Kodėl PPTP ir L2TP/IPsec sustoja prieš vartotojo vardo užklausą?
Nėra vartotojo vardo užklausos, vadinasi, PPP niekada neprasidėjo, todėl gedimas yra transporte, raktų mainuose arba tunelio nustatyme. Prieš perinstaliuodami patikrinkite etapų tvarką.
Vartotojo vardo užklausos nebuvimas yra diagnostinė dovana: PPP dar neprasidėjo, todėl paskyra, slaptažodis ir domeno politika dar nebuvo klausti. PPTP arba L2TP/IPsec ryšyje klientas prisijungimo duomenų prašo tik tada, kai tunelis jau yra ir serveris pradėjo PPP sesiją. Viskas, kas gali nepavykti iki tos akimirkos, yra transportas, raktų mainai arba tunelio nustatymas, o tai daug mažesnė sritis nei „VPN sugedusi“.
Trūkstama užklausa susiaurina gedimą iki trijų etapų
Užsirašykite paskutinį etapą, kuris matomai pavyko, nes kiekvienas jų turi kitą savininką ir kitą sprendimą. Spėlioti paskyros nustatymus, kai įstrigote dviem etapais anksčiau, yra būdas, kuriuo dingsta popietė.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Klientas, kuris baigiasi be užklausos, niekada negavo IPsec asociacijos, todėl gedimas yra IKE arba tame, ar jūsų paketai apskritai pasiekia šliuzą. Tas, kuris praneša tikrinantis prisijungimo duomenis, o paskui nukrenta, nuėjo toliau, nei leidžia manyti pranešimas. Užklausa, po kurios ateina atmetimas, yra PPP autentifikacija, ir tai priklauso straipsniui apie paskyrą, ne šiam.
Pirmas etapas: protokolas, kurį užkarda tyliai numeta
PPTP reikia TCP 1723 valdymo kanalui ir IP protokolo 47 duomenų keliui, ir abu keliauja atskirai. Daugelis tinklų praleidžia 1723 ir numeta protokolą 47, todėl susidaro tunelis, kuris derasi ir paskui nieko neneša. Maršrutizatoriui su NAT taip pat reikia GRE palaikančio praleidimo, o prieigos kelias tik per IPv6 jokioje konfigūracijoje negali pernešti PPTP.
L2TP per IPsec sunaudoja 500 prievadą IKE ir 4500 prievadą NAT perėjimui, paskui įvynioja patį L2TP srautą į 1701, o ESP neša apsaugotą turinį, kai asociacija jau yra. Leiskite du valdymo prievadus, bet ne ESP, ir gausite būtent antraštės simptomą: matoma pažanga, o paskui negyvas klientas prieš bet kokį prisijungimo duomenų dialogą. Bandymas iš telefono hotspot yra pigus būdas atskirti kliento problemą nuo kelio problemos.
Antras etapas: raktas, kuris nėra raktas, pasiūlymas, kuris nesiūlomas
Nesutampantis iš anksto bendrinamas raktas nepavyksta greitai ir tyliai, o įprasta versija yra raktas, kuris ekrane atrodo teisingai, bet turi įklijuotą eilutės lūžį arba tarpą pabaigoje. Linux kliente dialogas nebūtinai yra tiesos šaltinis: NetworkManager L2TP papildinys laiko paslaptis failuose po /etc/ipsec.d/, ir senesnis vienos jungties failas, kurį /etc/ipsec.secrets vis dar įtraukia, bus naudojamas vietoj ką tik įvesto. Nukopijuokite tą failą į saugią vietą, išimkite jį iš įtraukimo kelio ir tada įveskite raktą ranka iš naujo.
Kita šio etapo pusė yra pasiūlymas. Abi pusės turi sutarti dėl to paties 1 fazės algoritmų rinkinio — šifravimo, vientisumo ir Diffie-Hellman grupės — ir dėl atitinkamų ESP transformacijų 2 fazei, kitaip asociacija visai nesusidaro. Šliuzas, siūlantis tik 3DES, SHA1 ir MODP1024, atmes klientą, sukonfigūruotą stipresniems algoritmams, ir jo žurnalas įvardija atmestą transformaciją. Žurnalas įvardija neatitikimą, jei jį skaitote, o ne dar kartą paleidžiate paslaugą iš naujo. Užuot kopijavę algoritmų eilutę iš forumo temos, paklauskite šliuzo, dėl kokių transformacijų jis tikrai derėsis: į jo adresą nukreiptas ike-scan grąžina transformacijas, dėl kurių jis derėsis. Jei vienintelis pasiūlymas yra kriptografija, kurios jūsų politika nebeleidžia, pataisa priklauso šliuzui, o ne kliento nusileidimui.
Windows raktas ir autentifikavimo metodas gyvena VPN profilyje, o neatitikimas pasirodo prieš prisijungimo duomenų užklausą, o ne po jos. Kur priėmėjas yra Windows Server, patikrinkite, ar nuotolinės prieigos vaidmuo įdiegtas, ar sertifikatas atitinka vardą, prie kurio jungiasi klientai, ir ar joks prievadų filtras nėra siauresnis už aukščiau nurodytus protokolus.
Trečias etapas: tunelis yra, o PPP neprasideda
Kai IKE baigiasi, o užklausa vis tiek nepasirodo, žiūrėkite į tunelio demoną, o ne į užkardą. L2TP reikia kažko, kas klausosi UDP 1701 — xl2tpd arba kl2tpd Linux, nuotolinės prieigos paslauga Windows — o įdiegta, bet sustabdyta paslauga iš kliento pusės atrodo lygiai taip pat kaip numestas paketas. Patikrinkite klausytoją prieš vėl atidarydami jau patikrintas taisykles. Tada PPP turi derėtis, o pirmasis LCP apsikeitimas yra vieta, kur paprastai nusileidžia tylus nepavykimas.
Vienas spąstas šiame etape visai ne tinklo gedimas: Windows leidžia tik vieną tam tikro tipo VPN jungtį vienu metu, todėl antras bandymas grąžina klaidą 937, „kita šio tipo jungtis yra naudojama“. Tai vietinė taisyklė, o apėjimo būdas yra kitas įrenginys, kitas tunelio tipas arba bendrinimas vienintelės jau esančios jungties.
Skaitykite žurnalą etapų tvarka, o ne spėliokite
Sustabdykite klientą, paleiskite jį iš naujo ir skaitykite komponentus ta tvarka, kuria jie rašo žurnalą. Tai reiškia pirmiausia IPsec demonas — strongSwan arba Libreswan, o ipsec --version pasako, kuris — tada L2TP demonas, tada pppd. Kuris komponentas paskutinis rašė prieš gedimą, tas žymi etapą, kurį reikia tirti, nes viskas, kas sekoje eina po jo, visai neveikė.
Tikrinkite nauja jungtimi, o ne išsaugota sesija, nes klientas, jungdamasis iš podėlio, gali praleisti dalį apsikeitimo ir atkurti pasenusį rezultatą. Patvirtinkite pasiekiamumą, raktų mainus, tunelį ir PPP po vieną, ta tvarka. Tada trūkstama užklausa nustoja būti mįsle ir tampa antra eilute sąrašo, su kuriuo tikrai galima dirbti. Tas sąrašas yra ir tai, ką perduodate tinklo komandai, kurios kitu atveju būtų prašoma patikrinti užkardą dėl gedimo, gyvenančio nepaleistame demone.