L2TP/IPsec NAT bidez: zer hausten den benetan eta zergatik

NATek L2TP/IPsec hausten duela dioen baieztapena erdi egia da eta, beraz, alferrikakoa. Helbideen itzulpena normala da, NAT traversal hain zuzen hori gainditzeko dago, eta milioika bezero konektatzen dira egunero router baten atzetik. Hausten dena truke jakin baten etapa jakin bat da: IKEk ez du inoiz erantzunik jasotzen, tunel kapsulatua protokolo bakarra baimentzen duen politikak baztertzen du, edo itzulpen-mapatzea tunela inaktibo dagoen bitartean iraungitzen da. Zein etapan zauden jakinda, konponketa normalean arau bat edo keepalive bat izaten da, ez VPN diseinu berri bat.

Mitoa da galdera okerra

Galdera erabilgarria ez da ea NATek hau hausten duen, baizik eta trukearen zein atal itzultzen den eta itzultzen duen gailuak harekin zer egiten duen. L2TP/IPsec geruzatutako protokoloa da: IKEk negoziatzen du, ESPk babesten du, eta L2TP PPP eramaten du babes horren barruan. Helbide-itzulpenak modu desberdinean eragiten dio geruza bakoitzari, eta hutsegiteen sinadurak bereiz daitezke negoziazio-etapa begiratzen baduzu, errore-leihoa beharrean.

Webguneak ondo arakatzen dituen router batek soilik frogatzen du jatorrizko atakako itzulpena duen TCPk funtzionatzen duela. Ez du ezer esaten UDP 500, UDP 4500 edo 50 protokoloaz, eta inplementazio hau hiru gauza horien mende dago.

Etapa 1: IKEk erantzunen bat jaso behar du

Lehen trukea UDP 500eko erantzulearengana doa. Erantzunik itzultzen ez bada, gainerako guztiak ez du axola: aldez aurretik partekatutako gakoa, proposamena eta kredentzialak irakurri gabe geratzen dira. Begiratu eskaera eta erantzuna, bezeroaren denbora-mugaren arabera ondorioztatu beharrean:

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

Erantzunik gabeko eskaerak esan nahi du normalean suebaki batek edo goiko operadoreak paketea botatzen duela, ez zerbitzariak baztertu duenik. Proposamen bat edo ziurtagiri-arazo bat aipatzen duen jakinarazpen-karga duen erantzunak esan nahi du paketeak iritsi zirela eta negoziazioa edukiagatik huts egin zuela, eta hori oso konponketa desberdina da.

Bi muturrak itzulpenaren atzean daudenean, hasieratzaileak erantzulearengana iritsi behar du soilik, beraz bezeroaren aldeko inplementazio gehienek etapa 1etikik funtzionatzen dute. Zerbitzariaren aldeko ostatatzea da sarrerako arazoa hasten den lekua, eta horregatik bi egoerak ez dira inoiz bat bezala eztabaidatu behar.

Etapa 2: kapsulatzeak aldatzen du suebakiak ikusten duena

ESP IP protokoloa da, ez TCP edo UDP ataka, eta ataken helbide-itzulpen arruntak ez du berridazteko ataka-eremurik. Horregatik NAT traversalak babestutako karga UDP 4500era eramaten du: kapsulatzeak itzultzen duen gailuari itzultzen dakien zerbait ematen dio. Hori gertatzen denean, UDP 500erako soilik idatzitako suebaki-arau batek negoziazioa baimendu eta tunela baztertzen du, eta horrek emaitza nahasia sortzen du: erregistroak fase 1 arrakastatsua erakusten du eta trafiko ezer ez.

IKE trukea bera ere UDP 4500era pasa daiteke NAT bat detektatu ondoren, eta horrek harritzen ditu 500 eta besterik ez dutenak baimendu. Baimendu bi atakak bi noranzkoetan bidean, eta gogoratu egoeradun suebaki batek fluxua trafikoa ikusten duen bitartean soilik eutsi dezakeela.

