Kako NAT prolaz obavija ESP unutar UDP-a

Dva klijenta iza istog rutera razgovaraju s jednim IPsec pristupnikom, i jedan stalno pada dok drugi ostaje stabilan. Izvorni ESP je IP protokol 50 bez portova, pa prevodilac nema na šta vezati mapiranje kada više klijenata dijeli jednu adresu. NAT prolaz zatvara tu prazninu obavijajući ESP u UDP na 4500, i to zaglavlje objašnjava većinu simptoma koji slijede. Ono također pokazuje na uređaj koji treba promijeniti.

Zašto se ravan podataka premješta na port 4500

Tokom postavljanja IKEv2 poredi adrese i portove za koje svaka strana vjeruje da ih koristi, razmjenjujući heševe u svojim obavještenjima o otkrivanju NAT-a. Kada se heševi ne slažu, negdje na putu sjedi prevodilac, i oba partnera prebacuju zaštićeni saobraćaj na UDP enkapsulaciju. Zato sesija koja je naišla na prevodioca izgleda drugačije od one koja nije.

Omotač je koverta, a ne promjena protokola: ESP zadržava svoje zaglavlje, provjeru integriteta i šifrovanje, a UDP obezbjeđuje samo portove koji su prevodiocu potrebni. Port 500 nosi IKE razmjenu; 4500 nosi enkapsulirane podatke nakon otkrivanja, a često i kasnije IKE poruke. Nijedan port ne čini tok TCP vezom, a upravo ta pretpostavka zavarava većinu ljudi koji čitaju snimak.

Provjerite dvije faze po redu

Prvo dokažite kontrolnu razmjenu, zatim putanju podataka, i držite to dvoje odvojeno u bilješkama. Snimak koji prikazuje saobraćaj na 500 i nikada na 4500 obično znači da je putanja podataka filtrirana, pa ispravka pripada pravilu firewall-a, a ne klijentu.

Nadzirite oba porta pomoću tcpdump -ni any 'udp port 500 or udp port 4500' i čitajte tabelu prevođenja na ruteru dok je sesija aktivna. Ta tabela prikazuje izvorni port koji će pristupnik zaista vidjeti, a snimak na laptopu se po dizajnu ne slaže: laptop vjeruje da je 500 dok pristupnik vidi 4500 s prevedenim izvornim portom, i oba su tačna. Isti tok, prije i poslije prevođenja:

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

Simptomi koje omotač objašnjava, i dva koja ne objašnjava

Ruter koji dopušta kontrolnu razmjenu i blokira enkapsulirane podatke daje izvještaj „tunel je podignut, ali ništa ne prolazi“. Tabele mapiranja istječu, pa neaktivna sesija treba saobraćaj održavanja koji partneri šalju namjerno, i ti paketi nisu zdravstvene provjere. Kada više klijenata iza jednog pristupnika padne zajedno, ispitajte prevođenje tog pristupnika i bilo koju naslijeđenu funkciju propuštanja. Omotač ne objašnjava aplikaciju koja pada kod svakog klijenta nakon podizanja tunela, ni upozorenje o sertifikatu na stranici blokade; oboje je iznad ovog sloja.

Čitajte tabelu mapiranja za dva klijenta odjednom: ako oba pokazuju isti prevedeni port, uređaj ih ne razdvaja onako kako pristupnik zahtijeva. Režim propuštanja koji daje izvorni ESP samo jednom hostu nije ekvivalentan usluživanju više prevedenih klijenata, iako prodavači oba opisuju kao prijateljske prema IPsec-u. Dvostruki NAT dodaje sloj mapiranja i još jednu tačku isteka, ali ne prekida automatski odlazne veze.

Saobraćaj održavanja zaslužuje svoj red u operativnom priručniku, jer upravo on drži povratnu putanju otvorenom kroz periode mirovanja. Uključite ga tamo gdje ga prodavač dokumentuje, i provjerite ga prvo kada sesija umre nakon nekoliko minuta tišine, a ne pri prvoj upotrebi.

Promijenite vlasnika mapiranja, pa ponovo testirajte

Slijedite podržane postavke NAT prolaza na oba partnera umjesto da pogađate port. Uređivanje lokalnog izvornog porta na jednom klijentu ne može promijeniti uslugu koja sluša na drugoj strani, i obično kvari već izgrađeno mapiranje. Ako klijent stoji iza uređaja koji ne kontrolišete, promjena pripada njegovom vlasniku.

Nakon svake promjene ponovite obje provjere faza i potvrdite da podatkovni paket prolazi, a ne samo da je statusni ekran postao zelen. Držite tuple, izlaz tabele mapiranja i promjenu pravila u jednoj bilješci, da sljedeća osoba ne počne ponovo od kontrolne razmjene. Bilješke strongSwan-a o NAT prolazu pokrivaju postavke enkapsulacije i održavanja iza obje faze.