Chyba PPTP 800 verzus 812 a výpadky po minúte
Chyba 800, chyba 812 a tunel PPTP, ktorý po minúte umrie, sú tri rôzne poruchy. Priraďte každý príznak vrstve, ktorá skutočne zlyhala.
Tri chybové správy od jedného klienta PPTP zvyčajne opisujú tri rôzne poruchy. Chyba 800 znamená, že tunel vôbec nevznikol, chyba 812 znamená, že server odmietol metódu overovania, a výpadok po minúte je keepalive časovač, ktorý usúdi, že zdravý partner zmizol. Každá fáza zlyháva zo svojho dôvodu, takže každá potrebuje vlastnú kontrolu.
Chyba 800 znamená, že tunel vôbec nevznikol
Windows vyvolá chybu 800, keď tunel vôbec nedokáže zostaviť, a text o nedostupnom serveri alebo nevhodných bezpečnostných parametroch je zhrnutie, nie diagnóza. PPTP potrebuje od siete dve samostatné veci, kým sa overia akékoľvek prihlasovacie údaje. TCP 1723 nesie riadiaci kanál a IP protokol 47, GRE, nesie zapuzdrenú záťaž.
Otestujte tú vonkajšiu cestu zvonku svojej LAN, pretože spojenie, ktoré funguje v kancelárii, o okraji nič nedokazuje:
$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB
Ak 1723 odpovedá a zachytávanie zostane prázdne, kým sa klient pokúša pripojiť, cesta zahadzuje protokol 47. Router s presmerovaným 1723, ale vypnutým priechodom PPTP dáva presne taký obraz: TCP handshake sa dokončí, potom pakety GRE zmiznú, takže porucha vyzerá ako problém s prihlasovacími údajmi, hoci sa neuskutočnil žiadny pokus o prihlásenie.
Nasmerujte presmerovanie na aktuálnu adresu servera v LAN, zapnite priechod PPTP tam, kde ho router ponúka, a skúste to znova z toho istého vonkajšieho bodu. Keď je GRE filtrovaný vyššie a nemôžete to zmeniť, SSTP cez TCP 443 alebo L2TP/IPsec cez UDP 500 a 4500 má lepšiu šancu než akákoľvek zmena na strane Windows.
Chyba 812 je odmietnutie vašej metódy overovania serverom
Chyba 812 sa vracia po tom, čo je tunel hore, preto to vyzerá ako problém s heslom. Server odmieta metódu overovania dohodnutú pre spojenie, nie nevyhnutne samotné heslo. Na klientovi otvorte položku VPN, prejdite na kartu zabezpečenia, nastavte typ na Point-to-Point Tunneling Protocol, zvoľte explicitný zoznam protokolov a zaškrtnite Microsoft CHAP verzia 2.
Aktuálne nastavenie môžete prečítať bez preklikávania dialógu:
$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2
Server, ktorý vyžaduje MS-CHAP v2, odmieta klienta ponechaného na PAP alebo na automatickom type, ktorý dohaduje niečo slabšie, a chyba príde skôr, než sa vyhodnotí akékoľvek používateľské heslo. Formát účtu je druhá polovica toho istého odmietnutia. V jednom prípade Windows poslal identitu účtu Microsoft v tvare MicrosoftAccount\[email protected], kým server chcel miestny alebo doménový účet. Zadaním SERVERNAME\username sa Windowsu povedalo, ktoré úložisko účtov použiť, a chyba zmizla. Zadajte meno ručne, namiesto toho, aby uložené prihlasovacie údaje zopakovali predchádzajúci formát.
Výpadky po minúte sú rozhodnutie keepalive
Keď sa tunel pripojí, prepustí trochu prevádzky a potom sa odpojí, pozrite sa na správanie LCP echa servera skôr, než sa dotknete klienta. Démon pravidelne žiada partnera o potvrdenie, že je stále tam. Ak v nastavenom rozpočte príde príliš málo odpovedí, relácia sa zruší, aj keď používateľ má ešte fungujúce spojenie.
Na serveri Linux pptpd tieto hodnoty žijú v /etc/ppp/options.pptpd a zvyčajná oprava je rozpočet rozšíriť, nie interval skrátiť:
# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd
Tridsať minnutí pri intervale piatich sekúnd odpustí krátke zaseknutie, namiesto toho, aby partnera vyhlásilo za zmiznutého. Zníženie počtu na jeden alebo dva premení bežné chvenie na prekladanej ceste na odpojenie približne každú minútu. Ak je váš server Windows RRAS a nie pptpd, pozrite sa namiesto toho na časový limit relácie PPP a zásadu odpojenia pri nečinnosti. Tie žijú inde a úprava súboru pppd, ktorý neexistuje, nič nezmení.
Prekrývajúce sa podsiete rozbíjajú dátovú cestu
Tunel PPTP sa môže čisto overiť a napriek tomu nikam nedôjsť, keď obe lokality používajú rovnaký privátny rozsah, napríklad 192.168.1.0/24 v kancelárii aj doma. Klient nedokáže povedať, ku ktorému hostiteľovi daná adresa patrí, a niektoré zásobníky odmietajú trasu vôbec nainštalovať, namiesto toho, aby si jednu vybrali.
Berte to ako chybu návrhu a prečíslujte jednu stranu, alebo dajte klientovi zámerne preložený rozsah prístupu. Ladenie klienta PPTP nedokáže opraviť adresný priestor, ktorý existuje dvakrát, a príznak bude naďalej vyzerať ako náhodný výpadok.
Začnite fázou, ktorá zlyhala: GRE pre 800, metóda a reťazec účtu pre 812, nastavenia echa pre tunel, ktorý umiera podľa plánu.