Właściwie to chciałem iść na rower, ale pogoda była mocno niestabilna, a ponieważ prysznice to wolę ciepłe, ostatecznie zająłem się czymś innym. A to "coś innego" to było zwalczenie fragmentacji w mojej sieci, no, przynajmniej w jej fragmencie.
Fragmentacja jest ZŁA
W którym fragmencie? Jak pewnie niektórzy pamiętają nie jestem całkiem normalny, w związku z czym między AP na OpenBSD i moimi laptopami korzystam z IPSec w trybie tunelowym. Powoduje to, że pakiet przychodzący na jeden interfejs (nieszyfrowany) jest opakowywany w ESP i dodatkowo w kolejny nagłówek IP. Oznacza to "zwiększenie" pakietu o dodatkowe dane, co z kolei pociąga za sobą przekroczenie wartości MTU dla Ethernetu (1500 bajtów), konieczność fragmentacji i... i mnie irytuje. Dlaczego fragmentacja jest zła? Dlatego, że do przesłania 4 bajtów danych, które mi się w jednym pakiecie nie mieściły potrzebne było aż 20 bajtów dodatkowego nagłówka, czyli dość niska efektywność przesyłania, na jeden bajt danych przypadało 5 bajtów opakowania. Oczywiście dotyczy to tylko tego drugiego fragmentu pierwotnego pakietu.
Jak można uniknąć fragmentacji? Prosto, tak zmniejszyć rozmiar pakietów nieszyfrowanych, by po opakowaniu w ESP i dodatkowy nagłówek IP były mniejsze niż MTU łącza. Jak to zrobić? Najpierw trzeba się zastanowić z czym chce się walczyć. Mamy ICMP, UDP, TCP... Pakiety ICMP i UDP zwykle są na tyle małe, że nie wywołują fragmentacji. Fragmentacja występowała głownie przy sesjach TCP, wówczas, gdy transmitowane były dane "masowe". Ilość danych przesyłanych w jednym segmencie TCP określona jest od góry wartością MSS, która dla sieci Ethernet wynosi 1460 bajtów (MTU - nagłówki). Zmniejszenie wartości MSS spowoduje automatycznie zmniejszenie maksymalnego rozmiaru pakietu zawierającego segment TCP, po dodaniu ESP i kolejnego nagłówka IP rozmiar całości jest mniejszy niż 1500 bajtów, w związku z czym fragmentacja staje się zbędna.
Jaki rozmiar MSS wybrać? Teoretycznie można to sobie wyliczyć, ale z uwagi na konstrukcję ESP (zmienna długość pól ESP trailer oraz authentication data) wolałem to zrobić empirycznie. Z moich testów wynika, że w moim konkretnym przypadku, odpowiednią wartością dla MSS jest 1388 bajtów. Oznacza to, że cały pakiet przed "zapakowaniem" ma wielkość 1428 bajtów. Z tego co widzę, po zapakowaniu osiąga on wielkość 1496 bajtów, czyli nagłówek IP i ESP zajmują wspólnie dodatkowych 68 bajtów, a więc, ponieważ IP to 20 bajtów, na ESP przypada w tym wypadku 48 bajtów.
Jak ustalić rozmiar MSS? Oczywiście, najłatwiej to zrobić na serwerze. W PF jest możliwość normalizacji pakietów poprzez scrub. Scrub posiada opcję max-mss, której konfiguracja spowoduje "podmienienie" wartości MSS w przesyłanych pakietach, co powoduje, że negocjowana w trakcie nawiązywania połączenia TCP wartość MSS jest nie większa niż wartość zdefiniowana w max-mss. W moim przypadku jest to 1388 bajtów.
W tej chwili łatwo wyliczyć jak duże są straty wynikające z wykorzystania ESP. Pakiet o wielkości 1496 bajtów przenosi efektywnie 1388 bajtów danych, czyli rozmiar pakietu przeznaczony na dane to jakieś 92% całej wielkości pakietu. W przypadku, gdy nie ma IPSec jest to około 97%, czyli narzut IPSec to jakieś 5%.
A teraz sprawdzę, czy Backtrack radzi sobie z moją kartą wireless w drugim laptopie i może połamię trochę WEPa...