50 protokoloak garrantzia du oraindik itzulpenik gabeko bideetan, eta tarteko kaxa bat baimentzeko konfiguratuta dagoen bideetan. Bazterketaz diagnostikatzen baduzu, desaktibatu hipotesia arauak multzoka gehitu beharrean: baimendu 500, 4500 eta ESP, egiaztatu tunela igotzen dela, eta gero kendu beharrezkoa ez zena. Inork azaldu ezin duen araua hurrengo etena eragin zuenean inork kenduko ez duen araua da. Idatzi estutzea aldaketen erregistroan konpondu zuen etaparekin batera, hurrengo ingeniariak zure frogak abiapuntu izan ditzan, erpuru-arau beretik beharrean.

Etapa 3: mapatzea iraungi eta tunela hiltzen da

Itzultzen duen gailuak berbidaltzen dituen fluxuen egoera gordetzen du, eta egoera horrek bizitza-muga du. L2TP/IPsec tunelak trafiko gutxi daramatza inork erabiltzen ez duenean, beraz tunel inaktibo batek bere mapatzea gaindi dezake eta itzuli-trafikoa jasotzeari utz diezaioke. Bezeroak konektatuta dagoela sinetsita jarraitzen du, zerbitzariak ezer ez du ikusten, eta lehen sintoma normalean aplikazio baten denbora-muga izaten da, ez VPN errorea.

Pare hilaren detekzioa eta NAT keepaliveak horretarako daude, eta bi muturrek bidaltzeko prest egon behar dute. Zure zerbitzaria itzulpenaren atzean badago, Windows aldeko baldintza erregistro-ezarpen dokumentatu bat da, zerbitzariak bere irteerako paketeetarako UDP kapsulatzea suposa dezan; horren gabe, erantzuleak ESP bidaltzen du eta itzultzen duen gailuak ezin du atzera mapatu. Zerbitzariaren konfigurazio kontua da, ez bezeroarena.

WAN helbidearen aldaketak emaitza bera ematen du beste norabide batetik: mapatzea helbide berri baten inguruan berreraikitzen da, eta segurtasun-elkartze zaharrak jada existitzen ez den tupla bat seinalatzen du. Berriz konektatzeko jokabidea bezeroaren inplementazioaren parte da, eta horregatik «routerra berrabiarazi ondoren berriro konektatu» bezero batean funtzionatzen du eta beste batean eskuzko etengailua behar du.

Operadore-mailako NAT baten atzean ostatatzea beste arazo bat da

Etxean L2TP/IPsec zerbitzari bat ostatatu eta kanpotik bertara iritsi nahi baduzu, baldintza eskatu gabeko sarrerako irisgarritasuna da, eta hori ez da NAT traversalak eskaintzen duena. Zure routerraren aurrean operadore-mailako NAT bat egoteak esan nahi du ez dagoela birbidal dezakezun atakarik zu irisgarri egiteko, helbide publikoa partekatua delako eta mapatzea irteerakoa soilik.

IPsec pass-through lauki batek ere ez du hori aldatzen, eta bezeroaren konfigurazio kopuruak ez du hori konpentsatzen. Onartutako erantzunak benetan irisgarria den helbide bat, ostatatutako amaiera-puntu bat edo partaide bakoitzak irteerako konexio bat egiten duen arkitektura bat dira. UDP kapsulatzearen zehaztapena existitzen diren fluxuetarako itzulpen-arazoa konpontzen du; ez du sarrerako biderik sortzen operadoreak bat eskaintzen ez duen tokian.

Beraz, konparatu sareak asmatu beharrean. Eraman gailu eta profila berdinak baimendutako beste sare batera eta begiratu zein etapatako huts egiten duen han. Beste leku batean funtzionatzen badu, aldea bidean dago, eta horrek goiko hiru etapetara murrizten du bilaketa, konfigurazio osoa ordez.