PPTP грешка 800 наспроти 812 и прекини по една минута
Грешката 800, грешката 812 и PPTP тунел што умира по една минута се три различни дефекти. Поврзете го секој симптом со слојот што навистина откажал.
Три пораки за грешка од еден PPTP клиент обично опишуваат три различни дефекти. Грешката 800 значи дека тунелот никогаш не се формирал, грешката 812 значи дека серверот го одбил методот за автентикација, а прекинот по една минута е keepalive тајмер што одлучува дека здрав партнер си заминал. Секоја фаза откажува поради своја причина, затоа секоја бара своја проверка.
Грешката 800 значи дека тунелот никогаш не се формирал
Windows ја подига грешката 800 кога воопшто не може да го изгради тунелот, а текстот за недостапен сервер или несоодветни безбедносни параметри е резиме, а не дијагноза. PPTP бара две одделни работи од мрежата пред да се провери било кој акредитив. TCP 1723 го носи контролниот канал, а IP протоколот 47, GRE, ја носи инкапсулираната покривка.
Тестирајте ја таа надворешна патека од надвор од вашиот LAN, бидејќи врска што работи во канцеларијата не докажува ништо за работ:
$ 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
Ако 1723 одговори, а снимката остане празна додека клиентот се обидува да се поврзе, патеката го отфрла протоколот 47. Рутер со пренасочен 1723, но исклучен PPTP passthrough дава токму таква слика: TCP ракувањето завршува, потоа GRE пакетите исчезнуваат, па дефектот изгледа како проблем со акредитиви, иако не е направен обид за најава.
Насочете го пренасочувањето кон тековната LAN адреса на серверот, вклучете PPTP passthrough каде рутерот го нуди и обидете се повторно од истата надворешна точка. Кога GRE се филтрира погоре и не можете да го смените, SSTP преку TCP 443 или L2TP/IPsec преку UDP 500 и 4500 има подобра шанса од која било промена на страната на Windows.
Грешката 812 е одбивање на вашиот метод за автентикација од серверот
Грешката 812 се враќа откако тунелот ќе се подигне, затоа изгледа како проблем со лозинка. Серверот го одбива методот за автентикација договорен за врската, а не нужно самата лозинка. На клиентот отворете го VPN записот, одете на јазичето за безбедност, поставете го типот на Point-to-Point Tunneling Protocol, изберете го експлицитниот список протоколи и штиклирајте Microsoft CHAP верзија 2.
Тековното поставување можете да го прочитате без кликање низ дијалогот:
$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2
Сервер што бара MS-CHAP v2 го одбива клиентот оставен на PAP или на автоматски тип што договара нешто послабо, а грешката пристигнува пред да се оцени каква било корисничка лозинка. Форматот на сметката е другата половина од истото одбивање. Во еден случај Windows испрати идентитет на Microsoft сметка во форма MicrosoftAccount\[email protected], а серверот сакаше локална или доменска сметка. Впишувањето SERVERNAME\username му кажа на Windows кое складиште на сметки да го користи и ја отстрани грешката. Внесете го името рачно, наместо да дозволите зачуван акредитив да го повтори претходниот формат.
Прекините по една минута се одлука на keepalive
Кога тунелот се поврзува, пропушта малку сообраќај и потоа се исклучува, погледнете го однесувањето на LCP ехото на серверот пред да го допрете клиентот. Демонот периодично бара од партнерот да потврди дека е се уште таму. Ако во поставениот буџет пристигнат премалку одговори, сесијата се урива иако корисникот се уште има работна врска.
На Linux pptpd сервер тие вредности живеат во /etc/ppp/options.pptpd, а вообичаената поправка е да се прошири буџетот наместо да се скрати интервалот:
# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd
Триесет промашувања на интервал од пет секунди простуваат краток застој наместо да го прогласат партнерот за исчезнат. Намалувањето на бројот на еден или два го претвора вообичаеното треперење на преведена патека во исклучување приближно секоја минута. Ако вашиот сервер е Windows RRAS, а не pptpd, гледајте го наместо тоа тајмаутот на PPP сесијата и политиката за исклучување при мирување. Тие живеат на друго место, а уредувањето на pppd датотека што не постои нема да смени ништо.
Преклопувачките подмрежи ја кршат податочната патека
PPTP тунелот може чисто да се автентицира и сепак да не стигне никаде кога двете локации го користат истиот приватен опсег, на пример 192.168.1.0/24 во канцеларија и дома. Клиентот не може да каже на кој домаќин се однесува дадена адреса, а некои стекови воопшто одбиваат да ја инсталираат рутата наместо да изберат една.
Третирајте го тоа како дизајнерски дефект и пренумерирајте една страна, или дајте му на клиентот намерно преведен опсег за пристап. Дебагирањето на PPTP клиентот не може да поправи адресен простор што постои двапати, а симптомот ќе продолжи да изгледа како случаен прекин.
Започнете со фазата што откажала: GRE за 800, методот и низата на сметката за 812, поставките за ехо за тунел што умира по распоред.