Zein VPN-etapa huts egin du: IPsec, L2TP kontrola edo PPP autentifikazioa
Aurkitu arrakasta izan zuen azken etapa eta konpondu soilik geruza hori: IPsec, L2TP kontrol-kanala, PPP autentifikazioa edo helbide-esleipena.
Pasahitza aldatu duzu eta ezer ez da mugitu, porrota inoiz ez baitzegoen PPPn. L2TP/IPsec konexio-errore bakarra jakinarazten du bost entrega erabat desberdinetarako, eta entrega bakoitzak bere konponketa du. Alderantziz lan egin: aurkitu arrakasta izan zuen azken etapa eta aldatu soilik ondoren datorrena. Beheko ordenak ere erabakitzen du zein froga bilduko duzun lehenengo.
Erantzun lau galderari ordenan
Behartu saiakera berri bat, bezero batzuek aurreko errorea erakusten jarraitzen baitute profila deskonektatu eta berriro konektatu arte. Ondoren erantzun hau: IPsec segurtasun-elkarte bat zegoen, L2TP kontrol-konexio bat eta dei bat agertu ziren, PPP autentifikazio-epai batera iritsi zen, eta IPCPk helbide bat eman zion bezeroari? Lehen eza konpontzen duzun etapa da. Haren ondorengo guztia probatu gabe dago, beraz errefusatutako erabiltzaile-izenak ezer ez du frogatzen elkarterik inoiz egon ez bazen.
Sinkronizatu erlojuak bi muturretan alderatu aurretik. IPsec garbitu eta PPPn huts egin zuen berrizko saiakera porrot bakar bat bezala ikusten da bezeroak azken mezua soilik erakusten duenean eta zerbitzariaren erregistroak aurreko saiakera oraindik gordetzen duenean. Irakurri denbora-markaren arabera, ez lerro ozenenaren arabera.
Erabiltzailearen pantaila-argazkia baino ez duzunean, eginbide merkeenaren gainean jarri: aurrez partekatutako gako oker batek eta inoiz erantzuten ez duen xl2tpd batek Windows elkarrizketan testu bera sortzen dute, baina batek bi muturretan aldatutako sekretua behar du eta besteak zerbitzarian bertan abiatutako daemon edo suebaki-arau bat. Erdiko gailu batek ezin du barneko 1701 bota IPsec garraio-moduak bildu ondoren, beraz ez bilatu existitzen ez den bide-iragazki bat.
Zer duen geruza bakoitzak benetan
IPsec-ek bi pareen arteko paketeak babesten ditu; L2TPk PPP saio bat darama bide babestu horren barruan, horregatik RFC 3193 garraio-modua zehazten du bere tunel propioa beharrean. Bezeroaren etiketak L2TP dio, beraz tunela eta saioa hasteko ekintza mekanismo bakar bat ematen dute. Ez dira: L2TP kontrol-konexioak tunelaren muturrak autentifikatzen ditu hedapenak gaitzen duen lekuan, eta PPPk erabiltzailea bereiz autentifikatzen du CHAP, PAP edo MS-CHAPv2 erabiliz zerbitzariaren politikaren arabera.
Bereizketa horrek jendeak nahasten dituen bi sekretuak azaltzen ditu. Aurrez partekatutako gako batek IPsec pareak autentifikatzen ditu. Erabiltzaile-izenak eta pasahitzak erabiltzailea PPPren aurrean identifikatzen dute. Sertifikatuekin autentifikatzen den profilean Windows-en sekretu partekatua berriz idazteak ez du ezer aldatzen huts egiten duen etapan, eta PPP pasahitza editatzeak ezin du falta den kanal babesturik eman. Uzkurtasun berak aplikatzen zaio identitate-egiaztapenari: ez desgaitu parearen identitatea edo ziurtagiriaren balidazioa tunel bat lortzeko, orduan bidea konektatzen baita, ez parea.
Autentifikazioa ere ez da PPPren amaiera. Erabiltzailea onartu ondoren, IPCPk bezeroaren helbidea eta zerbitzariak emateko prest dauden DNS eta WINS aukerak negoziatzen ditu. Bezeroak CHAP edo MS-CHAPv2 gaindi dezake eta helbiderik gabe geratu, eta hori PPPren barruko porrota da, ez bideratze-arazoa. IPsec gabeko L2TP soila baliozkoa eta babesgabea izaten jarraitzen du, beraz konexio arrakastatsuak ez du inoiz frogatzen trafikoa babestuta dagoenik; egiaztatu zer eskatzen duen zerbitzariak, ez bezeroaren etiketak.
Erabaki falta den lehen etaparen arabera
Irakurri taula lehen falta den elementuaren arabera, ezkerretik eskuinera. Eskuineko zutabea da une horretan merezi duen lan bakarra; haren ezkerreko guztia jada frogatuta dago, eta berriro probatzeak etenaldi-leihoa erreko du informazioa gehitu gabe.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Hiru errek balio dute abisu bat. 1701 errea da Windows bezeroak NAT atzean normalean lurreratzen diren tokia: elkartea osatzen da, gero ezer ez da iristen, eta kapsulatzea da arrazoia, ez pasahitz txarra. IPCP errea da bide-arazo gisa gaizki irakurtzen dena, Windows-ek falta den helbidea 720 errorean biltzen duelako eta erretiluko ikonoak konexioak huts egin duela baino ez duelako esaten; porrot hori autentifikazioaren ondoren eta bideratzearen aurretik dago. Azken errea ez da inolako IPsec porrota, erretiluko ikonoak deskonektatuta dioen arren.
Geruzak bereizten dituzten komandoak
strongSwan duen Linux zerbitzari batean, swanctl --list-sas komandoak ezarritako elkarteak zerrendatzen ditu parearen identitatearekin, eta ipsec statusall komandoak strongSwan eta libreswan ostalari zaharrak estaltzen ditu. Azpian, ip xfrm state komandoak kernelaren benetako elkarteak erakusten ditu, eta ss -lunp | grep 1701 komandoak frogatzen du non dagoen lotuta xl2tpd. Exekutatu xl2tpd -D aurreko planoan kontrol-konexioak eta deiak agertzen ikusteko, eta gaitu pppd arazketa /etc/ppp/options.xl2tpd fitxategian eskaintzen den metodoa eta erantzuna ikusteko.
Erregistzoek autentifikazio arrakastatsua erakusten dutenean, hurrengo galdera IPCP osatu ote zen da. Egiaztatu /etc/xl2tpd/xl2tpd.conf fitxategiko [lns default] ataleko ip range komandoak oraindik helbide libreak dituen, eta /etc/ppp/options.xl2tpd fitxategiak benetan ms-dns eta ms-wins daramatzan bezeroak espero baditu. Multzo agortu batek eta falta den DNS aukera batek desberdin ikusten dute kablean: lehenak bezeroa helbiderik gabe eta 720 batekin uzten du, bigarrenak helbidea baina resolverrik ez, beraz izenek huts egiten dute helbide gordinetara egindako ping-ek lan egiten duten bitartean. Biak ez dira konpontzen pasahitza berriz sartuta.
Bezeroan, NetworkManager-en L2TP pluginak pppd-ren elkarrizketa egunkarian idazten du, beraz journalctl -u NetworkManager -b komandoak normalean tunela gora, autentifikazioa ukatu eta tunelik ez bereizten ditu. Windows-en, Get-VpnConnection komandoak profileko benetako autentifikazio-ezarpenak jakinarazten ditu, eta Event Viewer-en Application azpiko RasClient gertaerek huts egiten duen osagaia izendatzen dute. Elkarrizketa oso lausoa denean, gaitu netsh ras set tracing * enable.
Harrapaketek zuhurtzia bat behar dute. IPsec garraio-moduan barneko UDP 1701 zifratuta dago, beraz kanpoko interfazean egindako harrapaketak ESP erakusten du, edo UDP 4500 NAT-T pean, eta ez du L2TPrik erakusten. Harrapaketa batean 1701 falta izatea espero da eta ez da blokeatutako ataka baten froga; begiratu ESP edo 4500 kontagailuak mugitzen diren.
NAT, MTU eta bideak: non engainatzen zaituen pilak
NATek ustekizunak hausten ditu ezer autentifikatu aurretik. ESP bere IP protokoloa da, beraz itzultzen duen gailu batek baztertu egiten du pareek kapsulatu ezean; hori da UDP 4500-ek ematen duena. Etxeko router baten edo hodeiko NAT ate baten atzean dagoen Windows zerbitzari batean, IPsec etapek 789 errorearekin huts egiten du AssumeUDPEncapsulationContextOnSendRule PolicyAgent giltzaren pean 2ra ezarri eta makina berrabiarazi arte, eta porrotak ataka itxi batetatik bereiztezina izaten jarraitzen du. NAT atzeko bezeroak errazagoak dira: zerbitzarian helbide publikoa badago, UDP 4500 gaineko NAT-Tk garraiatzen ditu eta balio hori ez dago tartean.
PPP gora dagoenean, zulo beltzeko MTU batek tunel hil bat imitatzen du: pakete txikiak igarotzen dira, TLS eskuko keinu bat edo orri-karga bat zintzilik geratzen dira, eta bezeroak oraindik konektatuta erakuts dezake. Jaitsi interfazearen MTU edo estutu MSS atarian zerbitzaria errudun egin aurretik. Tuneletan banatutako bideratzea da beste iruzurtia; maskara okerrarekin bidalitako azpisare batek tunela osasuntsu uzten du eta aplikazio bat iristezin. Ostalari-izen pribatu batek bere jauzia gehitzen du: kontsulta resolver lokaletik irteten bada, izenak huts egiten du edozein bide probatu aurretik.
Egiaztapen-zerrenda kredentzialak ukitu aurretik
Egin zerrenda ordenan eta gelditu huts egiten duen lehen elementuan. Urrats bakoitza merkea da, eta bakoitzak aldaketen klase oso bat baztertzen du.
- Egiaztatu elkartea bi muturretan dagoela, parearen identitatearen arabera parekatuta, ez konektatuta etiketa baten arabera.
- Egiaztatu UDP 1701 xl2tpd-ra iristen dela; deirik gabeko elkartea da zure porrota.
- Irakurri PPPren epaia, eta autentifikatu bazen, IPCPren emaitza, pasahitza okerra dela suposatu aurretik.
- Orain soilik sartu berriro kredentzialak zerbitzariak espero duen formatuan, domeinu-aurrizki batek kontua aldatzen baitu.
- Oraindik huts egiten badu, harrapatu bi muturrak lerrokatutako denbora-markekin eta alderatu etapa etapa.
Bigarren urratsean gelditzeak bide edo kapsulatze arazo bat esan nahi du, eta pasahitzaren edozein aldaketak ez du hura mugituko. Hirugarren urratsean gelditzeak erregistroak jada konpondu beharreko metodoa edo helbide-multzoa izendatzen duela esan nahi du. Edonola ere hurrengo aldaketa justifika dezakezun bat da, eta inoiz tartean egon ez diren ezarpenen artean ibiltzeari uzten diozu.