L2TP/IPsec NATin läpi: mikä oikeasti hajoaa ja miksi

Väite, että NAT rikkoo L2TP/IPsecin, on puoliksi totta ja siksi hyödytön. Osoitteenmuunnos on normaalia, NAT-läpäisy on olemassa juuri sen läpikäymiseksi, ja miljoonat asiakkaat yhdistävät joka päivä reitittimen takaa. Rikki menee tietyn vaihdon tietty vaihe: IKE ei saa koskaan vastausta, kapseloitu tunneli pudotetaan käytännöllä, joka sallii vain yhden protokollan, tai muunnoskarttaus vanhenee, kun tunneli on joutilaana. Kun tiedät, missä vaiheessa olet, korjaus on yleensä yksi sääntö tai keepalive, ei uusi VPN-suunnittelu.

Myytti on väärä kysymys

Hyödyllinen kysymys ei ole ”rikkooko NAT tämän” vaan ”mikä osa vaihdosta muunnetaan ja mitä muuntava laite tekee sillä”. L2TP/IPsec on kerroksittainen protokolla: IKE neuvottelee, ESP suojaa, ja L2TP kuljettaa PPP:tä suojan sisällä. Osoitteenmuunnos vaikuttaa joka kerrokseen eri tavalla, ja vikojen allekirjoitukset erottuvat, jos katsot neuvotteluvaihetta etkä virhedialogia.

Reititin, joka selaa verkkoa onnistuneesti, todistaa vain, että TCP lähdeportin muunnoksella toimii. Se ei kerro mitään UDP 500:sta, UDP 4500:sta tai protokollasta 50, ja juuri näistä kolmesta tämä käyttöönotto riippuu.

Vaihe 1: IKE:n on ylipäätään saatava vastaus

Ensimmäinen vaihto menee vastaajalle UDP 500:ssa. Jos vastausta ei tule takaisin, mikään muu ei merkitse mitään: ennalta jaettu avain, ehdotus ja tunnistetiedot jäävät lukematta. Tarkkaile pyyntöä ja vastausta sen sijaan, että päättelet asiakkaan aikakatkaisusta:

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

Pyyntö ilman vastausta tarkoittaa yleensä, että palomuuri tai ylävirran operaattori pudottaa paketin, ei että palvelin hylkäsi sen. Vastaus, jonka ilmoituskuorma nimeää ehdotuksen tai varmenneongelman, tarkoittaa, että paketit saapuivat ja neuvottelu epäonnistui sisällön vuoksi, mikä on täysin eri korjaus.

Kun molemmat osapuolet ovat muunnoksen takana, aloittajan tarvitsee vain tavoittaa vastaaja, joten useimmat asiakaspuolen käyttöönotot toimivat vaiheesta 1. Palvelinpuolen ylläpito on paikka, jossa saapuvan liikenteen ongelma alkaa, ja siksi näitä kahta tilannetta ei pitäisi koskaan käsitellä yhtenä.

Vaihe 2: kapselointi muuttaa sitä, mitä palomuuri näkee

ESP on IP-protokolla, ei TCP- tai UDP-portti, eikä tavallisessa porttien osoitteenmuunnoksessa ole porttikenttää, jota kirjoittaa uudelleen. Siksi NAT-läpäisy siirtää suojatun hyötykuorman UDP 4500:aan: kapselointi antaa muuntavalle laitteelle jotain, jonka se osaa muuntaa. Kun niin tapahtuu, vain UDP 500:lle kirjoitettu palomuurisääntö sallii neuvottelun ja pudottaa tunnelin, mikä tuottaa hämmentävän tuloksen, jossa loki näyttää onnistuneen vaiheen 1 eikä lainkaan liikennettä.

Itse IKE-vaihto voi myös siirtyä UDP 4500:aan, kun NAT havaitaan, mikä yllättää ne, jotka sallivat 500 eivätkä muuta. Salli molemmat portit molempiin suuntiin polulla, ja muista, että tilallinen palomuuri pitää virran vain niin kauan kuin näkee liikennettä.

