Zašto se PPTP i L2TP/IPsec zaustavljaju pre upita za korisničko ime?
Nema upita za korisničko ime znači da PPP nikad nije počeo, pa je kvar u prenosu, razmeni ključeva ili postavljanju tunela. Proverite redosled faza pre ponovne instalacije.
Nema upita za korisničko ime je dijagnostički poklon: PPP još nije počeo, pa se račun, lozinka i domenska politika još nisu konsultovali. U PPTP ili L2TP/IPsec vezi klijent traži akreditive tek nakon što tunel postoji i server je započeo PPP sesiju. Sve što može pasti prije tog trenutka jest prijenos, razmjena ključeva ili postavljanje tunela, što je mnogo manja površina od „VPN je pokvaren”.
Upit koji nedostaje sužava kvar na tri faze
Zapišite posljednju fazu koja je vidljivo uspjela, jer svaka ima drugog vlasnika i drugo rješenje. Nagađanje o postavkama računa dok ste zaglavili dvije faze ranije jest kako jedno poslijepodne nestane.
| 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 |
Klijent koji istekne bez upita nikada nije dobio IPsec asocijaciju, pa je kvar u IKE-u ili u tome stižu li vaši paketi do pristupnika uopće. Onaj koji javi da provjerava akreditive i zatim padne stigao je dalje nego što poruka sugeriše. Upit nakon kojeg slijedi odbijanje jest PPP autentifikacija i pripada članku o računu, ne ovome.
Prva faza: protokol koji vatrozid tiho odbacuje
PPTP treba TCP 1723 za kontrolni kanal i IP protokol 47 za put podataka, a to dvoje putuje odvojeno. Mnoge mreže propuštaju 1723 i odbacuju protokol 47, što daje tunel koji se dogovori i zatim ne prenosi baš ništa. Usmjerivač koji radi NAT treba i propusnicu s podrškom za GRE, a pristupni put samo preko IPv6 ne može nositi PPTP ni pod kakvom konfiguracijom.
L2TP preko IPsec-a troši port 500 na IKE i port 4500 na NAT prolaz, zatim umotava sam L2TP promet u 1701, a ESP nosi zaštićeni teret kad asocijacija postoji. Dozvolite dva kontrolna porta ali ne ESP i dobijate tačno simptom iz naslova: vidljiv napredak, pa mrtav klijent prije bilo kakvog dijaloga za akreditive. Testiranje s mobilnog hotspota jeftin je način da odvojite problem klijenta od problema puta.
Druga faza: ključ koji nije ključ, prijedlog koji se ne nudi
Neusklađeni unaprijed dijeljeni ključ pada brzo i tiho, a uobičajena verzija je ključ koji na ekranu izgleda ispravno dok nosi zalijepljen prijelom reda ili razmak na kraju. Na Linux klijentu dijalog nije nužno izvor istine: NetworkManagerov L2TP dodatak drži tajne u datotekama pod /etc/ipsec.d/, a starija datoteka pojedinačne veze koju /etc/ipsec.secrets još uvijek uključuje bit će upotrijebljena umjesto one koju ste upravo otipkali. Kopirajte tu datoteku na sigurno mjesto, izbacite je iz putanje uključivanja, pa otipkajte ključ ručno.
Druga polovina ove faze je prijedlog. Obje strane moraju se složiti oko istog skupa algoritama faze 1 — šifriranje, integritet i Diffie-Hellman grupa — i oko odgovarajućih ESP transformacija za fazu 2, inače se asocijacija uopće ne formira. Pristupnik koji nudi samo 3DES, SHA1 i MODP1024 odbit će klijenta podešenog na jače algoritme, a njegov dnevnik imenuje odbijenu transformaciju. Dnevnik imenuje nesklad ako ga čitate umjesto da ponovo pokrenete servis. Umjesto kopiranja niza algoritama s foruma, pitajte pristupnik koje će transformacije zaista dogovoriti: ike-scan uperen na njegovu adresu vraća transformacije koje će dogovoriti. Ako je jedina ponuda kriptografija koju vaša politika više ne dopušta, popravka pripada pristupniku, ne degradaciji klijenta.
Na Windowsu ključ i metoda autentifikacije žive u VPN profilu, a nesklad ispliva prije upita za akreditive, ne poslije njega. Gdje je prijemnik Windows Server, potvrdite da je uloga daljinskog pristupa instalirana, da se certifikat poklapa s imenom na koje se klijenti spajaju i da nijedan filter portova nije uži od gore navedenih protokola.
Treća faza: tunel postoji a PPP ne počinje
Kad IKE završi a upit se ipak ne pojavi, gledajte u tunelski demon, ne u vatrozid. L2TP treba nešto što sluša na UDP 1701 — xl2tpd ili kl2tpd na Linuxu, servis daljinskog pristupa na Windowsu — a instaliran ali zaustavljen servis s klijentske strane izgleda isto kao odbačen paket. Provjerite slušača prije nego ponovo otvorite pravila koja ste već provjerili. Zatim se PPP mora dogovoriti, a prva LCP razmjena je mjesto gdje tihi neuspjeh obično sleti.
Jedna zamka u ovoj fazi nije mrežni kvar nimalo: Windows dopušta samo jednu vezu date vrste VPN-a odjednom, pa drugi pokušaj vraća grešku 937, „druga veza ove vrste je u upotrebi”. To je lokalno pravilo, a zaobilazi se drugim uređajem, drugom vrstom tunela ili dijeljenjem jedine veze koja već postoji.
Čitajte dnevnik po redoslijedu faza umjesto da nagađate
Zaustavite klijent, pokrenite ga ponovo i čitajte komponente redom kojim pišu dnevnik. To znači prvo IPsec demon — strongSwan ili Libreswan, a ipsec --version vam kaže koji — zatim L2TP demon, pa pppd. Koja god komponenta posljednja piše prije kvara, ona označava fazu za istragu, jer sve što u nizu dolazi poslije nje nije uopće radilo.
Provjerite svježom vezom, ne sačuvanom sesijom, jer klijent koji se ponovo spaja iz keša može preskočiti dijelove razmjene i reproducirati zastario rezultat. Potvrdite dostupnost, razmjenu ključeva, tunel i PPP jednu po jednu, tim redom. Tada upit koji nedostaje prestaje biti misterija i postaje drugi red spiska po kojem se zaista može raditi. Taj spisak je i ono što predajete mrežnom timu, od kojeg bi inače tražili da provjeri vatrozid zbog kvara koji živi u nepokrenutom demonu.