MSS clamping na bramie VPN: co naprawia, a czego nie
Clamping przepisuje MSS w uściskach dłoni TCP, aby segmenty mieściły się w tunelu. Nigdy nie naprawia UDP ani zepsutego sprawdzenia path-MTU. Trzy kontrole, po kolei.
Małe żądania działają, duże pobierania się zawieszają, i ktoś proponuje MSS clamping. Ta propozycja jest wystarczająco często trafna, by warto było spróbować jej w odpowiedniej kolejności, i wystarczająco często błędna, by przy ślepym zastosowaniu stracić popołudnie. Trzy kontrole poniżej oddzielają prawdziwy problem z rozmiarem TCP od problemu UDP, od zepsutego wykrywania path-MTU i od clampu, który nigdy nie widzi uścisku dłoni, który ma przepisać.
Zacznij od kształtu awarii
Awaria rozmiaru ma sygnaturę: połączenie się nawiązuje, uwierzytelnianie i małe odpowiedzi się udają, a potem transfer zawiesza się na czas nieokreślony, gdy tylko potrzebny jest segment pełnego rozmiaru. Strony, które ładują tekst, ale nigdy nie kończą obrazu, to ta sama awaria w mniejszej skali. Jeśli nic się w ogóle nie łączy, problem jest wcześniej na ścieżce i clamping nie pomoże. Clamp nie naprawi uścisku dłoni, który nigdy nie dotarł.
Sygnatura istnieje, ponieważ uścisk dłoni to miejsce, w którym uzgadniany jest rozmiar segmentu. Każda strona ogłasza maksymalny rozmiar segmentu jako opcję TCP, a nadawcy szanują ogłoszenie drugiej strony. Jeśli ścieżka nie może unieść tak dużego segmentu, awaria pojawia się później, gdy nadawca w końcu takiego próbuje.
Miej transport na oku, czytając ten objaw. Clamping to przepisanie opcji TCP, więc rozmowa głosowa lub wideo, która zastyga pod tym samym tunelem, nie jest problemem MSS i nie poprawi się od tego. Zapisz transport, zanim dotkniesz opcji TCP.
Wyceń ścieżkę, a potem porównaj ją z tunelem
Dwie liczby mają znaczenie i często są mylone. path-MTU to największy pakiet, jaki ścieżka przenosi bez fragmentacji, a ogłaszany MSS dla IPv4 to ta wartość minus 40 bajtów nagłówków IP i TCP, albo minus 60 dla IPv6. Enkapsulacja tunelu zjada część budżetu, zanim pakiet wewnętrzny w ogóle się zacznie.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20Ping z bitem do-not-fragment mówi, czy pakiet o takim rozmiarze ładunku przetrwa; zmieniaj rozmiar, aż zawiedzie, i empirycznie znalazłeś limit ścieżki. Wyjście tracepath podaje MTU wykryte na trasie, co jest szybsze, gdy działa, i mniej niezawodne, gdy pośredni przeskok filtruje sondy.
Teraz odejmij narzut tunelu. Zewnętrzny nagłówek IP, nagłówek UDP i nagłówek właściwy dla tunelu pochodzą z tych samych 1500 bajtów, więc użyteczny wewnętrzny MTU na typowym podłożu Ethernet jest niższy, niż sugeruje łącze fizyczne. Jeśli wyliczony wewnętrzny MTU jest niższy od ogłaszanego przez twoich partnerów, znalazłeś prawdziwego kandydata do clampu, a nie domysł. Jeśli wyliczona wartość jest już powyżej ogłoszenia partnerów, zatrzymaj się tutaj i szukaj gdzie indziej.
Umieść clamp tam, gdzie przechodzi uścisk dłoni
Clamp działa przez przepisanie opcji MSS w pakietach SYN i SYN-ACK, gdy przechodzą przez bramę. Jeśli reguła siedzi na interfejsie, którego żaden z kierunków nigdy nie przekracza, negocjacja kończy się bez zmian i objaw pozostaje, dlatego umiejscowienie decyduje o wyniku bardziej niż wartość.
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
Kierunek to druga połowa. Clamping jednego kierunku naprawia połowę przepływów, a resztę zostawia zawodzącą w sposób wyglądający na przerywany, więc stosuj go w obu kierunkach przekazywanego ruchu. Klasyczna forma w Linuksie dla interfejsu tunelu to reguła mangle dopasowująca pakiety SYN:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuZwróć uwagę, co --clamp-mss-to-pmtu faktycznie robi: wyprowadza wartość z MTU trasy, co nie zawsze jest rzeczywistym budżetem ładunku tunelu. W tunelu opartym na trasie, gdzie trasa wewnętrzna i ścieżka zewnętrzna się różnią, jawna wartość wyliczona w poprzedniej kontroli jest bardziej przewidywalna niż automatyczna.
Sprawdź na nowym połączeniu i utrzymuj informację zwrotną przy życiu
Ustanowione połączenie zachowuje wynegocjowany MSS, więc test na tej samej sesji niczego nie dowodzi. Otwórz nowe połączenie po zmianie i odczytaj wynegocjowaną wartość bezpośrednio, zamiast wnioskować ją z transferu, który przypadkiem się kończy.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSPierwsze polecenie podaje MSS gniazda wraz ze stanem przeciążenia, co jest najszybszym potwierdzeniem, że clamp zadziałał. Drugie potwierdza, że reguła, którą uważasz, że dodałeś, jest regułą, która istnieje, w tabeli, w której została umieszczona.
Następnie chroń mechanizm, którego nie naprawiłeś. Wykrywanie path-MTU zależy od tego, czy komunikaty ICMP fragmentation-needed dotrą do nadawcy, więc firewall, który je odrzuca, będzie dalej psuł duże transfery nawet przy poprawnym clampie. Zezwól na te komunikaty dla ścieżki tunelu albo zaakceptuj, że clamping kompensuje politykę, którą sam wybrałeś.
Na koniec oprzyj się pokusie traktowania clampu jako pokrętła strojenia. Ogranicza rozmiar segmentu, co kosztuje przepustowość na ścieżkach, które nigdy go nie potrzebowały. Zastosowany po trzech kontrolach jest ukierunkowaną naprawą; zastosowany pierwszy jest zmianą, która ukrywa pierwotną usterkę i dodaje drugą zmienną do każdego późniejszego testu. Ten kompromis warto zrobić świadomie, a nie domyślnie.
Zapisz zmierzony path-MTU, odjęty narzut tunelu, dodaną regułę i MSS, który zobaczyłeś później. Cztery liczby czynią następny incydent wyszukiwaniem, a nie śledztwem.