Cila fazë e VPN dështoi: IPsec, kontrolli L2TP apo vërtetimi PPP

Ndryshuat fjalëkalimin dhe asgjë nuk lëvizi, sepse defekti nuk ishte kurrë në PPP. L2TP/IPsec raporton një gabim lidhjeje për pesë dorëzime krejt të ndryshme, dhe çdo dorëzim ka riparimin e vet. Punoni mbrapsht: gjeni fazën e fundit të suksesshme dhe ndryshoni vetëm atë që vjen pas saj. Rendi më poshtë vendos gjithashtu cilat prova mblidhni së pari.

Përgjigjuni katër pyetjeve sipas radhës

Detyroni një provë të re, sepse disa klientë vazhdojnë të shfaqin gabimin e mëparshëm derisa profili të shkëputet dhe të rilidhet. Më pas përgjigjuni kësaj: a kishte shoqatë sigurie IPsec, a u shfaqën një lidhje kontrolli L2TP dhe një telefonatë, a arriti PPP në një verdikt vërtetimi dhe a i dha IPCP klientit një adresë? Joja e parë është faza që rregulloni. Gjithçka pas saj është e paprovuar, kështu që një emër përdoruesi i refuzuar nuk provon asgjë kur shoqata nuk ekzistoi kurrë.

Sinkronizoni orët në të dy skajet përpara se të krahasoni. Një provë e re që pastroi IPsec dhe dështoi në PPP duket si një defekt i vetëm kur klienti shfaq vetëm mesazhin e fundit dhe regjistri i serverit ende mban provën e mëparshme. Lexoni sipas vulës kohore, jo sipas rreshtit më të zhurmshëm.

Kur keni vetëm pamjen e ekranit të përdoruesit, mbështetuni te ndarja më e lirë: një çelës i ndarë paraprakisht i gabuar dhe një xl2tpd që nuk përgjigjet kurrë prodhojnë të njëjtin tekst në dialogun e Windows, por njëri kërkon një sekret të ndryshuar në të dy skajet dhe tjetri një demon të nisur ose një rregull firewalls në vetë serverin. Një pajisje në mes nuk mund ta hedhë poshtë 1701 e brendshme pasi IPsec në modalitetin transport e ka mbështjellë, prandaj mos kërkoni një filtër rruge që nuk ekziston.

Çfarë zotëron në të vërtetë secila shtresë

IPsec mbron paketat midis dy partnerëve; L2TP transporton një sesion PPP brenda asaj rruge të mbrojtur, prandaj RFC 3193 përcakton modalitetin transport dhe jo një tunel të vetin. Etiketa e klientit thotë L2TP, kështu që tuneli dhe hyrja duken si një mekanizëm. Nuk janë: lidhja e kontrollit L2TP vërteton skajet e tunelit aty ku vendosja e aktivizon, dhe PPP vërteton përdoruesin veçmas me CHAP, PAP ose MS-CHAPv2 sipas politikës së serverit.

Kjo ndarje shpjegon dy sekretet që njerëzit vazhdojnë t'i ngatërrojnë. Një çelës i ndarë paraprakisht vërteton partnerët IPsec. Emri i përdoruesit dhe fjalëkalimi identifikojnë përdoruesin para PPP. Rishkrimi i sekretit të përbashkët të Windows në një profil që vërteton me certifikata nuk ndryshon asgjë në fazën që dështon, dhe redaktimi i fjalëkalimit PPP nuk mund të sigurojë një kanal të mbrojtur që mungon. I njëjti përmbajtje vlen për kontrollin e identitetit: mos fikni identitetin e partnerit ose validimin e certifikatës për të marrë një tunel, sepse atëherë lidhet rruga, jo partneri.

As vërtetimi nuk është fundi i PPP. Pasi përdoruesi pranohet, IPCP negocion adresën e klientit dhe opsionet DNS e WINS që serveri është i gatshëm të japë. Një klient mund të kalojë CHAP ose MS-CHAPv2 dhe prapë të mbetet pa adresë, që është defekt brenda PPP dhe jo problem rrugëtimi. L2TP i thjeshtë pa IPsec mbetet i vlefshëm dhe i pambrojtur, prandaj një lidhje e suksesshme nuk provon kurrë se trafiku është i mbrojtur; kontrolloni çfarë kërkon serveri, jo etiketën e klientit.

Vendosni nga faza e parë që mungon

Lexoni tabelën sipas elementit të parë që mungon, nga e majta në të djathtë. Kolona e djathtë është e vetmja punë që vlen në atë moment; gjithçka në të majtë të saj është provuar tashmë, dhe riprovimi djeg dritaren e ndërprerjes pa shtuar informacion.

Tre rreshta meritojnë një paralajmërim. Rreshti 1701 është vendi ku klientët Windows pas NAT zakonisht ulen: shoqata plotësohet, pastaj nuk arrin asgjë, dhe shkaku është inkapsulimi, jo një fjalëkalim i keq. Rreshti IPCP është ai që lexohet gabimisht si problem rruge, sepse Windows e mbështjell adresën që mungon në gabimin 720 dhe ikona e tabaka thotë vetëm se lidhja dështoi; ai defekt ndodhet pas vërtetimit dhe para rrugëtimit. Rreshti i fundit nuk është aspak defekt IPsec, edhe pse ikona thotë i shkëputur.

Komandat që ndajnë shtresat

