strongSwan ESP-in-UDP: kad nav ko atklāt ar NAT

NAT atklāšana atrod adrešu tulkošanu, nevis ugunsmūra politiku. Vietnes savienojumam bez NAT joprojām var būt nepieciešama skaidra ESP-in-UDP izvēle.

NAT atklāšana atbild uz vienu jautājumu: vai adreses vai porti ceļā mainījās? Tā neatbild, vai ugunsmūris atļauj IP 50 protokolu. Vietnes vārtejas bez jebkādas tulkošanas joprojām var atrasties aiz politikas, kas izmet native ESP, un šī prasība ir jākonfigurē, nevis jāatklāj. Mehānisms ir ESP-in-UDP, un tas ir lēmums, nevis pats no sevis parādījusies rezerves iespēja.

Atklāšana ir aritmētika uz adresēm, nevis ugunsmūra zonde

IKEv2 pārnēsā NAT atklāšanas kravas ar avota un galamērķa adrešu un portu jaucējkodiem. Katra puse salīdzina saņemto ar to, ko redz lokāli, un neatbilstība tai pasaka, ka kaut kas pakojumu ir pārveidojis. Nekas šajā apmaiņā nepārbauda, vai maršrutētājs pa vidu pārsūta IP 50 protokolu.

Praktisko sekas ir vērts pateikt tieši. Tunelis, kas darbojās ar native ESP, pats neatklās jaunu ierobežojošu ugunsmūri, un tā nākamais mēģinājums neizdosies datu posmā, kamēr IKE turpinās gūt panākumus. Jūs redzēsiet izveidotas IKE drošības asociācijas un nekādu aizsargātu datplūsmu, kas izskatās pēc maršrutēšanas kļūdas, līdz notverat uz vada.

Tāpēc iekapsulēšana ir jūsu konfigurētā savienojuma īpašība, nevis rezultāts, par ko puses vienojas, balstoties uz tīkla uzvedību.

Kā encap maina apmaiņu

Mūsdienīgā strongSwan izvietojumā, ko pārvalda caur swanctl.conf, savienojuma iestatījums encap = yes ietekmē NAT atklāšanas apmaiņu tā, ka abas puses ESP izmanto UDP iekapsulēšanu. Aizsargātie pakojumi pēc tam ceļo UDP iekšienē, parasti 4500 portā, un abiem galiem par šo kārtību jāvienojas.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Šis fragments pieder īstai savienojuma definīcijai un nav pilnīgs vietnes profils. Saglabājiet jau lietotos partnera adreses, autentifikāciju un child datplūsmas atlasītājus; vienīgā pievienotā atslēga maina to, kā tiek ietīti aizsargātie dati, nevis ko tie aizsargā.

strongSwan NAT-traversal rokasgrāmata apraksta šo uzvedību, tostarp mijiedarbību ar porta peldēšanu, kad tiek izmantots MOBIKE.

Izmantojiet iestatījumu, kas pieder jūsu backend

strongSwan ir divi konfigurācijas backend, un atslēga starp tiem atšķiras. swanctl.conf savienojums pieņem encap, bet vecāks ipsec.conf savienojums pieņem forceencaps. Viena backend atslēgvārda ievietošana otrā rada konfigurāciju, kas ielādējas bez iebildumiem un neko nemaina, kas ir sliktāk par kļūdu.

Pirms kaut ko rediģējat, pārbaudiet, kurš dēmons faktiski darbojas. Daudzās distribūcijās ir abas datnes, jo viena ir iepriekšējās migrācijas palieka, un aktīvā ir tā, ko startē servisa vienība. Lasiet šo vienību, nevis miniet no datņu laika zīmogiem. Piecu sekunžu pārbaude šeit ietaupa stundas, pārbaudot iestatījumu, ko nekas nav ielādējis.

Piemērojiet izmaiņas caur savienojuma īpašnieku un kontrolētā logā atjaunojiet asociāciju. Jau instalēts child saglabā pašreizējo iekapsulēšanu, līdz tas tiek aizstāts, tāpēc tikai datnes rediģēšana nepierāda, ka jaunā kārtība tiek izmantota.

Pārbaudiet ietītos datus, ne tikai portu

Notveriet uz vārtejas, kamēr plūst aizsargātā datplūsma, pēc tam salīdziniet to ar paša strongSwan skatījumu:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP parādās kā IP 50 protokols un nemaz neizskatās pēc UDP. Ietīts ESP parādās kā UDP datagrammas uz 4500, kuru krava nav IKE. IKE datplūsma tajā pašā portā nav iekapsulēšanas pierādījums, jo MOBIKE var pārvietot IKE turp, kamēr datu ceļš paliek native, tāpēc lasiet kravu, nevis porta numuru.

Paturiet prātā arī ceļa MTU. Ietvars pievieno papildu izmaksas, un ceļam, kas nesa native ESP, var būt nepieciešami pielāgojumi, kad pakojumi pieaug. Nepieciešamā ICMP apstrāde jau būtu jābūt dizaina daļai; iekapsulēšana šo atkarību nenovērš.

Pieņemiet izmaiņas, kad svaiga lietojumprogrammu datplūsma tuneļa iekšienē ir redzama tveršanā kā ietīts ESP abos galos un kad iekšējais pakalpojums un tā atpakaļceļš joprojām darbojas. Viss mazāk ir konfigurācija, kas datnē izskatās pareizi.

Saistītie raksti