Kasutajanime küsimuse puudumine on diagnostiline kingitus: PPP ei ole veel alustanud, seega ei ole kontot, parooli ega domeenipoliitikat veel küsitud. PPTP- või L2TP/IPsec-ühenduses küsib klient volitusi alles siis, kui tunnel on olemas ja server on alustanud PPP-sessiooni. Kõik, mis võib enne seda hetke nurjuda, on transport, võtmevahetus või tunneliloom, mis on palju väiksem pind kui „VPN on katki”.

Puuduv küsimus kitsendab vea kolmele etapile

Kirjutage üles viimane etapp, mis nähtavalt õnnestus, sest igal on erinev omanik ja erinev parandus. Konto seadete oletamine, kui olete kinni jäänud kaks etappi varem, on viis, kuidas üks pärastlõuna kaob.

StageWhat has to workHow a failure looks
ReachUDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT deviceClient hangs, then reports no response
Key exchangePreshared key or certificate, phase 1 and phase 2 proposalsFast error, or a stall after the client says it is verifying
TunnelL2TP or PPTP control channel, then PPP startsConnects, then closes with no prompt
User authPPP credentials and an address pool with roomPrompt appears, then a rejection

Klient, mis aegub ilma küsimuseta, ei saanud kunagi IPsec-assotsiatsiooni, seega on viga IKE-s või selles, kas teie paketid üldse lüüsini jõuavad. Klient, mis teatab volituste kontrollimisest ja seejärel katkeb, jõudis kaugemale, kui teade vihjab. Küsimus, millele järgneb tagasilükkamine, on PPP-autentimine ja see kuulub kontoartiklisse, mitte siia.

Esimene etapp: protokoll, mille tulemüür vaikselt maha viskab

PPTP vajab juhtkanali jaoks TCP 1723 ja andmeteekonna jaoks IP-protokolli 47 ning need kaks reisivad eraldi. Paljud võrgud edastavad 1723 ja viskavad protokolli 47 maha, mille tulemuseks on tunnel, mis peab läbirääkimisi ja ei kanna seejärel üldse midagi. NAT-i tegev ruuter vajab ka GRE-toega läbipääsu ning ainult IPv6-põhine juurdepääsutee ei suuda PPTP-d üheski konfiguratsioonis kanda.

L2TP üle IPsec-i kulutab IKE jaoks pordi 500 ja NAT-i läbimiseks pordi 4500, seejärel mässib L2TP-liikluse enda 1701 sisse, samal ajal kui ESP kannab kaitstud sisu, kui assotsiatsioon on olemas. Lubage kaks juhtporti, kuid mitte ESP-d, ja saate täpselt pealkirjas kirjeldatud sümptomi: nähtav edenemine ja seejärel surnud klient enne igasugust volituste dialoogi. Telefoni hotspotist testimine on odav viis eraldada kliendi probleem tee probleemist.

Teine etapp: võti, mis ei ole võti, pakkumine, mida ei pakuta

Sobimatu eeljagatud võti nurjub kiiresti ja vaikselt ning tavaline versioon on võti, mis näeb ekraanil õige välja, kuid kannab kleepimisel tekkinud reavahetust või lõpus olevat tühikut. Linuxi kliendis ei ole dialoog tingimata tõe allikas: NetworkManageri L2TP-plugin hoiab saladusi failides /etc/ipsec.d/ all, ja vanem ühendusepõhine fail, mille /etc/ipsec.secrets endiselt kaasab, võetakse kasutusele selle asemel, mille te just tipistasite. Kopeerige see fail turvalisse kohta, eemaldage see kaasamise teelt ja seejärel tipitage võti käsitsi uuesti.

Selle etapi teine pool on pakkumine. Mõlemad otsad peavad kokku leppima samas faasi 1 algoritmide komplektis — krüpteerimine, terviklikkus ja Diffie-Hellmani grupp — ning faasi 2 jaoks sobivates ESP-teisendustes, muidu ei teki assotsiatsiooni üldse. Lüüs, mis pakub ainult 3DES-i, SHA1-t ja MODP1024-t, keeldub tugevamatele algoritmidele seatud kliendist ning selle logi nimetab keeldutud teisenduse. Logi nimetab lahknevuse, kui te seda loete, selle asemel et teenust jälle taaskäivitada. Selle asemel et kopeerida algoritmide stringi foorumiteemast, küsige lüüsilt, milliseid teisendusi see tegelikult läbi räägib: selle aadressile suunatud ike-scan tagastab teisendused, mille üle see läbi räägib. Kui ainus pakkumine on krüptograafia, mida teie poliitika enam ei luba, kuulub parandus lüüsile, mitte kliendi allaviimisele.

Windowsis elavad võti ja autentimismeetod VPN-profiilis ning lahknevus ilmneb enne volituste küsimust, mitte pärast seda. Kui vastuvõtja on Windows Server, veenduge, et kaugjuurdepääsu roll on paigaldatud, et sert vastab nimele, millega kliendid ühenduvad, ja et ükski pordifilter ei ole ülaltoodud protokollidest kitsam.

Kolmas etapp: tunnel on olemas ja PPP ei alusta

Kui IKE on lõppenud ja küsimus siiski kunagi ei ilmu, vaadake tunnelideemonit, mitte tulemüüri. L2TP vajab midagi, mis kuulab UDP 1701 peal — Linuxis xl2tpd või kl2tpd, Windowsis kaugjuurdepääsuteenus — ning paigaldatud, kuid peatatud teenus näeb kliendi poolelt välja täpselt nagu mahavisatud pakett. Kontrollige kuulajat enne, kui avate uuesti reeglid, mida olete juba kontrollinud. Seejärel peab PPP läbi rääkima ja esimene LCP-vahetus on koht, kuhu vaikne nurjumine tavaliselt maandub.

Üks lõks selles etapis ei ole üldse võrguviga: Windows lubab korraga ainult ühte antud VPN-tüübi ühendust, seega teine katse tagastab vea 937, „teine seda tüüpi ühendus on kasutusel”. See on kohalik reegel ja sellest möödapääsemiseks on teine seade, teine tunnelitüüp või juba olemasoleva ainsa ühenduse jagamine.

Lugege logi etappide järjekorras, selle asemel et oletada

Peatage klient, käivitage see uuesti ja lugege komponente selles järjekorras, milles need logivad. See tähendab kõigepealt IPsec-deemon — strongSwan või Libreswan, ja ipsec --version ütleb teile, milline — seejärel L2TP-deemon, siis pppd. Milline komponent kirjutas enne nurjumist viimasena, märgib uurimist vajava etapi, sest kõik, mis järjestuses pärast seda tuleb, ei jooksnud üldse.

Kontrollige värske ühendusega, mitte salvestatud sessiooniga, sest vahemälust uuesti ühenduv klient võib vahetuse osad vahele jätta ja taasesitada vananenud tulemuse. Kinnitage kättesaadavus, võtmevahetus, tunnel ja PPP ükshaaval, selles järjekorras. Siis lakkab puuduv küsimus olemast mõistatus ja muutub nimekirja teiseks reaks, mida saab tõesti läbi töötada. See nimekiri on ka see, mille annate võrgumeeskonnale, kellelt muidu küsitaks tulemüüri kontrollimist vea pärast, mis elab käivitamata deemonis.

Seotud artiklid