Trūksta PPTP pralaidumo: pataisykite Windows VPN klaidą 807

TCP 1723 persiuntimas dažnai atveria pirmąją PPTP dalį, o likusią palieka sulaužytą, todėl Windows bandant vis tiek grąžina klaidą 807. Kitas instinktas – pridėti taisyklę 47 prievadui, ir būtent šis žingsnis sugaišta pusdienį: GRE yra protokolo numeris IP antraštėje, o ne prievadas, kurį persiuntimo lentelė galėtų sutapatinti. Kol maršrutizatorius nepraleis 47 protokolo ir nesies jį su tuo pačiu skambučiu, tunelis negali prasidėti. Toliau pateikti skyriai atskiria du kanalus ir po to tikrina juos po vieną.

Prievadų lentelėje nėra eilutės protokolo numeriui

PPTP naudoja du pokalbius, kurie žlunga skirtingai. Pokalbis per TCP 1723 pradeda skambutį, perduoda ryšio informaciją ir nutraukia jį, kai vartotojas atsijungia. Naudingosios apkrovos pusė veikia GRE viduje, kurį IP antraštė žymi protokolo numeriu 47, o tame tunelyje PPP derasi dėl ryšio, kol MS-CHAPv2 tikrina prisijungimo duomenis.

Kadangi GRE neturi transporto antraštės, jis neatskleidžia jokių prievadų, todėl taisyklė, parašyta prievadams, neturi ko sutapatinti. Maršrutizatorius, kuris persiunčia 1723, sukuria susiejimą tai TCP sesijai ir ten sustoja. Programinė įranga, kuri tvarko antrąją pusę, šią funkciją vadina PPTP pralaidumu arba PPTP ALG, o kai kuri programinė įranga nesiūlo nė vieno ir niekada nemini šios spragos. Etiketė ant žymės langelio mažiau svarbi nei tai, ar 47 protokolas apskritai atpažįstamas.

Ką Windows praneša, kai miršta duomenų kelias

Klaida 807 sako, kad ryšio nepavyko užbaigti, o praktiškai tai reiškia, kad skambutis pasiekė serverį, o duomenų kanalas neatsistojo. Tai nuosprendis apie transportą, o ne apie paskyrą. Klaida 691 yra ta, kuri nurodo prisijungimo duomenis arba autentifikavimo protokolo neatitikimą, todėl ji nukreipia visai kitur.

Dirbkite su transportu, kol nelietėte slaptažodžio. Prisijungimo duomenų keitimas vejantis 807 palieka tikrą gedimą vietoje ir padaro kitą bandymą sunkiau perskaitomą.

Kodėl antras klientas sugadina veikiantį tunelį

Neturint prievadų jiems atskirti, NAT įrenginys negali atskirti dviejų PPTP klientų taip, kaip atskiria dvi HTTPS sesijas. Todėl daug vartotojiškų įrenginių leidžia tik vieną PPTP skambutį ir seka jį pagal šaltinio adresą. Nešiojamasis kompiuteris, kuris veikė vienas, nustoja užbaigti vos kitai mašinai surinkus numerį, o iš kliento pusės gedimas atrodo atsitiktinis. Šis modelis priklauso programinei įrangai, ir joks profilio pakeitimas jo nepakeis.

Stebėkite jungčių lentelę, kol abu klientai renka numerį. Jei susiejimą visada turi tik pirmasis kompiuteris, maršrutizatorius pasiekė savo palaikymo ribą ir joks kliento nustatymas to nepajudins.

Įrodykite, kuri pusė žlunga

Prieš ką nors keisdami maršrutizatoriuje patvirtinkite, kad TCP 1723 ateina, nes tas atsakymas nulemia, kurią pusę testuojate. Vykdykite tai iš Windows kliento prieš savo serverio vardą. Pirmoji komanda išspausdina, ar prievadas atsakė, o antroji skambina be dialogo, todėl pakartotiniai bandymai tampa palyginami.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Tikras prievado testo rezultatas reiškia, kad valdymo kanalas atviras ir GRE yra likęs įtariamasis. Klaidingas rezultatas reiškia, kad maršrutizavimas, filtras arba persiuntimas sugedę, ir joks GRE pakeitimas to neišgelbės. Duomenų pusę reikia stebėti ten, kur ją galima matyti, serveryje arba maršrutizatoriuje.

tcpdump -ni any proto 47

Wireshark atitikmuo yra rodymo filtras ip proto 47, kurį lengviau perduoti tam, kam nepatogu komandinėje eilutėje. GRE, kuris ateina niekam neišėjus atsakyme, reiškia, kad grįžimo kelią reikia pataisyti.

Kas iš tikrųjų pataiso klaidą

Ten, kur maršrutizatorius rodo nustatymą, įjunkite PPTP pralaidumą arba aiškiai leiskite 47 protokolą programinėje įrangoje, kuri priima taisykles. RouterOS persiuntimo taisyklė tiesiogiai sutapatina protokolą, ko prievadais pagrįstas persiuntimas niekada negalėjo padaryti. Vartotojiška programinė įranga paprastai slepia tą patį sprendimą už žymės langelio, kartais saugumo nustatymuose, o ne prievadų persiuntime. Jei tokios kontrolės nėra, kliente niekas to nekompensuos.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP pakeitimas yra kita galimybė ir dažnai pigesnė. Maršrutizatorius, kuris pats užbaigia VPN, išvengia dvigubo NAT įeinantiems klientams, o protokolui, kurį prievadais pagrįstas NAT jau tvarko, pralaidumo visai nereikia: OpenVPN per UDP, SSTP per TCP 443 arba L2TP/IPsec su NAT-T, kuris įvynioja ESP į UDP 4500. PPTP taip pat priklauso nuo MS-CHAPv2, kurio dokumentuoti trūkumai daro jį blogu pasirinkimu naujam diegimui net ir po to, kai klaida išnyksta.

Užsirašykite, kuri taisyklė padarė skirtumą, nes ta pati vieta susidurs su ta pačia riba, kai antras vartotojas paprašys prieigos. Protokolo lygio pataisymas priklauso tinklo užrašams, kur pažiūrės kitas inžinierius.