Në një server Linux me strongSwan, swanctl --list-sas liston shoqatat e vendosura me identitetin e partnerit, dhe ipsec statusall mbulon hostet më të vjetra strongSwan dhe libreswan. Nën të, ip xfrm state tregon shoqatat reale të kernelit, ndërsa ss -lunp | grep 1701 provon ku është lidhur xl2tpd. Ekzekutoni xl2tpd -D në plan të parë për të parë lidhjet e kontrollit dhe telefonatat, dhe aktivizoni korrigjimin e pppd në /etc/ppp/options.xl2tpd për të parë metodën e ofruar dhe përgjigjen.

Kur regjistrat tregojnë vërtetim të suksesshëm, pyetja tjetër është nëse IPCP u plotësua. Kontrolloni nëse ip range në seksionin [lns default] të /etc/xl2tpd/xl2tpd.conf ka ende adresa të lira, dhe nëse /etc/ppp/options.xl2tpd vërtet mbart ms-dns dhe ms-wins nëse klienti i pret. Një pishinë e shteruar dhe një opsion DNS që mungon duken ndryshe në tel: i pari e lë klientin pa adresë dhe me 720, i dyti jep adresë por asnjë zgjidhës, kështu që emrat dështojnë ndërsa ping në adresa të papërpunuara funksionon. Asnjëra nuk rregullohet duke rishkruar fjalëkalimin.

Në klient, shtojca L2TP e NetworkManager shkruan bisedën e pppd në ditar, kështu që journalctl -u NetworkManager -b zakonisht ndan tuneli lart, vërtetimi i refuzuar nga asnjë tunel fare. Në Windows, Get-VpnConnection raporton cilësimet reale të vërtetimit të profilit, dhe ngjarjet RasClient nën Application në Event Viewer emërtojnë komponentin që dështon. Kur dialogu është shumë i paqartë, aktivizoni netsh ras set tracing * enable.

Regjistrimet kërkojnë një kujdes. Me IPsec në modalitetin transport, UDP 1701 e brendshme është e kriptuar, kështu që një regjistrim në ndërfaqen e jashtme tregon ESP, ose UDP 4500 nën NAT-T, dhe asnjë L2TP fare. Mungesa e 1701 në një regjistrim është e pritur dhe nuk është provë e një porte të bllokuar; vëzhgoni nëse numëruesit ESP ose 4500 lëvizin.

NAT, MTU dhe rrugë: ku stivi ju mashtron

NAT thyen supozimet përpara se çfarëdo të vërtetohet. ESP është protokolli i vet IP, prandaj një pajisje që përkthen e hedh poshtë nëse partnerët nuk inkapsulojnë; pikërisht këtë siguron UDP 4500. Në një server Windows që vetë qëndron pas një routeri shtëpiak ose një porte NAT në re, faza IPsec dështon me gabimin 789 derisa AssumeUDPEncapsulationContextOnSendRule të vendoset në 2 nën çelësin PolicyAgent dhe makina të riniset, dhe defekti mbetet i padallueshëm nga një port i mbyllur. Klientët pas NAT janë më të lehtë: me një adresë publike në server, NAT-T në UDP 4500 i transporton dhe ajo vlerë nuk përfshihet.

Pasi PPP është lart, një MTU me vrimë të zezë imiton një tunel të vdekur: paketat e vogla kalojnë, një shtrëngim duarsh TLS ose ngarkimi i një faqe ngec, dhe klienti mund të shfaqet ende i lidhur. Ulni MTU-n e ndërfaqes ose shtrëngoni MSS në portë përpara se të fajësoni serverin. Rrugëtimi i tunelit të ndarë është mashtruesi tjetër; një nënrrjet i shtyrë me maskë të gabuar e lë tunelin të shëndetshëm dhe një aplikacion të paarritshëm. Një emër host privat shton hapin e vet: nëse pyetja del përmes zgjidhësit lokal, emri nuk zgjidhet përpara se të provohet ndonjë rrugë.

Listë kontrolli përpara se të prekni kredencialet

Punoni listën sipas radhës dhe ndaloni te elementi i parë që dështon. Çdo hap është i lirë, dhe secili përjashton një klasë të tërë ndryshimesh.

1. Konfirmoni se shoqata ekziston në të dy skajet, e përputhur sipas identitetit të partnerit dhe jo sipas etiketës së lidhur.
2. Konfirmoni se UDP 1701 arrin në xl2tpd; një shoqatë pa telefonatë është defekti juaj.
3. Lexoni verdiktin e PPP dhe, nëse vërtetoi, rezultatin e IPCP, përpara se të supozoni se fjalëkalimi është i gabuar.
4. Vetëm tani rihyjnoni kredencialet në formatin që pret serveri, sepse një parashtesë domeni ndryshon llogarinë.
5. Nëse ende dështon, regjistroni të dy skajet me vula kohore të rreshtuara dhe krahasoni fazë për fazë.

Ndalimi në hapin e dytë do të thotë problem rruge ose inkapsulimi, dhe asnjë redaktim i fjalëkalimit nuk do ta lëvizë. Ndalimi në hapin e tretë do të thotë që regjistri emërton tashmë metodën ose pishinën e adresave për t'u rregulluar. Sido që të jetë, ndryshimi i radhës është një që mund ta justifikoni, dhe ndaloni së rrotulluari nëpër cilësime që nuk ishin përfshirë kurrë.