ESP este protocolul IP 50, nu portul TCP 50: ce trebuie permis

Formularele de firewall cer un port TCP, iar intrarea evidentă este 50. Acea intrare nu permite nimic, deoarece ESP este protocolul IP numărul 50, iar numerele de protocol nu sunt porturi. Cele două spații de nume împart doar numere întregi mici și nimic altceva, iar eroarea rămâne invizibilă până când IKE se termină și traficul protejat nu ajunge niciodată.

Două spații de nume care împart numere mici

Un antet IP poartă un câmp de protocol care numește ce urmează: 6 pentru TCP, 17 pentru UDP, 1 pentru ICMP, 50 pentru ESP, 51 pentru AH. Un antet TCP sau UDP poartă numere de port, care selectează un proces pe gazda de destinație. Protocolul 50 și portul TCP 50 sunt valori fără legătură, dar o casetă de dialog le poate face să pară interschimbabile.

De aceea o regulă de redirecționare a porturilor nu poate exprima ESP nativ. Nu există un port de destinație ESP de redirecționat, iar un dispozitiv care înțelege doar reguli de port nu are deloc vocabular pentru acel pachet. Regula corectă numește protocolul IP. Orice dialog de porturi este instrumentul greșit pentru acel pachet.

Confuzia are o a doua jumătate. Când pachetul este criptat, tot ce este în interiorul lui este opac, inclusiv antetul TCP al conexiunii originale. Un firewall care inspectează porturi în acel pachet se uită la antetul exterior, care în cazul nativ nu are porturi de inspectat.

ESP nativ, apoi alternativa încapsulată

ESP nativ este transportat direct ca protocol IP, ceea ce este la fel de eficient pe cât este de incomod. Eficient pentru că nu există un antet suplimentar, și incomod pentru că niciun dispozitiv care traduce adrese și porturi nu îl poate urmări. NAT traversal există exact pentru asta: înfășoară pachetul ESP în UDP, astfel încât traducătorul să aibă porturi de rescris.

Cele două forme sunt implementări alternative ale aceluiași canal de date, nu straturi ale unuia. Permiterea ESP nativ nu permite forma încapsulată, iar permiterea UDP 4500 nu permite traficul nativ, așa că un set de reguli trebuie să corespundă implementării, nu să le acopere pe amândouă din întâmplare.

Și detectarea contează aici. Punctele terminale decid între forme în timpul negocierii, iar comutarea se produce de obicei când este detectat un NAT între ele. De aceea o cale care se schimbă după stabilirea tunelului poate muta traficul într-un spațiu de nume pe care regulile tale nu l-au acoperit niciodată.

Citiți ce formă folosește de fapt conexiunea

Întrebați punctul terminal în loc să ghiciți din firewall. În Linux intrarea de stare raportează dacă asocierea folosește încapsulare UDP și ce porturi sunt implicate. O captură de pachete răspunde la aceeași întrebare de pe cablu, și ambele sunt mai rapide decât să citești un set de reguli și să speri.

ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'

Prima comandă arată un tip de încapsulare când NAT traversal este folosit și nimic când nu este. A doua arată care dintre cele două forme traversează de fapt interfața, iar asta încheie discuțiile despre o configurație care pare corectă pe hârtie.

Contraprobarea face parte din același pas. O regulă care raportează zero potriviri îți spune că pachetul nu a ajuns niciodată la ea, iar asta este o chestiune de rutare sau de selector, nu de firewall.

Apoi confirmați canalul de control separat. IKE are propriile porturi și propriile jurnale, iar o negociere încheiată fără date este exact separarea despre care este acest articol.

Scrieți regula în spațiul de nume corect

O regulă de protocol și o regulă de port sunt instrucțiuni diferite, așa că instrumentul trebuie să o exprime pe cea pe care o aveți în vedere. În nftables potrivirea protocolului este explicită, iar alternativa încapsulată primește propria regulă UDP. Țineți cele două reguli alăturate, ca perechea să fie vizibilă la revizuire.

nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept

Nu lărgiți niciuna dintre reguli pentru a compensa un diagnostic greșit. Permiterea totală pentru protocolul ESP pe fiecare interfață, sau o permisiune UDP de oriunde către oriunde, repară un simptom și elimină controlul pe care încercați să îl configurați. Fluxul îngust acceptat este aproape întotdeauna suficient odată ce forma este cunoscută.

În final, țineți straturile drepte când tunelul funcționează, iar aplicația nu. Pachetele care ajung la gateway au în continuare nevoie de redirecționare, de o rută de întoarcere și de o politică ce le admite, și nimic din toate acestea nu este exprimat de o regulă ESP. Portul lipsă explică o defecțiune anume, nu fiecare defecțiune IPsec. Țineți corectarea regulii și verificarea rutării ca două concluzii separate.

Notați forma pe care ați observat-o, regula de protocol pe care ați adăugat-o și contorul pe care l-ați văzut după aceea. Trei rânduri, iar următoarea persoană poate distinge o eroare de spațiu de nume de una de rutare într-un minut, nu într-o după-amiază.