Ogromna cześć lokalnych ISP zdaje się nie nadążać za ciągle zmieniającą się rzeczywistością. Problem dotyczy implementacji protokołu IPv6, który jest już z nami od bardzo wielu lat. W przypadku mojego obecnego ISP raczej nie mam co liczyć na to, by w bliżej nieokreślonej przyszłości dodał on obsługę tego protokołu. Istnieje jednak mechanizm zwany tunelowaniem pakietów protokołu IPv6 wewnątrz pakietów protokołu IPv4 (w skrócie 6to4), którym warto się zainteresować. W ogromnym skrócie, część puli adresowej IPv6 jest zarezerwowana i zmapowana na adresy protokołu IPv4. Dzięki takiemu podejściu, każdy kto posiada stały zewnętrzny adres IPv4 ma również adres w puli IPv6. Mając zatem zarezerwowany adres, możemy pokusić się o utworzenie tunelu 6to4, co aktywuje w naszej infrastrukturze ten nowszy protokół obchodząc jednocześnie ograniczenia ISP. Trzeba jednak mieć na względzie, że nie jest to natywne wsparcie dla protokołu IPv6 i jest niemal pewne, że wystąpią mniejsze lub większe problemy z wydajnością.

SysRq (System Request) to klawisz na klawiaturze, po którego przyciśnięciu można wysłać niskopoziomowe zapytana bezpośrednio do kernela linux'a. Te komendy działają nawet w przypadku pozornego braku kontaktu z systemem operacyjnym, tj. zacięcia dźwięku, nieruchomy kursor myszy, a nawet w przypadku braku możliwości wpisywania znaków z klawiatury. Zwykle po opisanych wyżej symptomach, człowiek jest skłonny przycisnąć przycisk reset na obudowie swojego komputera, no bo jak inaczej odwiesić taki system? Problem z twardym resetem (za pomocą przycisku) jest taki, że praktycznie zawsze po nim występuje uszkodzenie struktury systemu plików na dysku, a czasami uszkodzeniu ulega cała partycja. To niesie ze sobą ryzyko utraty danych. Dlatego też powinniśmy zaprzestać resetowania komputerów przy pomocy przycisków i zacząć korzystać z klawisza SysRq .

Gdy nasz linux napotka z jakiegoś powodu błąd wewnątrz swojej struktury, to istnieją sytuacje, w których obsługa tego błędu czasem nie jest możliwa. Wobec czego, zostaje wyrzucony komunikat systemowy oznajmiający nam, że kernel spanikował (kernel panic), bo nie wie co w takim przypadku zrobić. Gdy tego typu sytuacja się nam przytrafia, nie ma innego wyjścia jak tylko uruchomić system ponownie. Co jednak w przypadku gdy pracujemy zdalnie i nie jesteśmy w stanie zresetować takiej maszyny fizycznie? Na szczęście kernel ma kilka opcji, które mogą zainicjować automatyczny restart w przypadku wystąpienia kernel panic.

Atak SYN flood to rodzaj ataku DoS, którego celem jest wyczerpanie zasobów serwera uniemożliwiając mu tym samym poprawne realizowanie danej usługi, do której został oddelegowany. Jest to dość popularne zjawisko i w przypadku, gdy mamy postawioną jakąś maszynę na publicznym adresie IP, przydałoby się nieco zainteresować tym problem, który może wystąpić w najmniej oczekiwanym momencie. W tym wpisie rzucimy okiem na mechanizm SYN cookies.

Internet nie jest zbyt przyjaznym miejscem i jest wielce prawdopodobne, że prędzej czy później ktoś zaatakuje jedną z naszych maszyn, która świadczy w nim jakieś usługi. Są różne typy ataków, w tym przypadku chodzi o ataki DDoS z wykorzystaniem pakietów wchodzących w proces potrójnego witania (three way handshake) przy nawiązywaniu połączenia w protokole TCP, tj. pakiety SYN , SYN-ACK i ACK . Istnieje szereg mechanizmów, które adresują problem SYN flooding'u ale żaden z nich nie jest doskonały. Jakiś czas temu, do kernela linux'owego trafił patch implementujący mechanizm SYNproxy i w tym wpisie obadamy go sobie nieco dokładniej.

Retransmisja pakietu w przypadku sieci opartych na protokołach TCP/IP nie jest niczym niezwykłym. Oczywiście, pozostaje kwestia samego realizowania tego przedsięwzięcia ale generalnie rzecz biorąc, systemy linux'owe mają szereg opcji w kernelu, które możemy sobie dostosować konfigurując tym samym, to w jaki sposób nasz system reaguje na zjawisko utraty pakietów podczas ich przesyłu między dwoma punktami sieciowymi.

Kernele linux'owe mają dość sporo opcji, które możemy zmienić przy pomocy pliku /etc/sysctl.conf . Niby nic nadzwyczajnego ale co w przypadku tych zmiennych, które muszą być ustawione, z tym, że moduł, który stworzy odpowiednie ścieżki w katalogu /proc/sys/ , nie został załadowany z jakichś względów przy starcie systemu? Zmienne te nie zostaną ustawione, a w logu pojawi się komunikat informujący nas o nieodnalezieniu określonego pliku. Okazuje się, że jesteśmy w stanie aplikować określone ustawienia sysctl w momencie ładowania określonych modułów i temu mechanizmowi się przyjrzymy bliżej w tym wpisie.

Wolny start jest wynikiem braku zaufania maszyny nadawczej do utworzonego kanału przesyłowego -- połączenia. Nie wie ona czy to łącze jest bowiem w stanie obsłużyć taką porcję danych, którą ma zamiar przesłać bez czekania na pakiet ACK . W przypadku bufora odbiorczego, wszystko jest proste, bo dane dotyczące wielkości okien są zdefiniowane w nagłówku pakietów, do których ma wgląd druga ze stron. W przypadku gdy nadawca przesyła dane, prędkość z jaką to robi zależy głównie od niego.

Wraz ze zwiększaniem zapotrzebowania na szybsze łącza internetowe, ograniczenia wynikające z protokółu TCP zaczęły powoli dawać się ludziom we znaki. Problemem była bariera prędkości, którą ciężko było pokonać mając do dyspozycji domyślną formę nagłówka protokołu TCP. Było w nim zwyczajnie za mało miejsca, co zapoczątkowało jego rozbudowę kosztem ilości danych, które można było przesłać w pojedynczym segmencie. W tym wpisie skupię się głównie na dwóch opcjach jakie zostały dodane do nagłówka TCP, tj. dynamiczne skalowanie okien oraz znaczniki czasu, bo te dwa parametry nie mogą wręcz bez siebie istnieć, zwłaszcza gdy rozmawiamy o łączach pokroju 1 czy 10 gbit/s.

Protokół TCP jest tak zbudowany by zapewnić rzetelny transfer danych między dwoma komunikującymi się punktami. Z początku jednak, ta cecha tego protokołu powodowała marnowanie dość sporych ilości zasobów jeśli chodzi o przepustowość łącza. Stało się to widoczne przy większych prędkościach połączeń, gdzie skalowany był bufor (okno) TCP, co umożliwiło przesyłanie szeregu segmentów bez potrzeby czekania na ich potwierdzenie przez odbiorcę. To zwiększyło, co prawda, transfer danych ale pojawił się problem z zagubionymi pakietami.