Prilagajanje MSS za TCP na prehodu Linux IPsec: kaj popravi

Ping deluje, SSH deluje, majhna stran se naloži, nato pa se vsak velik odgovor ustavi, dokler ne poteče čas. Klasičen vzorec kaže na velikost paketa in ne na dosegljivost: pot nosi rokovanje in prvih nekaj kilobajtov, nato celoten segment izgine. Na prehodu Linux IPsec je pravilo TCP MSS pogosto rešitev, a le če razumete, kaj spreminja in kje se paket, ki se ga dotakne, v resnici nahaja. Vrstni red spodaj sledi paketu od simptoma do postavitve pravila, tako da lahko prenehate, takoj ko razlaga ne ustreza več.

Simptom, ki kaže na MSS

TCP se pri rokovanju dogovori o največji velikosti segmenta. Če je ta vrednost večja od tiste, ki jo pot zmore po inkapsulaciji, pošiljatelj še naprej ustvarja segmente, ki nikoli ne prispejo, in povezava se po prvem krogu ustavi. Majhni odgovori se prilegajo; veliki ne.

Povratna informacija ICMP lahko povezavo reši z odkrivanjem MTU poti, požarni zid, ki te sporočila zavrže, pa ustavitev spremeni v tiho črno luknjo. Zato isti tunel deluje za eno aplikacijo in spodleti za drugo brez očitne razlike v konfiguraciji.

Kaj pravilo TCPMSS naredi in česa ne

Pravilo prepiše možnost MSS v paketih rokovanja TCP, ko ti prehajajo. Ne nastavi MTU vmesnika tunela, ne spremeni politike IPsec in na sedanjem jedru samo zniža objavljeno vrednost, namesto da bi dvignilo že manjšo. Dotakne se tudi samo TCP; obremenitve UDP, vedenje DNS in dogovorjeni izbirniki prometa so zunaj njegovega dosega.

Ker se sprememba zgodi med rokovanjem, obstoječa povezava, vzpostavljena pred pravilom, obdrži staro vrednost. Preizkusite z novo povezavo in pričakujte, da bo prvi poskus po spremembi tisti, ki vam bo kaj povedal. Nič v pravilu ne doseže že odprte povezave. Zato je lahko popravek, uporabljen sredi incidenta, videti, kot da ni storil čisto nič.

Pravilo postavite na notranjo pot TCP

Na prehodu Linux, ki temelji na politikah, je posredovani paket za požarni zid še vedno videti kot običajen TCP. Politika IPsec odloči, da bo paket zaščiten; požarni zid za notranji tok ne vidi glave ESP, zato ujemanje z ESP tukaj opisuje povsem drug paket. Prav to neskladje je razlog, da so nekatera pravila videti pravilna in se nikoli ne ujemajo.

V izrazih iptables pravilo spada v tabelo mangle na poti posredovanja, omejeno na pakete rokovanja: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Število je primer, ne univerzalna konstanta; izpeljite ga iz stroškov inkapsulacije in dejanskega MTU poti. Enakovredno pravilo nftables nastavi največjo velikost segmenta v verigi forward ali postrouting.

Zunanja pravila poslušanja za IKE in ESP imejte ločena od notranjih pravil posredovanja. Eno samo pravilo, ki poskuša dovoliti tok aplikacije in zunanji protokol hkrati, se na koncu zanesljivo ne ujema z nobenim od obeh.

Spoštujte lastnika požarnega zidu in vrstni red NAT

Če UFW upravlja požarni zid gostitelja, dodajte spremembe mangle in posredovanja prek njegove podprte trajne konfiguracije, namesto da bi vtipkali ukaz, ki ob naslednjem nalaganju izgine. Pravilo, vstavljeno v napačno tabelo ali za končno pravilo, nima učinka, in živa tabela to skriva pred vami.

Prevajanje vira je ločena odločitev, ki se pogosto prepleta s to. Izjema, postavljena pred splošno pravilo masquerade, prepreči, da bi zaščiten promet izgubil vir, ki ga zahteva njegova politika; ne popravi težave z velikostjo in pravilo velikosti ne popravi težave s prevajanjem.

Preverite ozko in nato prenehajte

Odprite novo povezavo do storitve, ki spodleti, in opazujte aplikacijo ter števce pravila. Če se ustavitev odpravi, imate dokaz o tej poti TCP s to inkapsulacijo. Nimate dokaza, da ustreza vsak protokol VPN, da je popravljena vsaka aplikacija UDP ali da je bil določen nadrejeni servis prvotni vzrok.

Pustite povratno informacijo o velikosti prek ICMP delovati tam, kjer politika to dovoli, in previdno ravnajte z samodejnim omejevanjem na podlagi MTU poti, kadar zunanje poti IPsec ne predstavlja notranja pot. Ožji ko je sklep, lažje je diagnosticirati naslednji incident.