L2TP/IPsec läbi NAT-i: mis tegelikult katki läheb ja miks

Väide, et NAT rikub L2TP/IPsec-i, on poolenisti tõene ja seetõttu kasutu. Aadresside teisendamine on normaalne, NAT-i läbimine on olemas just selleks, et seda üle elada, ja miljonid kliendid ühenduvad iga päev ruuteri tagant. Katki läheb konkreetse vahetuse konkreetne etapp: IKE ei saa kunagi vastust, kapseldatud tunnel visatakse kõrvale poliitikaga, mis lubab ainult ühte protokolli, või teisendusvastendus aegub, kui tunnel on jõude. Kui teate, millises etapis olete, on parandus tavaliselt üks reegel või keepalive, mitte uus VPN-i disain.

Müüt on vale küsimus

Kasulik küsimus ei ole „kas NAT selle rikub“, vaid „milline osa vahetusest teisendatakse ja mida teeb sellega seade, mis teisendab“. L2TP/IPsec on kihiline protokoll: IKE peab läbirääkimisi, ESP kaitseb, ja L2TP kannab PPP-d selle kaitse sees. Aadresside teisendamine mõjutab iga kihti erinevalt ning rikete allkirju saab eristada, kui vaatate läbirääkimise etappi, mitte veadialoogi.

Ruuter, mis veebis edukalt sirvib, tõestab ainult seda, et TCP koos lähteporti teisendamisega töötab. See ei ütle midagi UDP 500, UDP 4500 ega protokoll 50 kohta, ja just neist kolmest see juurutus sõltub.

Etapp 1: IKE peab üldse vastuse saama

Esimene vahetus läheb vastajale UDP 500 kaudu. Kui vastust tagasi ei tule, ei loe miski muu: eelnevalt jagatud võti, pakkumine ja volitused jäävad lugemata. Jälgige päringut ja vastust, selle asemel et tuletada kliendi ajalõpust:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Vastuseta päring tähendab tavaliselt, et tulemüür või ülemvoolu operaator viskab paketi ära, mitte et server selle tagasi lükkas. Vastus, mille teavituskoormus nimetab pakkumist või sertifikaadi probleemi, tähendab, et paketid jõudsid kohale ja läbirääkimine ebaõnnestus sisu tõttu, mis on hoopis teine parandus.

Kui mõlemad pooled on teisenduse taga, peab algataja ainult vastajani jõudma, seega töötab enamik kliendipoolseid juurutusi etapist 1 alates. Serveripoolne majutus on koht, kus algab sissetulev probleem, ja seetõttu ei tohiks neid kahte olukorda kunagi käsitleda ühena.

Etapp 2: kapseldamine muudab seda, mida tulemüür näeb

ESP on IP-protokoll, mitte TCP või UDP port, ja tavalisel pordiaadresside teisendamisel pole pordivälja, mida ümber kirjutada. Seetõttu viib NAT-i läbimine kaitstud koormuse UDP 4500 sisse: kapseldamine annab teisendavale seadmele midagi, mida see oskab teisendada. Kui see juhtub, siis ainult UDP 500 jaoks kirjutatud tulemüürireegel lubab läbirääkimise ja viskab tunneli kõrvale, mis annab segadust tekitava tulemuse, kus logi näitab õnnestunud faasi 1 ja üldse mitte liiklust.

IKE vahetus ise võib samuti pärast NAT-i tuvastamist UDP 4500 peale liikuda, mis üllatab neid, kes lubasid 500 ja mitte midagi muud. Lubage mõlemad pordid mõlemas suunas teel, ja pidage meeles, et olekupõhine tulemüür hoiab voogu ainult seni, kuni näeb liiklust.

Protokoll 50 on endiselt oluline teedel ilma teisenduseta ja teedel, kus vahepealne seade on seatud seda lubama. Kui diagnoosite välistamise teel, lülitage hüpotees välja, selle asemel et lisada reegleid hunnikus: lubage 500, 4500 ja ESP, kinnitage, et tunnel tõuseb, seejärel eemaldage see, mis osutus tarbetuks. Reegel, mida keegi ei oska seletada, on reegel, mida keegi ei eemalda, kui sellest saab järgmise katkestuse põhjus. Kirjutage kitsendus muudatuste logisse koos etapiga, mille see parandas, et järgmine insener alustaks teie tõenditest, mitte samast rusikareeglist.

Etapp 3: vastendus aegub ja tunnel sureb

Teisendav seade hoiab olekut edastatavate voogude jaoks ja sellel olekul on eluiga. L2TP/IPsec tunnel kannab vähe liiklust, kui keegi seda ei kasuta, seega jõude tunnel võib oma vastenduse üle elada ja lakkab tagasiliiklust vastu võtmast. Klient jääb veendunuks, et on ühendatud, server ei näe midagi, ja esimene sümptom on tavaliselt rakenduse ajalõpp, mitte VPN-i viga.

Surnud partneri tuvastamine ja NAT-i keepalive on selle jaoks olemas ning mõlemad otsad peavad olema valmis neid saatma. Kui teie server on teisenduse taga, on Windowsi poolne nõue dokumenteeritud registriseade, mis paneb serveri eeldama UDP-kapseldamist oma väljuvate pakettide jaoks; ilma selleta saadab vastaja ESP-d, mida teisendav seade ei saa tagasi vastendada. See on serveri konfiguratsiooni, mitte kliendi küsimus.

WAN-aadressi muutus annab sama tulemuse teisest suunast: vastendus ehitatakse üles uue aadressi ümber ja vana turbeseos osutab nüüd ennikule, mida enam ei ole. Ühenduse taastamise käitumine kuulub kliendi juurutusele, mistõttu „ühenda uuesti pärast ruuteri taaskäivitust“ töötab ühel kliendil ja nõuab teisel käsitsi lülitit.

Operaatoritasandi NAT-i taga majutamine on teine probleem

Kui soovite L2TP/IPsec serverit kodus majutada ja sellele väljastpoolt ligi pääseda, on nõue soovimatu sissetulev kättesaadavus, ja seda NAT-i läbimine ei paku. Operaatoritasandi NAT teie ruuteri ees tähendab, et pole ühtegi porti, mille edasisuunamisega saaksite kättesaadavaks, sest avalik aadress on jagatud ja vastendus on ainult väljuv.

Ükski IPsec pass-through märkeruut ei muuda seda ja ükski kliendi konfiguratsioon ei korva seda. Toetatud vastused on aadress, mis on tegelikult kättesaadav, majutatud lõpp-punkt või arhitektuur, kus iga osaleja teeb väljuva ühenduse. UDP-kapseldamise spetsifikatsioon lahendab teisendusprobleemi voogude jaoks, mis on olemas; see ei loo sissetulevat teed seal, kus operaator seda ei paku.

Seega võrrelge võrke, mitte ärge oletage. Viige sama seade ja profiil teise lubatud võrku ja vaadake, milline etapp seal ebaõnnestub. Kui see töötab mujal, on erinevus teel, ja see kitsendab otsingu kolmele ülaltoodud etapile, mitte kogu konfiguratsioonile.