L2TP/IPsec per NAT: kas iš tikrųjų lūžta ir kodėl

Teiginys, kad NAT sulaužo L2TP/IPsec, yra pusiau teisingas ir todėl nenaudingas. Adresų vertimas yra normalus dalykas, NAT traversal egzistuoja būtent tam, kad jį išgyventų, ir milijonai klientų kasdien jungiasi iš už maršrutizatoriaus. Lūžta konkretus konkretaus apsikeitimo etapas: IKE niekada negauna atsakymo, inkapsuliuotas tunelis atmetamas taisyklės, leidžiančios tik vieną protokolą, arba vertimo susiejimas baigiasi, kol tunelis neaktyvus. Kai žinote, kuriame etape esate, pataisymas paprastai yra viena taisyklė arba keepalive, o ne naujas VPN dizainas.

Mitas yra neteisingas klausimas

Naudingas klausimas yra ne „ar NAT tai sugriauna“, o „kuri apsikeitimo dalis verčiama ir ką su ja daro verčiantis įrenginys“. L2TP/IPsec yra sluoksniuotas protokolas: IKE derasi, ESP apsaugo, o L2TP perduoda PPP tos apsaugos viduje. Adresų vertimas kiekvieną sluoksnį veikia skirtingai, o gedimo požymius galima atskirti, jei žiūrite į derybų etapą, o ne į klaidos dialogą.

Maršrutizatorius, kuris sėkmingai naršo internete, įrodo tik tai, kad TCP su šaltinio prievado vertimu veikia. Jis nieko nesako apie UDP 500, UDP 4500 ar 50 protokolą, o šis diegimas priklauso būtent nuo šių trijų dalykų.

1 etapas: IKE apskritai turi gauti atsakymą

Pirmasis apsikeitimas eina atsakikliui per UDP 500. Jei joks atsakymas negrįžta, visa kita nesvarbu: iš anksto bendrinamas raktas, pasiūlymas ir prisijungimo duomenys lieka neperskaityti. Stebėkite užklausą ir atsakymą, o ne spėkite iš kliento laiko limito:

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

Užklausa be atsakymo paprastai reiškia, kad užkarda arba tiekėjas aukščiau meta paketą, o ne kad serveris jį atmetė. Atsakymas su pranešimo naudinguoju kroviniu, kuriame nurodomas pasiūlymas ar sertifikato problema, reiškia, kad paketai atvyko ir derybos nepavyko dėl turinio, o tai visiškai kitas taisymas.

Kai abi pusės yra už vertimo, iniciatoriui tereikia pasiekti atsakiklį, todėl dauguma kliento pusės diegimų veikia nuo 1 etapo. Serverio pusės hostingas yra vieta, kur prasideda įeinanti problema, ir todėl šios dvi situacijos niekada neturėtų būti aptariamos kaip viena.

2 etapas: inkapsuliavimas keičia tai, ką mato užkarda

ESP yra IP protokolas, o ne TCP ar UDP prievadas, ir įprastas prievadų adresų vertimas neturi prievado lauko, kurį būtų galima perrašyti. Todėl NAT traversal perkelia apsaugotą krovinį į UDP 4500: inkapsuliavimas duoda verčiančiam įrenginiui tai, ką jis moka versti. Kai tai įvyksta, užkardos taisyklė, parašyta tik UDP 500, leis derybas ir atmes tunelį, o tai duoda klaidinančią situaciją, kai žurnale matomas sėkmingas 1 etapas ir jokio srauto.

Pats IKE apsikeitimas taip pat gali persikelti į UDP 4500, kai aptinkamas NAT, o tai nustebina tuos, kurie leido 500 ir nieko daugiau. Leiskite abu prievadus abiem kryptimis kelyje ir atminkite, kad būsenos užkarda srautą išlaiko tik tol, kol mato srautą.

50 protokolas vis dar svarbus keliuose be vertimo ir keliuose, kur tarpinė dėžutė sukonfigūruota jį leisti. Jei diagnozuojate šalinimu, išjunkite hipotezę, o ne dėkite taisykles krūvomis: leiskite 500, 4500 ir ESP, patvirtinkite, kad tunelis pakyla, tada pašalinkite tai, kas pasirodė nereikalinga. Taisyklė, kurios niekas negali paaiškinti, yra taisyklė, kurios niekas nepašalins, kai ji taps kitos avarijos priežastimi. Įrašykite susiaurinimą į pakeitimų žurnalą kartu su etapu, kurį ji pataisė, kad kitas inžinierius pradėtų nuo jūsų įrodymų, o ne nuo tos pačios nykščio taisyklės.

3 etapas: susiejimas baigiasi ir tunelis miršta

Verčiantis įrenginys saugo būseną perduodamiems srautams, ir ta būsena turi gyvavimo trukmę. L2TP/IPsec tunelis perduoda mažai srauto, kai niekas juo nesinaudoja, todėl neaktyvus tunelis gali pergyventi savo susiejimą ir nustoti gauti grįžtamąjį srautą. Klientas lieka įsitikinęs, kad yra prisijungęs, serveris nieko nemato, o pirmasis simptomas paprastai yra programos laiko limitas, o ne VPN klaida.

Mirusio partnerio aptikimas ir NAT keepalive egzistuoja tam, ir abu galai turi būti pasirengę juos siųsti. Jei jūsų serveris yra už vertimo, Windows pusės reikalavimas yra dokumentuotas registro nustatymas, dėl kurio serveris laiko, kad jo paties išeinantiems paketams taikomas UDP inkapsuliavimas; be jo atsakiklis siunčia ESP, kurio verčiantis įrenginys negali susieti atgal. Tai serverio konfigūracijos klausimas, o ne kliento.

WAN adreso pasikeitimas duoda tą patį rezultatą iš kitos pusės: susiejimas atkuriamas aplink naują adresą, o senoji saugumo asociacija dabar rodo į kortelę, kurios nebėra. Persijungimo elgsena priklauso kliento įgyvendinimui, todėl „prisijunk iš naujo po maršrutizatoriaus perkrovimo“ veikia viename kliente, o kitame reikia rankinio perjungiklio.

Hosteris už operatoriaus lygio NAT yra kita problema

Jei norite namuose talpinti L2TP/IPsec serverį ir pasiekti jį iš išorės, reikalavimas yra neprašomas įeinantis pasiekiamumas, ir to NAT traversal nesuteikia. Operatoriaus lygio NAT prieš jūsų maršrutizatorių reiškia, kad nėra prievado, kurį galėtumėte persiųsti ir tapti pasiekiami, nes viešasis adresas yra bendrinamas, o susiejimas tik išeinantis.

Jokia IPsec pass-through varnelė to nepakeis, ir jokia kliento konfigūracija to nekompensuos. Palaikomi atsakymai yra tikrai pasiekiamas adresas, talpinamas galinis taškas arba architektūra, kurioje kiekvienas dalyvis užmezga išeinantį ryšį. UDP inkapsuliavimo specifikacija išsprendžia vertimo problemą esamiems srautams; ji nesukuria įeinančio kelio ten, kur operatorius jo nesiūlo.

Todėl lyginkite tinklus, o ne spėliokite. Nuneškite tą patį įrenginį ir profilį į kitą leidžiamą tinklą ir pažiūrėkite, kuris etapas ten nepavyksta. Jei kitur veikia, skirtumas yra kelyje, ir tai susiaurina paiešką iki trijų etapų aukščiau, o ne visos konfigūracijos.