Milline VPN-i etapp ebaõnnestus: IPsec, L2TP juhtimine või PPP autentimine
Leidke viimane õnnestunud etapp ja parandage ainult see kiht: IPsec, L2TP juhtkanal, PPP autentimine või aadressi määramine.
Muutsite parooli ja miski ei liikunud, sest viga ei olnud kunagi PPP-s. L2TP/IPsec teatab ühest ühendusveast viie täiesti erineva üleandmise kohta ja igal üleandmisel on oma parandus. Töötage tagurpidi: leidke viimane etapp, mis õnnestus, ja muutke ainult seda, mis tuleb pärast. Allolev järjekord otsustab ka, milliseid tõendeid kogute esimesena.
Vastake neljale küsimusele järjekorras
Sunnige värske katse, sest mõned kliendid näitavad eelmist viga seni, kuni profiil lahti ühendatakse ja uuesti ühendatakse. Seejärel vastake: kas IPsec-i turvaassotsiatsioon oli olemas, kas L2TP juhtühendus ja kõne ilmusid, kas PPP jõudis autentimisotsuseni ja kas IPCP andis kliendile aadressi? Esimene ei on etapp, mida parandate. Kõik pärast seda on testimata, seega tagasi lükatud kasutajanimi ei tõesta midagi, kui assotsiatsiooni kunagi polnud.
Sünkroonige kellad mõlemas otsas enne võrdlemist. Katse, mis puhastas IPsec-i ja ebaõnnestus PPP juures, näeb välja nagu üks rike, kui klient näitab ainult viimast sõnumit ja serverilogu hoiab veel varasemat katset. Lugege ajatempli järgi, mitte kõige valjema rea järgi.
Kui teil on ainult kasutaja ekraanipilt, toetuge kõige odavamale eraldusele: vale eeljagatud võti ja xl2tpd, mis ei vasta kunagi, tekitavad Windowsi dialoogis sama teksti, kuid üks vajab mõlemas otsas muudetud saladust ja teine serveris endas käivitatud deemonit või tulemüürireeglit. Vahendav seade ei saa sisemist 1701-t ära visata, kui IPsec transpordirežiimis on selle juba mähkinud, nii et ärge otsige teefiltrit, mida pole olemas.
Mida iga kiht tegelikult omab
IPsec kaitseb pakette kahe partneri vahel; L2TP kannab PPP sessiooni selle kaitstud tee sees, mistõttu RFC 3193 määrab omatunneli asemel transpordirežiimi. Kliendi silt ütleb L2TP, nii et tunnel ja sisselogimine tunduvad ühe mehhanismina. Need ei ole: L2TP juhtühendus autendib tunneli otspunkte seal, kus juurutus selle lubab, ja PPP autendib kasutajat eraldi CHAP-i, PAP-i või MS-CHAPv2-ga vastavalt serveri poliitikale.
See eraldus selgitab kahte saladust, mida inimesed pidevalt segamini ajavad. Eeljagatud võti autendib IPsec-i partnereid. Kasutajanimi ja parool identifitseerivad kasutajat PPP jaoks. Windowsi jagatud saladuse uuesti sisestamine profiilile, mis autendib sertidega, ei muuda ebaõnnestuvas etapis midagi, ja PPP parooli muutmine ei suuda pakkuda puuduvat kaitstud kanalit. Sama tagasihoidlikkus kehtib identiteedikontrolli kohta: ärge lülitage välja partneri identiteeti ega serdi valideerimist, et tunnelit saada, sest siis ühendub tee, mitte partner.
Ka autentimine ei ole PPP lõpp. Pärast kasutaja vastuvõtmist läbiräägib IPCP kliendi aadressi ning DNS- ja WINS-valikud, mida server on valmis andma. Klient võib läbida CHAP-i või MS-CHAPv2 ja jääda ikkagi aadressita, mis on rike PPP sees, mitte marsruutimise probleem. Lihtne L2TP ilma IPsec-ita jääb kehtivaks ja kaitsmata, seega õnnestunud ühendus ei tõesta kunagi, et liiklus on kaitstud; kontrollige, mida server nõuab, mitte kliendi silti.
Otsustage esimese puuduva etapi järgi
Lugege tabelit esimese puuduva üksuse järgi vasakult paremale. Parem veerg on ainus töö, mis sel hetkel väärt on; kõik sellest vasakul on juba tõestatud ja selle uuesti testimine põletab katkestusakna ilma teavet lisamata.
| 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 |
Kolm rida väärivad hoiatust. 1701 rida on koht, kuhu NAT-i taga olevad Windowsi kliendid tavaliselt maanduvad: assotsiatsioon lõpeb, siis ei saabu midagi ja põhjus on kapseldamine, mitte halb parool. IPCP rida on see, mida loetakse ekslikult marsruudiprobleemiks, sest Windows mähkib puuduva aadressi vea 720 sisse ja süsteemisalve ikoon ütleb ainult, et ühendus ebaõnnestus; see rike asub pärast autentimist ja enne marsruutimist. Viimane rida ei ole üldse IPsec-i rike, kuigi ikoon ütleb lahti ühendatud.
Käsud, mis kihid eraldavad
strongSwaniga Linuxi serveris loetleb swanctl --list-sas loodud assotsiatsioonid koos partneri identiteediga ja ipsec statusall katab vanemad strongSwan- ja libreswan-hostid. Selle all näitab ip xfrm state kerneli tegelikke assotsiatsioone, samas kui ss -lunp | grep 1701 tõestab, kuhu xl2tpd on seotud. Käivitage xl2tpd -D esiplaanil, et näha juhtühendusi ja kõnesid, ning lülitage sisse pppd silumine failis /etc/ppp/options.xl2tpd, et näha pakutavat meetodit ja vastust.
Kui logid näitavad õnnestunud autentimist, on järgmine küsimus, kas IPCP lõpetati. Kontrollige, kas ip range jaotises [lns default] failis /etc/xl2tpd/xl2tpd.conf on veel vabu aadresse ja kas /etc/ppp/options.xl2tpd sisaldab tõesti ms-dns ja ms-wins, kui klient neid ootab. Ammendunud bassein ja puuduv DNS-valik näevad juhtmel erinevad välja: esimene jätab kliendi aadressita ja 720-ga, teine annab aadressi, kuid mitte resolverit, nii et nimed ebaõnnestuvad, samal ajal kui ping tooradele aadressidele töötab. Kumbagi ei paranda parooli uuesti sisestamine.
Kliendis kirjutab NetworkManageri L2TP pistikprogramm pppd vestluse žurnaali, nii et journalctl -u NetworkManager -b eraldab tavaliselt tunnel üleval, autentimine tagasi lükatud olekust tunnelit üldse pole. Windowsis teatab Get-VpnConnection profiili tegelikud autentimisseaded ja Event Vieweris jaotise Application all olevad RasClient sündmused nimetavad ebaõnnestuva komponendi. Kui dialoog on liiga ebamäärane, lubage netsh ras set tracing * enable.
Salvestised nõuavad üht ettevaatust. IPsec transpordirežiimis on sisemine UDP 1701 krüpteeritud, nii et välisliidesel tehtud salvestis näitab ESP-d või NAT-T korral UDP 4500 ja üldse mitte L2TP-d. Puuduv 1701 salvestises on ootuspärane ja ei tõesta blokeeritud porti; jälgige, kas ESP või 4500 loendurid liiguvad.
NAT, MTU ja marsruudid: kus pinu teid eksitab
NAT murrab eeldused enne, kui miski on autenditud. ESP on omaette IP-protokoll, seega tõlkiv seade viskab selle ära, kui partnerid ei kapselda; just seda pakub UDP 4500. Windowsi serveris, mis ise seisab koduruuteri või pilve NAT-lüüsi taga, ebaõnnestub IPsec-i etapp veaga 789, kuni AssumeUDPEncapsulationContextOnSendRule seatakse PolicyAgent võtme all väärtusele 2 ja masin taaskäivitatakse, ning rike jääb suletud pordist eristamatuks. NAT-i taga olevad kliendid on lihtsamad: kui serveril on avalik aadress, kannab neid NAT-T UDP 4500 peal ja see väärtus ei ole mängus.
Kui PPP on üleval, jäljendab musta auguga MTU surnud tunnelit: väikesed paketid läbivad, TLS-i käepigistus või lehe laadimine jääb ripakile ja klient võib endiselt näidata ühendatud. Langetage liidese MTU-d või klammerdage MSS lüüsis enne, kui serverit süüdistate. Split-tunneli marsruutimine on teine petis; vale maskiga saadetud alamvõrk jätab tunneli terveks ja ühe rakenduse kättesaamatuks. Privaatne hostinimi lisab oma sammu: kui päring väljub kohaliku resolveri kaudu, ebaõnnestub nimi enne, kui ükski marsruut testitakse.
Kontrollnimekiri enne, kui puudutate mandaate
Töötage nimekiri järjekorras läbi ja peatuge esimese ebaõnnestuva üksuse juures. Iga samm on odav ja igaüks välistab terve muudatuste klassi.
- Kinnitage, et assotsiatsioon on olemas mõlemas otsas, sobitatud partneri identiteedi, mitte ühendatud-sildi järgi.
- Kinnitage, et UDP 1701 jõuab xl2tpd-ni; assotsiatsioon ilma kõneta on teie rike.
- Lugege PPP otsust ja kui see autentis, siis IPCP tulemust, enne kui eeldate, et parool on vale.
- Alles nüüd sisestage mandaadid uuesti vormingus, mida server ootab, sest domeeni prefiks muudab kontot.
- Kui see ikka ebaõnnestub, salvestage mõlemad otsad joondatud ajatemplitega ja võrrelge etapp etapi haaval.
Teise sammu juures peatuma jäämine tähendab tee- või kapseldusprobleemi ja ükski parooli muudatus ei liiguta seda. Kolmanda sammu juures peatuma jäämine tähendab, et logi juba nimetab meetodi või aadressibasseini, mida parandada. Mõlemal juhul on järgmine muudatus selline, mida saate põhjendada, ja te lõpetate seadete ringi käimise, mis kunagi mängus ei olnud.