Zakaj se PPTP in L2TP/IPsec ustavita pred pozivom za uporabniško ime?
Če ni poziva za uporabniško ime, se PPP ni nikoli začel, zato je napaka v prenosu, izmenjavi ključev ali postavitvi tunela. Pred ponovno namestitvijo preverite vrstni red stopenj.
Manjkajoč poziv za uporabniško ime je diagnostično darilo: PPP se še ni začel, zato račun, geslo in domenska politika še niso bili vprašani. Pri povezavi PPTP ali L2TP/IPsec odjemalec zahteva poverilnice šele, ko tunel obstaja in je strežnik začel sejo PPP. Vse, kar lahko spodleti pred tem trenutkom, je prenos, izmenjava ključev ali postavitev tunela, kar je veliko manjša površina kot «VPN je pokvarjen».
Manjkajoč poziv zoži napako na tri stopnje
Zapišite zadnjo stopnjo, ki je vidno uspela, ker ima vsaka drugega lastnika in drugo rešitev. Ugibanje nastavitev računa, medtem ko ste obtičali dve stopnji prej, je način, kako izgine popoldne.
| 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 |
Odjemalec, ki poteče brez poziva, ni nikoli dobil asociacije IPsec, zato je napaka v IKE ali v tem, ali vaši paketi sploh dosežejo prehod. Tisti, ki sporoča, da preverja poverilnice, in nato pade, je prišel dlje, kot nakazuje sporočilo. Poziv, ki mu sledi zavrnitev, je avtentikacija PPP, in to spada v članek o računu, ne v tega.
Prva stopnja: protokol, ki ga požarni zid tiho zavrže
PPTP potrebuje TCP 1723 za krmilni kanal in protokol IP 47 za podatkovno pot, oba pa potujeta ločeno. Veliko omrežij posreduje 1723 in zavrže protokol 47, kar ustvari tunel, ki se pogaja in nato ne prenese prav ničesar. Usmerjevalnik, ki izvaja NAT, potrebuje tudi prehod s podporo GRE, dostopna pot samo prek IPv6 pa ne more prenašati PPTP v nobeni konfiguraciji.
L2TP prek IPsec porabi vrata 500 za IKE in vrata 4500 za prehod NAT, nato ovije sam promet L2TP v 1701, medtem ko ESP prenaša zaščiteno breme, ko asociacija obstaja. Dovolite dve krmilni vrati, ne pa ESP, in dobite natanko simptom iz naslova: viden napredek, nato mrtev odjemalec pred vsakim pogovorom o poverilnicah. Preizkušanje s hotspotom telefona je poceni način, kako ločiti težavo odjemalca od težave poti.
Druga stopnja: ključ, ki ni ključ, predlog, ki ni ponujen
Neskladni vnaprej dogovorjeni ključ spodleti hitro in tiho, običajna različica pa je ključ, ki je na zaslonu videti pravilen, a nosi prilepljen prelom vrstice ali presledek na koncu. Na odjemalcu Linux pogovorno okno ni nujno vir resnice: vtičnik L2TP v NetworkManagerju hrani skrivnosti v datotekah pod /etc/ipsec.d/, starejša datoteka za posamezno povezavo, ki jo /etc/ipsec.secrets še vključuje, pa bo uporabljena namesto pravkar vnesene. Kopirajte to datoteko na varno mesto, odstranite jo iz poti vključevanja in nato ključ znova vnesite ročno.
Druga polovica te stopnje je predlog. Oba konca se morata dogovoriti o istem naboru algoritmov faze 1 — šifriranje, celovitost in skupina Diffie-Hellman — ter o ustreznih transformacijah ESP za fazo 2, sicer asociacija sploh ne nastane. Prehod, ki ponuja samo 3DES, SHA1 in MODP1024, bo zavrnil odjemalca, nastavljenega za močnejše algoritme, in njegov dnevnik poimenuje zavrnjeno transformacijo. Dnevnik poimenuje neskladje, če ga berete, namesto da storitev znova zaženete. Namesto kopiranja niza algoritmov iz niti foruma vprašajte prehod, o katerih transformacijah se bo res pogajal: ike-scan usmerjen na njegov naslov vrne transformacije, o katerih se bo pogajal. Če je edina ponudba kriptografija, ki je vaša politika ne dovoljuje več, popravek spada na prehod, ne v znižanje odjemalca.
V sistemu Windows ključ in metoda preverjanja živita v profilu VPN, neskladje pa se pokaže pred pozivom za poverilnice in ne po njem. Kjer je prejemnik Windows Server, potrdite, da je vloga za oddaljeni dostop nameščena, da potrdilo ustreza imenu, s katerim se povezujejo odjemalci, in da noben filter vrat ni ožji od zgornjih protokolov.
Tretja stopnja: tunel obstaja in PPP se ne začne
Ko je IKE končan in se poziv še vedno ne pojavi, poglejte demona tunela, ne požarnega zidu. L2TP potrebuje nekaj, kar posluša na UDP 1701 — xl2tpd ali kl2tpd v Linuxu, storitev oddaljenega dostopa v Windows — nameščena, a ustavljena storitev pa je z vidika odjemalca videti enako kot zavržen paket. Preverite poslušalca, preden znova odprete pravila, ki ste jih že preverili. Nato se mora PPP pogajati, prva izmenjava LCP pa je mesto, kjer običajno pristane tiha napaka.
Ena past na tej stopnji sploh ni omrežna napaka: Windows dovoli le eno povezavo določene vrste VPN hkrati, zato drugi poskus vrne napako 937, «druga povezava te vrste je v uporabi». To je lokalno pravilo, obiti pa se da z drugo napravo, drugo vrsto tunela ali skupno rabo edine obstoječe povezave.
Berite dnevnik v vrstnem redu stopenj, namesto da ugibate
Ustavite odjemalca, zaženite ga znova in berite komponente v vrstnem redu, v katerem pišejo dnevnik. To pomeni najprej demon IPsec — strongSwan ali Libreswan, in ipsec --version vam pove katerega — nato demon L2TP, nato pppd. Katera koli komponenta je pred napako pisala zadnja, označuje stopnjo za preiskavo, ker vse, kar v zaporedju pride za njo, ni delovalo sploh.
Preverite s svežo povezavo in ne s shranjeno sejo, ker lahko odjemalec, ki se znova poveže iz predpomnilnika, preskoči dele izmenjave in ponovi zastarel rezultat. Potrdite dosegljivost, izmenjavo ključev, tunel in PPP enega za drugim, v tem vrstnem redu. Takrat manjkajoč poziv preneha biti uganka in postane druga vrstica seznama, po katerem je mogoče res delati. Ta seznam je tudi tisto, kar predate omrežni ekipi, ki bi sicer morala preveriti požarni zid zaradi napake, ki živi v nezagnanem demonu.