Ajustarea MSS pentru TCP pe o poartă Linux IPsec: ce repară

Pingul funcționează, SSH funcționează, o pagină mică se încarcă, iar apoi fiecare răspuns mare se blochează până la expirarea timpului. Modelul clasic indică dimensiunea pachetului, nu accesibilitatea: calea transportă handshake-ul și primii câțiva kilobytes, apoi un segment de dimensiune completă dispare. Pe o poartă Linux IPsec, o regulă TCP MSS este adesea soluția, dar numai dacă înțelegeți ce schimbă și unde se află de fapt pachetul pe care îl atinge. Ordinea de mai jos urmărește pachetul de la simptom până la plasarea regulii, astfel încât să vă puteți opri imediat ce explicația nu mai este potrivită.

Simptomul care sugerează MSS

TCP negociază o dimensiune maximă a segmentului în handshake. Dacă acea valoare este mai mare decât ceea ce calea poate transporta după încapsulare, expeditorul continuă să producă segmente care nu ajung niciodată, iar conexiunea se blochează după primul schimb. Răspunsurile mici încap; cele mari nu.

Feedbackul ICMP poate salva conexiunea prin descoperirea MTU-ului căii, iar un firewall care aruncă aceste mesaje transformă blocajul într-o gaură neagră silențioasă. De aceea același tunel funcționează pentru o aplicație și eșuează pentru alta fără nicio diferență evidentă în configurație.

Ce face o regulă TCPMSS și ce nu face

Regula rescrie opțiunea MSS din pachetele de handshake TCP pe măsură ce trec. Nu setează MTU-ul interfeței tunelului, nu schimbă politica IPsec și, pe nucleele actuale, doar coboară o valoare anunțată în loc să o ridice pe una deja mai mică. De asemenea, atinge doar TCP; încărcăturile UDP, comportamentul DNS și selectorii de trafic negociați sunt în afara razei sale.

Deoarece schimbarea are loc în timpul handshake-ului, o conexiune existentă stabilită înainte de regulă își păstrează valoarea veche. Testați cu o conexiune nouă și așteptați-vă ca prima încercare după schimbare să fie cea care vă spune ceva. Nimic din regulă nu ajunge la o conexiune deja deschisă. De aceea o corecție aplicată la mijlocul unui incident poate părea că nu a făcut absolut nimic.

Puneți regula pe calea TCP interioară

Pe o poartă Linux bazată pe politici, pachetul redirecționat încă arată ca TCP obișnuit când firewallul îl vede. Politica IPsec decide că pachetul va fi protejat; firewallul nu vede un antet ESP pentru fluxul interior, așa că potrivirea cu ESP aici descrie un pachet complet diferit. Această nepotrivire este motivul pentru care unele reguli par corecte și nu se potrivesc niciodată.

În termenii iptables, regula aparține tabelului mangle de pe calea de redirecționare, limitată la pachetele de handshake: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Numărul este un exemplu, nu o constantă universală; deduceți-l din costul încapsulării și din MTU-ul real al căii. Un echivalent nftables setează dimensiunea maximă a segmentului într-un lanț forward sau postrouting.

Țineți regulile externe de ascultare pentru IKE și ESP separate de regulile interne de redirecționare. O singură regulă care încearcă să autorizeze atât fluxul aplicației, cât și protocolul exterior ajunge să nu se potrivească fiabil cu niciunul dintre ele.

Respectați proprietarul firewallului și ordinea NAT

Dacă UFW deține firewallul gazdei, adăugați modificările mangle și de redirecționare prin configurația sa persistentă acceptată, în loc să tastați o comandă care dispare la următoarea reîncărcare. O regulă inserată în tabelul greșit sau după o regulă terminală nu are niciun efect, iar tabelul activ ascunde asta de dumneavoastră.

Traducerea sursei este o decizie separată care interacționează adesea cu aceasta. O excepție plasată înaintea unei reguli masquerade generale împiedică traficul protejat să piardă sursa pe care o cere politica sa; nu repară o problemă de dimensiune, iar o regulă de dimensiune nu repară o problemă de traducere.

Verificați îngust, apoi opriți-vă

Deschideți o conexiune nouă la serviciul care eșuează și urmăriți atât aplicația, cât și contoarele regulii. Dacă blocajul dispare, aveți dovezi despre acea cale TCP cu acea încapsulare. Nu aveți dovezi că se potrivește fiecare protocol VPN, că fiecare aplicație UDP este reparată sau că un anumit serviciu din amonte a fost cauza inițială.

Lăsați feedbackul de dimensiune ICMP să funcționeze acolo unde politica permite, și tratați cu grijă ajustarea automată bazată pe MTU-ul rutei când calea IPsec exterioară nu este reprezentată de ruta interioară. Cu cât concluzia este mai îngustă, cu atât incidentul următor este mai ușor de diagnosticat.