L2TP/IPsec dështon: izolo IPsec, vërtetimin e tunelit ose hyrjen PPP

Tri gjëra vërtetohen brenda një lidhjeje të vetme L2TP/IPsec, dhe vetëm njëra prej tyre përfshin personin që telefonon. IPsec vërteton pikat fundore të tunelit, lidhja e kontrollit L2TP mund t'i vërtetojë përsëri partnerët me sekretin e vet, dhe më pas PPP vërteton llogarinë e përdoruesit brenda sesionit. Një dështim në çdo fazë duket si gabim i përgjithshëm hyrjeje në dritaren e klientit dhe duket krejt ndryshe në regjistrin e serverit. Kaloni nëpër fazat sipas radhës dhe ndaloni në të parën që dështon, sepse çdo fazë nën një fazë të paprovuar është gjithashtu e paprovuar.

Tri faza vërtetimi, tri identitete të ndryshme

IPsec vërteton kujt i përkasin pikat fundore, duke përdorur një çelës të paracaktuar ose një certifikatë. Ky identitet u përket makinave ose portave, kurrë personit në tastierë. Kur partnerët nuk arrijnë të bien dakord në këtë fazë, nuk shkëmbehet asnjë paketë L2TP.

Lidhja e kontrollit L2TP mund të shtojë një shkëmbim të dytë e të veçantë sfidë-përgjigje, të drejtuar nga një sekret i përbashkët që duhet ta kenë të dy skajet.

RFC 2661 e bën atë vërtetim të lidhjes së kontrollit opsional, gjë që shpjegon pse i njëjti gabim prodhon simptoma të ndryshme në dy serverë. Një vendosje që nuk e ka konfiguruar kurrë një sekret tuneli e kalon fazën plotësisht; ajo që e ka konfiguruar vetëm në njërën anë dështon përpara se PPP të ofrohet. Më pas PPP vërteton përdoruesin me PAP, CHAP ose MSCHAPv2 dhe ia dorëzon emrin një depoje llogarish që mund të jetë lokale, në chap-secrets ose në RADIUS. Një fjalëkalim i gabuar në atë moment ju lë gjithsesi me një tunel që punon dhe një sesion të dështuar.

Lexoni pikën e ndalimit përpara se të redaktoni një konfigurim

Filloni me ipsec --version që të dini nëse dalja e statusit i përket strongSwan apo Libreswan. Më pas lexoni regjistrin e serverit, jo dritaren e klientit, sepse serveri regjistron cila fazë refuzoi.

Një rresht zakonisht e zgjidh biletën: një ankesë për IKE ose propozimet është faza e parë, një mesazh për lidhjen e kontrollit është faza e dytë, dhe një refuzim i metodës PPP ose llogarisë është faza e tretë. Kopjoni atë rresht në biletë me vulën kohore. Hamendja nga ana e klientit humb provën e vetme që keni tashmë.

Mbajini materialin e çelësit dhe fjalëkalimet jashtë atij ngjitjeje; emri i fazës e drejton punën, dhe një çelës i paracaktuar i rrjedhur e rihap biletën me pasoja më të këqija.

Faza e parë: a ka IPsec një asociim?

Ekzekutoni ipsec statusall në strongSwan ose ipsec whack --status në Libreswan dhe kërkoni një asociim fëmijë të vendosur me numërues jo zero. ip xfrm state tregon pamjen e kernelit në të dyja. Një palë SA e instaluar me numërues që rriten do të thotë që faza e parë ka mbaruar dhe mund të vazhdoni.

Mungesa e plotë e asociimit tregon adresën e partnerit, grupin e propozimeve ose çelësin e paracaktuar, dhe ndonjëherë një pajisje që rishkruan UDP 500 ndërsa hedh UDP 4500. Një asociim që vendoset dhe më pas zhduket pas disa sekondash është zakonisht një mospërputhje e kohëzgjatjes mes dy skajeve dhe jo një problem kredencialesh. Kontrolloni nëse të dyja palët renditin të njëjtat propozime kriptimi dhe hash përpara se të shtypni ndonjë gjë nga e para. Nëse jo, asnjë çelës nuk do të punojë kurrë.

Ndaloni sa kohë asociimi mungon. Redaktimi i opsioneve PPP në atë moment nuk ndryshon asgjë dhe e fsheh defektin e vërtetë nga personi tjetër.

Faza e dytë: a u vërtetua lidhja e kontrollit L2TP?

Pasi IPsec është lart, vëzhgoni daemon-in L2TP për një lidhje kontrolli që arrin një gjendje të vendosur, pasi PPP nuk mund të fillojë përpara kësaj. Një refuzim në lidhjen e kontrollit do të thotë që sekreti i tunelit ndryshon mes skajeve, ose një skaj kërkon një sekret që tjetri nuk e dërgon kurrë. Klientët shpesh shfaqin një fushë të vetme me etiketën shared secret, dhe ajo zakonisht i përket IPsec dhe jo L2TP. Plotësimi i saj nuk e konfiguron sekretin e tunelit, dhe fshirja e saj nuk e çaktivizon.

Nëse asnjë palë nuk ka konfiguruar një sekret tuneli, kaloni këtë fazë dhe trajtojeni dështimin e lidhjes së kontrollit si problem arritshmërie. Konfirmoni që UDP 1701 arrin daemon-in dhe që të dy skajet bien dakord për të njëjtin inkapsulim. Një rregull firewall i shkruar për një nga këto dy kushte është një shkak i zakonshëm i një lidhjeje që hapet gjysmë.

Vetëm një sesion që fillon të negociojë PPP e ka kaluar vërtet fazën e tunelit.

Faza e tretë: a po e refuzon PPP llogarinë?

Një dështim PPP duket ndryshe nga jashtë: tuneli është vendosur, sesioni fillon, dhe daemon-i regjistron një dështim të metodës së vërtetimit ose një refuzim llogarie. Lexoni metodën e emërtuar në atë mesazh. PAP dhe CHAP dështojnë për arsye të ndryshme, dhe një server që refuzon njërën do të refuzojë një klient që ofron vetëm atë.

Në një server Linux, inspektoni skedarin e opsioneve që daemon-i i jep PPP, zakonisht /etc/ppp/options.xl2tpd, dhe konfirmoni cilat metoda pranohen dhe ku zgjidhen llogaritë. Një emër që ekziston në RADIUS por jo në skedarin lokal të sekreteve dështon pastër dhe duket si fjalëkalim i gabuar. Më pas kontrolloni që klienti ofron një metodë që serveri pranon, jo një më të fortë që serveri refuzon ta negociojë. Ndryshimi i çelësit të paracaktuar për të rregulluar këtë fazë humb një pasdite dhe nuk ndryshon asgjë.

Kur sesioni më në fund ngrihet, caktimi i adresave, DNS dhe rrugët nuk janë kontrolluar ende, dhe secili dështon në heshtje në mënyrën e vet. Mbajini tri shtresat të ndara në shënimet tuaja: një çelës i saktë me një llogari të gabuar gjithmonë dështon, dhe rregullimi i një shtrese nuk rregullon kurrë një tjetër.