Ako NAT traversal zabalí ESP do UDP

Dvaja klienti za rovnakým routerom komunikujú s jedinou bránou IPsec a jeden stále vypadáva, zatiaľ čo druhý zostáva pripojený. Natívny ESP je IP protokol 50 bez portov, takže prekladač nemá k mapovaniu čo pripnúť, keď viacerí klienti zdieľajú jednu adresu. NAT traversal túto medzeru uzatvára zabalením ESP do UDP na 4500 a tá hlavička vysvetľuje väčšinu nasledujúcich príznakov. Ukazuje aj na zariadenie, ktoré treba zmeniť.

Prečo sa dátová rovina presúva na port 4500

Počas nastavenia IKEv2 porovnáva adresy a porty, o ktorých každá strana verí, že ich používa, výmenou hashov vo svojich oznámeniach o detekcii NAT. Keď sa hashe nezhodujú, niekde na ceste sedí prekladač a obe strany prepnú chránenú premávku na zapuzdrenie UDP. Preto relácia, ktorá sa stretla s prekladačom, vyzerá inak ako tá, ktorá sa nestretla.

Obal je obálka, nie zmena protokolu: ESP si zachováva svoju hlavičku, kontrolu integrity a šifrovanie a UDP dodáva len tie porty, ktoré prekladač potrebuje. Port 500 nesie výmenu IKE; 4500 nesie zapuzdrené údaje po detekcii a často aj neskoršie správy IKE. Žiadny z portov nerobí z toku TCP spojenie, čo je predpoklad, ktorý mätie väčšinu ľudí čítajúcich záznam.

Skontrolujte obe fázy v poradí

Najprv preukážte riadiacu výmenu, potom dátovú cestu, a obe držte v poznámkach oddelene. Záznam, ktorý ukazuje premávku na 500 a nikdy na 4500, zvyčajne znamená, že dátová cesta je filtrovaná, takže oprava patrí do pravidla firewallu, nie do klienta.

Sledujte oba porty pomocou tcpdump -ni any 'udp port 500 or udp port 4500' a čítajte prekladovú tabuľku na routeri, kým je relácia živá. Tabuľka ukazuje zdrojový port, ktorý brána skutočne uvidí, a záznam na notebooku sa zámerne rozchádza: notebook verí, že je to 500, zatiaľ čo brána vidí 4500 s preloženým zdrojovým portom, a oba sú správne. Ten istý tok pred prekladom a po ňom:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Príznaky, ktoré obal vysvetľuje, a dva, ktoré nie

Router, ktorý povolí riadiacu výmenu a zablokuje zapuzdrené údaje vytvorí hlásenie „tunel stojí, ale nič neprechádza“. Mapovacie tabuľky vypršia, takže nečinná relácia potrebuje prevádzku keepalive, ktorú strany posielajú zámerne, a tie pakety nie sú zdravotné kontroly. Keď viacerí klienti za jednou bránou zlyhajú spoločne, preskúmajte preklad tejto brány a akúkoľvek staršiu funkciu prepúšťania. Obal nevysvetľuje aplikáciu, ktorá zlyhá u každého klienta po postavení tunela, ani varovanie o certifikáte na blokovacej stránke; oboje je nad touto vrstvou.

Čítajte mapovaciu tabuľku pre dvoch klientov naraz: ak obaja ukazujú rovnaký preložený port, zariadenie ich neoddeľuje tak, ako brána vyžaduje. Režim prepúšťania, ktorý odovzdá natívny ESP len jednému hostiteľovi, nie je rovnocenný obsluhe viacerých preložených klientov, hoci dodávatelia oba opisujú ako priateľské k IPsec. Dvojitý NAT pridáva mapovaciu vrstvu a ďalší bod vypršania, ale automaticky neprerušuje odchádzajúce spojenia.

Prevádzka keepalive si zaslúži vlastný riadok v prevádzkovej príručke, pretože práve ona drží cestu pre odpoveď otvorenú počas období nečinnosti. Zapnite ju tam, kde ju dodávateľ dokumentuje, a skontrolujte ju ako prvú, keď relácia zomrie po niekoľkých minútach ticha, a nie pri prvom použití.

Zmeňte vlastníka mapovania a potom znova otestujte

Riaďte sa podporovaným nastavením NAT traversal na oboch stranách namiesto hádania portu. Úprava miestneho zdrojového portu u jedného klienta nemôže zmeniť službu, ktorá počúva na druhom konci, a zvyčajne pokazí už vytvorené mapovanie. Ak klient sedí za zariadením, ktoré neovládate, zmena patrí jeho vlastníkovi.

Po každej zmene zopakujte obe kontroly fáz a potvrďte, že dátový paket prechádza, nie len že stavová obrazovka zozelenela. Držte n-tice, výstup mapovacej tabuľky a zmenu pravidla v jednej poznámke, aby ďalší človek nezačínal odznova od riadiacej výmeny. Poznámky strongSwan k NAT traversal pokrývajú nastavenia zapuzdrenia a keepalive za oboma fázami.