Kurš VPN posms neizdevās: IPsec, L2TP vadība vai PPP autentifikācija
Atrodiet pēdējo veiksmīgo posmu un labojiet tikai to slāni: IPsec, L2TP vadības kanālu, PPP autentifikāciju vai adreses piešķiršanu.
Jūs nomainījāt paroli, un nekas nekustējās, jo kļūme nekad nebija PPP. L2TP/IPsec ziņo par vienu savienojuma kļūdu piecām ļoti atšķirīgām nodošanām, un katrai nodošanai ir savs labojums. Strādājiet pretējā virzienā: atrodiet pēdējo veiksmīgo posmu un mainiet tikai to, kas nāk pēc tā. Zemāk redzamā secība arī nosaka, kādus pierādījumus vāksit vispirms.
Atbildiet uz četriem jautājumiem pēc kārtas
Piespiediet jaunu mēģinājumu, jo daži klienti rāda iepriekšējo kļūdu, līdz profils tiek atvienots un atkal pievienots. Pēc tam atbildiet: vai bija IPsec drošības asociācija, vai parādījās L2TP vadības savienojums un zvans, vai PPP sasniedza autentifikācijas spriedumu un vai IPCP deva klientam adresi? Pirmais nē ir posms, kuru labojat. Viss pēc tā nav pārbaudīts, tāpēc noraidīts lietotājvārds neko nepierāda, ja asociācija nekad nav pastāvējusi.
Pirms salīdzināšanas sinhronizējiet pulksteņus abos galos. Mēģinājums, kas iztīrīja IPsec un neizdevās pie PPP, izskatās kā viena kļūme, kad klients rāda tikai pēdējo ziņojumu un servera žurnāls vēl glabā iepriekšējo mēģinājumu. Lasiet pēc laikatzīmes, nevis pēc skaļākās rindas.
Kad jums ir tikai lietotāja ekrānuzņēmums, paļaujieties uz lētāko sadalījumu: nepareiza iepriekš koplietota atslēga un xl2tpd, kas nekad neatbild, rada to pašu tekstu Windows dialoglodziņā, taču vienam vajadzīgs abos galos mainīts noslēpums, bet otram — serverī palaists dēmons vai ugunsmūra noteikums. Ierīce vidū nevar nomest iekšējo 1701 pēc tam, kad transporta režīma IPsec to ir ietinis, tāpēc nemeklējiet ceļa filtru, kura nav.
Ko katrs slānis patiešām pārvalda
IPsec aizsargā paketes starp diviem partneriem; L2TP pārvadā PPP sesiju šī aizsargātā ceļa iekšienē, tāpēc RFC 3193 nosaka transporta režīmu, nevis savu tuneli. Klienta etiķete saka L2TP, tāpēc tunelis un pieteikšanās šķiet viens mehānisms. Tie nav: L2TP vadības savienojums autentificē tuneļa galus tur, kur izvietojums to ieslēdz, un PPP atsevišķi autentificē lietotāju ar CHAP, PAP vai MS-CHAPv2 saskaņā ar servera politiku.
Šis sadalījums izskaidro divus noslēpumus, ko cilvēki nemitīgi jauc. Iepriekš koplietota atslēga autentificē IPsec partnerus. Lietotājvārds un parole identificē lietotāju PPP priekšā. Windows koplietotā noslēpuma atkārtota ievadīšana profilā, kas autentificējas ar sertifikātiem, neveiksmīgajā posmā neko nemaina, un PPP paroles labošana nevar nodrošināt trūkstošo aizsargāto kanālu. Tāda pati atturība attiecas uz identitātes pārbaudi: neizslēdziet partnera identitāti vai sertifikāta validāciju, lai iegūtu tuneli, jo tad savienojas ceļš, nevis partneris.
Autentifikācija arī nav PPP beigas. Pēc lietotāja pieņemšanas IPCP pārrunā klienta adresi un DNS un WINS opcijas, ko serveris ir gatavs dot. Klients var izturēt CHAP vai MS-CHAPv2 un tomēr palikt bez adreses, un tā ir kļūme PPP iekšienē, nevis maršrutēšanas problēma. Vienkāršs L2TP bez IPsec paliek derīgs un neaizsargāts, tāpēc veiksmīgs savienojums nekad nepierāda, ka trafiks ir aizsargāts; pārbaudiet, ko serveris pieprasa, nevis klienta etiķeti.
Izlemiet pēc pirmā trūkstošā posma
Lasiet tabulu pēc pirmā trūkstošā elementa, no kreisās uz labo. Labā kolonna ir vienīgais darbs, kas tajā brīdī ir tā vērts; viss pa kreisi no tās jau ir pierādīts, un atkārtota pārbaude izdedzina pārtraukuma logu, nepievienojot informāciju.
| 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 |
Trīs rindas ir pelnījušas brīdinājumu. 1701 rinda ir vieta, kur parasti nonāk Windows klienti aiz NAT: asociācija pabeidzas, tad nekas neienāk, un cēlonis ir iekapsulēšana, nevis slikta parole. IPCP rinda ir tā, ko kļūdaini nolasa kā maršruta problēmu, jo Windows trūkstošo adresi ietin kļūdā 720, un paplātes ikona tikai pasaka, ka savienojums neizdevās; šī kļūme atrodas pēc autentifikācijas un pirms maršrutēšanas. Pēdējā rinda nemaz nav IPsec kļūme, kaut arī ikona saka atvienots.
Komandas, kas atdala slāņus
Linux serverī ar strongSwan swanctl --list-sas uzskaita izveidotās asociācijas ar partnera identitāti, un ipsec statusall aptver vecākus strongSwan un libreswan resursdatorus. Zem tā ip xfrm state rāda faktiskās kodola asociācijas, bet ss -lunp | grep 1701 pierāda, kur xl2tpd ir piesaistīts. Palaidiet xl2tpd -D priekšplānā, lai redzētu vadības savienojumus un zvanus, un ieslēdziet pppd atkļūdošanu /etc/ppp/options.xl2tpd, lai redzētu piedāvāto metodi un atbildi.
Kad žurnāli rāda veiksmīgu autentifikāciju, nākamais jautājums ir, vai IPCP tika pabeigts. Pārbaudiet, vai ip range faila /etc/xl2tpd/xl2tpd.conf sadaļā [lns default] vēl ir brīvas adreses un vai /etc/ppp/options.xl2tpd patiešām satur ms-dns un ms-wins, ja klients tos gaida. Izsmelts pūls un trūkstoša DNS opcija izskatās atšķirīgi uz vada: pirmais atstāj klientu bez adreses un ar 720, otrais dod adresi, bet ne atrisinātāju, tāpēc vārdi neizdodas, kamēr ping uz neapstrādātām adresēm strādā. Ne vienu no tiem nelabo atkārtota paroles ievadīšana.
Klientā NetworkManager L2TP spraudnis ieraksta pppd sarunu žurnālā, tāpēc journalctl -u NetworkManager -b parasti atdala tunelis uzcelts, autentifikācija noraidīta no tuneļa vispār nav. Windows Get-VpnConnection ziņo profila faktiskos autentifikācijas iestatījumus, un RasClient notikumi sadaļā Application Event Viewer nosauc neveiksmīgo komponenti. Kad dialoglodziņš ir pārāk neskaidrs, ieslēdziet netsh ras set tracing * enable.
Ierakstiem vajadzīga viena piesardzība. Transporta režīma IPsec gadījumā iekšējais UDP 1701 ir šifrēts, tāpēc ieraksts ārējā saskarnē rāda ESP vai UDP 4500 zem NAT-T un vispār nekādu L2TP. 1701 neesamība ierakstā ir gaidāma un nav bloķēta porta pierādījums; vērojiet, vai kustas ESP vai 4500 skaitītāji.
NAT, MTU un maršruti: kur steks jūs maldina
NAT salauž pieņēmumus pirms kaut kas ir autentificēts. ESP ir savs IP protokols, tāpēc tulkojošā ierīce to izmet, ja vien partneri neiekapsulē; tieši to nodrošina UDP 4500. Windows serverī, kas pats atrodas aiz mājas maršrutētāja vai mākoņa NAT vārtejas, IPsec posms neizdodas ar kļūdu 789, līdz AssumeUDPEncapsulationContextOnSendRule tiek iestatīts uz 2 zem PolicyAgent atslēgas un mašīna tiek restartēta, un kļūme paliek neatšķirama no slēgta porta. Klienti aiz NAT ir vienkāršāki: ja serverim ir publiska adrese, NAT-T uz UDP 4500 tos pārvadā, un šī vērtība nav iesaistīta.
Kad PPP ir uzcelts, MTU ar melno caurumu imitē mirušu tuneli: mazi paketi iziet cauri, TLS rokasspiediens vai lapas ielāde iekaras, un klients var joprojām rādīt savienojumu. Pirms vainot serveri, samaziniet saskarnes MTU vai savelciet MSS vārtejā. Sadalītā tuneļa maršrutēšana ir otrs blēdis; apakštīkls, kas nosūtīts ar nepareizu masku, atstāj tuneli veselu un vienu lietotni nesasniedzamu. Privāts resursdatora nosaukums pievieno savu lēcienu: ja vaicājums iziet caur vietējo atrisinātāju, nosaukums netiek atrisināts pirms jebkura maršruta pārbaudes.
Kontrolsaraksts pirms pieskaraties akreditācijas datiem
Izejiet sarakstu pēc kārtas un apstājieties pie pirmā neveiksmīgā elementa. Katrs solis ir lēts, un katrs izslēdz veselu labojumu klasi.
- Apstipriniet, ka asociācija pastāv abos galos, saskaņota pēc partnera identitātes, nevis pēc savienots etiķetes.
- Apstipriniet, ka UDP 1701 sasniedz xl2tpd; asociācija bez zvana ir jūsu kļūme.
- Izlasiet PPP spriedumu un, ja autentificēts, IPCP rezultātu, pirms pieņemat, ka parole ir nepareiza.
- Tikai tagad ievadiet akreditācijas datus no jauna tādā formātā, kādu serveris gaida, jo domēna prefikss maina kontu.
- Ja joprojām neizdodas, ierakstiet abus galus ar saskaņotām laikatzīmēm un salīdziniet posmu pa posmam.
Apstāšanās pie otrā soļa nozīmē ceļa vai iekapsulēšanas problēmu, un nekāds paroles labojums to neizkustinās. Apstāšanās pie trešā soļa nozīmē, ka žurnāls jau nosauc labojamo metodi vai adrešu pūlu. Jebkurā gadījumā nākamā izmaiņa ir tāda, ko varat pamatot, un jūs pārtraucat griezties ap iestatījumiem, kas nekad nav bijuši iesaistīti.