Protokolla 50 on edelleen tärkeä poluilla ilman muunnosta ja poluilla, joilla välilaite on määritetty sallimaan se. Jos diagnosoit poissulkemalla, kytke hypoteesi pois sen sijaan, että lisäisit sääntöjä kasoittain: salli 500, 4500 ja ESP, vahvista että tunneli nousee, ja poista sitten se, mikä osoittautui tarpeettomaksi. Sääntö, jota kukaan ei osaa selittää, on sääntö, jota kukaan ei poista, kun siitä tulee seuraavan katkoksen syy. Kirjaa kavennus muutoslokiin yhdessä korjatun vaiheen kanssa, jotta seuraava insinööri aloittaa todisteistasi eikä samasta peukalosäännöstä.

Vaihe 3: kartoitus vanhenee ja tunneli kuolee

Muuntava laite pitää tilaa välittämilleen virroille, ja sillä tilalla on elinikä. L2TP/IPsec-tunneli kuljettaa vähän liikennettä, kun kukaan ei käytä sitä, joten joutilas tunneli voi elää kartoituksensa ohi ja lakata vastaanottamasta paluuliikennettä. Asiakas pysyy vakuuttuneena yhteydestä, palvelin ei näe mitään, ja ensimmäinen oire on yleensä sovelluksen aikakatkaisu eikä VPN-virhe.

Kuolleen vastapuolen tunnistus ja NAT-keepalivet ovat juuri tätä varten, ja molempien päiden on oltava valmiita lähettämään niitä. Jos palvelimesi on muunnoksen takana, Windowsin puolen vaatimus on dokumentoitu rekisteriasetus, joka saa palvelimen olettamaan UDP-kapseloinnin omille lähteville paketeilleen; ilman sitä vastaaja lähettää ESP:tä, jota muuntava laite ei voi kartoittaa takaisin. Se on palvelimen kokoonpanoasia, ei asiakkaan.

WAN-osoitteen muutos tuottaa saman tuloksen toisesta suunnasta: kartoitus rakennetaan uudelleen uuden osoitteen ympärille, ja vanha tietoturvayhteys osoittaa nyt monikkoon, jota ei enää ole. Uudelleenyhdistämiskäyttäytyminen kuuluu asiakastoteutukseen, ja siksi ”yhdistä uudelleen reitittimen uudelleenkäynnistyksen jälkeen” toimii yhdellä asiakkaalla ja vaatii toisella käsisäätöä.

Ylläpito operaattoritason NATin takana on eri ongelma

Jos haluat ylläpitää L2TP/IPsec-palvelinta kotona ja tavoittaa sen ulkopuolelta, vaatimuksena on pyytämätön saapuva tavoitettavuus, eikä sitä NAT-läpäisy tarjoa. Operaattoritason NAT reitittimesi edessä tarkoittaa, että ei ole porttia, jonka edelleenohjauksella voisit tulla tavoitettavaksi, koska julkinen osoite on jaettu ja kartoitus on vain lähtevä.

Mikään IPsec pass-through -valintaruutu ei muuta sitä, eikä mikään asiakaskokoonpano korvaa sitä. Tuetut vastaukset ovat osoite, joka on oikeasti tavoitettavissa, ylläpidetty päätepiste tai arkkitehtuuri, jossa jokainen osallistuja tekee lähtevän yhteyden. UDP-kapseloinnin määritelmä ratkaisee muunnosongelman virroille, joita on olemassa; se ei luo saapuvaa polkua sinne, missä operaattori ei tarjoa sellaista.

Vertaile siis verkkoja sen sijaan, että arvailet. Vie sama laite ja profiili toiseen sallittuun verkkoon ja katso, mikä vaihe siellä epäonnistuu. Jos se toimii muualla, ero on polussa, ja se rajaa haun kolmeen yllä olevaan vaiheeseen koko kokoonpanon sijaan.