Korleis NAT-traversal pakkar ESP inn i UDP

To klientar bak same ruter snakkar med éin IPsec-gateway, og den eine fell stadig ut medan den andre held seg oppe. Native ESP er IP-protokoll 50 utan portar, så ein omsetjar har ingenting å feste ei mapping på når fleire klientar deler éi adresse. NAT-traversal lukkar dette gapet ved å pakke ESP inn i UDP på 4500, og den headeren forklarer dei fleste av symptoma som følgjer. Han peikar også på eininga som må endrast.

Kvifor dataplanet flyttar til port 4500

Under oppsettet samanliknar IKEv2 adressene og portane som kvar side trur ho brukar, ved å utveksle hashar i NAT-detekteringsvarsla sine. Når hashane ikkje stemmer, sit det ein omsetjar ein stad på vegen, og begge partar flyttar den verna trafikken til UDP-innkapsling. Derfor ser ei økt som møtte ein omsetjar annleis ut enn ei som ikkje gjorde det.

Innpakkinga er ein konvolutt, ikkje ei protokollendring: ESP held på headeren, integritetskontrollen og krypteringa, og UDP leverer berre portane omsetjaren treng. Port 500 ber IKE-utvekslinga; 4500 ber dei innkapsla dataa etter detekteringa, og ofte også dei seinare IKE-meldingane. Ingen av portane gjer flyten til ei TCP-tilkopling, ei antaking som villedar dei fleste som les eit opptak.

Kontroller dei to trinna i rekkefølgje

Bevis først kontrollutvekslinga, deretter datastien, og hald dei to åtskilde i notata dine. Eit opptak som viser trafikk på 500 og aldri på 4500 betyr vanlegvis at datastien er filtrert, så rettinga høyrer heime i brannmurregelen og ikkje i klienten.

Overvak begge portane med tcpdump -ni any 'udp port 500 or udp port 4500', og les omsetjingstabellen på ruteren medan ei økt er aktiv. Tabellen viser kjeldeporten gatewayen faktisk vil sjå, og eit opptak på laptopen er usamd med vilje: laptopen trur 500 medan gatewayen ser 4500 med ein omsett kjeldeport, og begge har rett. Den same flyten, før og etter omsetjing:

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

Symptom innpakkinga forklarer, og to ho ikkje forklarer

Ein ruter som tillèt kontrollutvekslinga og blokkerer dei innkapsla dataa gir rapporten om at tunnelen er oppe, men at ingenting går gjennom. Mappingstabellar går ut på tid, så ei inaktiv økt treng keepalive-trafikk som partane sender med vilje, og desse pakkane er ikkje helsesjekkar. Når fleire klientar bak éin gateway feilar samstundes, undersøk omsetjinga til den gatewayen og ein kvar gammal passthrough-funksjon. Innpakkinga forklarer ikkje eit program som feilar hos alle klientar etter at tunnelen er oppe, eller ei sertifikatåtvaring på ei blokkeringsside; begge ligg over dette laget.

Les mappingstabellen for to klientar samstundes: viss begge viser same omsette port, skil eininga dei ikkje slik gatewayen krev. Ein passthrough-modus som gir native ESP til berre éin vert, svarar ikkje til å betene fleire omsette klientar, sjølv om leverandørar skildrar begge som IPsec-venlege. Dobbelt NAT legg til eit mappinglag og endå eitt utløpspunkt, men det bryt ikkje utgåande tilkoplingar automatisk.

Keepalive-trafikk fortener si eiga line i driftshandboka, fordi det er den som held svarstien open gjennom inaktive periodar. Aktiver han der leverandøren dokumenterer det, og kontroller han først når ei økt døyr etter minuttars stille i staden for ved første bruk.

Endre eigaren av mappinga, og test på nytt

Følg dei støtta NAT-traversal-innstillingane på begge partar i staden for å gjette på ein port. Å redigere den lokale kjeldeporten på éin klient kan ikkje endre tenesta som lyttar i den andre enden, og det øydelegg vanlegvis mappinga som alt er bygd. Viss klienten sit bak ei eining du ikkje kontrollerer, høyrer endringa til eigaren av ho.

Etter kvar endring, gjenta begge trinnkontrollane og stadfest at ein datapakke passerer, ikkje berre at statusskjermen vart grøn. Hald tupla, utdataa frå mappingstabellen og regelendringa i eitt notat, slik at neste person ikkje startar på nytt frå kontrollutvekslinga. strongSwan-notata om NAT-traversal dekkjer innkapslings- og keepalive-innstillingane bak begge trinna.