Përse PPTP dhe L2TP/IPsec ndalen përpara kërkesës për emrin e përdoruesit?

Mungesa e kërkesës për emrin e përdoruesit është një dhuratë diagnostikuese: PPP nuk është nisur ende, prandaj llogaria, fjalëkalimi dhe politika e domenit nuk janë pyetur ende. Në një lidhje PPTP ose L2TP/IPsec klienti kërkon kredencialet vetëm pasi tuneli ekziston dhe serveri ka nisur një sesion PPP. Gjithçka që mund të dështojë para atij momenti është transport, shkëmbim çelësash ose konfigurim tuneli, një sipërfaqe shumë më e vogël se «VPN-ja është prishur».

Një kërkesë që mungon e kufizon defektin në tri faza

Shkruani fazën e fundit që pati sukses të dukshëm, sepse secila ka pronar dhe zgjidhje të ndryshme. Të hamendësosh cilësimet e llogarisë ndërsa je i bllokuar dy faza më parë është mënyra se si humbet një pasdite.

Një klient që skadon pa kërkesë nuk mori kurrë një asociacion IPsec, prandaj defekti është në IKE ose në faktin nëse paketat e tua arrijnë fare te porta. Ai që raporton se po verifikon kredencialet dhe pastaj bie ka shkuar më larg nga sa sugjeron mesazhi. Një kërkesë e ndjekur nga një refuzim është vërtetim PPP, dhe kjo i përket një artikulli për llogarinë, jo këtij.

Faza e parë: protokolli që një firewall e hedh në heshtje

PPTP ka nevojë për TCP 1723 për kanalin e kontrollit dhe protokollin IP 47 për rrugën e të dhënave, dhe të dy udhëtojnë veçmas. Shumë rrjeta përcjellin 1723 dhe hedhin protokollin 47, gjë që krijon një tunel që negocion dhe pastaj nuk mbart asgjë. Një router që bën NAT ka nevojë edhe për një kalim me mbështetje GRE, dhe një rrugë aksesi vetëm IPv6 nuk mund të mbartë PPTP në asnjë konfigurim.

L2TP mbi IPsec shpenzon portin 500 për IKE dhe portin 4500 për kalimin e NAT, pastaj e mbështjell vetë trafikun L2TP në 1701, ndërsa ESP mbart ngarkesën e mbrojtur sapo asociacioni ekziston. Lejo dy portat e kontrollit por jo ESP, dhe do të marrësh saktësisht simptomën e titullit: përparim i dukshëm, pastaj një klient i vdekur përpara çdo dialogu kredencialesh. Testimi nga një hotspot telefoni është një mënyrë e lirë për të ndarë një problem klienti nga një problem rruge.

Faza e dytë: një çelës që nuk është çelësi, një propozim që nuk ofrohet

Një çelës i përbashkët paraprak që nuk përputhet dështon shpejt dhe në heshtje, dhe versioni i zakonshëm është një çelës që duket i saktë në ekran ndërsa mban një thyerje rreshti të ngjitur ose një hapësirë në fund. Në një klient Linux dialogu nuk është domosdoshmërisht burimi i së vërtetës: shtojca L2TP e NetworkManager mban sekretet në skedarë nën /etc/ipsec.d/, dhe një skedar më i vjetër për çdo lidhje që /etc/ipsec.secrets ende përfshin do të përdoret në vend të atij që sapo shtypët. Kopjoje atë skedar në një vend të sigurt, hiqe nga rruga e përfshirjes dhe pastaj shtype çelësin përsëri me dorë.

Gjysma tjetër e kësaj faze është propozimi. Të dy skajet duhet të bien dakord për të njëjtin grup algoritmesh të fazës 1 — kriptim, integritet dhe grup Diffie-Hellman — dhe për transformime ESP që përputhen për fazën 2, përndryshe asociacioni nuk formohet fare. Një portë që ofron vetëm 3DES, SHA1 dhe MODP1024 do të refuzojë një klient të konfiguruar për algoritme më të fortë, dhe regjistri i saj emërton transformimin e refuzuar. Regjistri emërton mospërputhjen nëse e lexon në vend që ta rinisësh shërbimin edhe një herë. Në vend që të kopjosh një varg algoritmesh nga një temë forumi, pyet portën se për cilat transformime do të negociojë vërtet: ike-scan i drejtuar nga adresa e saj kthen transformimet për të cilat do të negociojë. Nëse oferta e vetme është kriptografi që politika jote nuk e lejon më, korrigjimi i përket portës, jo një degradimi të klientit.

Në Windows çelësi dhe metoda e vërtetimit jetojnë në profilin VPN, dhe një mospërputhje shfaqet përpara kërkesës së kredencialeve dhe jo pas saj. Kur marrësi është një Windows Server, konfirmo që roli i aksesit në distancë është instaluar, që certifikata përputhet me emrin me të cilin lidhen klientët dhe që asnjë filtër portash nuk është më i ngushtë se protokollet më sipër.

Faza e tretë: tuneli ekziston dhe PPP nuk niset kurrë

Kur IKE përfundon dhe kërkesa ende nuk shfaqet, shiko daemonin e tunelit dhe jo firewall-in. L2TP ka nevojë për diçka që dëgjon në UDP 1701 — xl2tpd ose kl2tpd në Linux, shërbimi i aksesit në distancë në Windows — dhe një shërbim i instaluar por i ndalur duket nga ana e klientit saktësisht si një paketë e hedhur. Kontrollo dëgjuesin përpara se të rihapësh rregulla që i ke verifikuar tashmë. Pastaj PPP duhet të negociojë, dhe shkëmbimi i parë LCP është vendi ku zakonisht ulet një dështim i heshtur.

Një kurth në këtë fazë nuk është aspak defekt rrjeti: Windows lejon vetëm një lidhje të një lloji të caktuar VPN në të njëjtën kohë, prandaj përpjekja e dytë kthen gabimin 937, «një lidhje tjetër e këtij lloji është në përdorim». Ky është një rregull lokal, dhe mënyra për ta anashkaluar është një pajisje tjetër, një lloj tjetër tuneli ose ndarja e lidhjes së vetme që ekziston tashmë.

Lexo regjistrin sipas rendit të fazave në vend që të hamendësosh

Ndal klientin, nise përsëri dhe lexo komponentët sipas rendit në të cilin shkruajnë regjistrin. Domethënë së pari daemoni IPsec — strongSwan ose Libreswan, dhe ipsec --version të thotë cili — pastaj daemoni L2TP, pastaj pppd. Cilido komponent që ka shkruar i fundit përpara dështimit shënon fazën për t'u hetuar, sepse gjithçka që vjen pas tij në sekuencë nuk ka punuar fare.

Verifiko me një lidhje të freskët dhe jo me një sesion të ruajtur, sepse një klient që rilidhet nga cache-i mund të kapërcejë pjesë të shkëmbimit dhe të riprodhojë një rezultat të vjetruar. Konfirmo arritshmërinë, shkëmbimin e çelësave, tunelin dhe PPP një nga një, në atë rend. Atëherë kërkesa që mungon pushon së qeni mister dhe bëhet rreshti i dytë i një liste me të cilën vërtet mund të punohet. Ajo listë është edhe ajo që i jep ekipit të rrjetit, të cilit përndryshe do t'i kërkohej të kontrollonte firewall-in për një defekt që jeton në një daemon të panisur.