PPTP-flater 800 tsjin 812 en ferbiningen dy’t nei in minút falle

Flater 800, flater 812 en in PPTP-tunnel dy’t nei in minút stjert, binne trije aparte flaters. Keppelje elk symptoom oan de laach dy’t echt mislearre.

Trije flaters fan ien PPTP-klant beskriuwe meast trije ferskate flaters. Flater 800 betsjut dat de tunnel nea foarme waard, flater 812 betsjut dat de tsjinner de ferifikaasjemetoade wegere, en in ferbining dy’t nei in minút falt is in keepalive-timer dy’t beslút dat in sûne partner fuort is. Elk stadium mislearret om syn eigen reden, dus elk hat syn eigen kontrôle nedich.

Flater 800 betsjut dat de tunnel nea foarme waard

Windows jout flater 800 as it de tunnel hielendal net bouwe kin, en de tekst oer in net berikbere tsjinner of ûngeskikte befeiligingsparameters is in gearfetting en gjin diagnoaze. PPTP hat twa aparte dingen fan it netwurk nedich foar’t hokker bewiis fan identiteit dan ek ûndersocht wurdt. TCP 1723 draacht it kontrôlekanaal, en IP-protokol 47, GRE, draacht de ferkapsulearre lading.

Test dat bûtenpaad fan bûten dyn eigen LAN, want in ferbining dy’t op kantoar wurket bewiist neat oer de râne:

$ 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

As 1723 antwurdet en de opname bliuwt leech wylst de klant besiket te ferbinen, lit it paad protokol 47 falle. In router mei 1723 trochstjoerd mar PPTP-passthrough útskeakele jout krekt dat patroan: de TCP-hânskieding foltôget, dan ferdwine de GRE-pakketten, sadat de flater as in probleem mei bewiis fan identiteit liket, ek al is gjin oanmelding besocht.

Rjochtsje de trochstjoering op it hjoeddeiske LAN-adres fan de tsjinner, skeakelje PPTP-passthrough oan wêr’t de router it biedt, en besykje opnij fan itselde bûtenpunt. As GRE streamop filtere wurdt en do dat net feroarje kinst, hat SSTP oer TCP 443 of L2TP/IPsec oer UDP 500 en 4500 in bettere kâns as hokker feroaring dan ek dy’tst oan de Windows-kant meitsje kinst.

Flater 812 is de tsjinner dy’t dyn ferifikaasjemetoade wegeret

Flater 812 komt werom neidat de tunnel omheech is, dêrom fielt it as in wachtwurdprobleem. De tsjinner wegeret de ferifikaasjemetoade dy’t foar de ferbining ôfsprutsen is, net needsaaklik it wachtwurd sels. Iepenje op de klant de VPN-yngong, gean nei it befeiligingstab, set it type op Point-to-Point Tunneling Protocol, kies de eksplisite protokol-list en set in fluch by Microsoft CHAP ferzje 2.

Do kinst de hjoeddeiske ynstelling lêze sûnder troch de dialooch te klikken:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

In tsjinner dy’t MS-CHAP v2 easket, wegeret in klant dy’t op PAP of op in automatysk type litten is dat eat swakker ôfslút, en de flater komt foar’t hokker brûkerswachtwurd dan ek beoardiele wurdt. It accountformaasje is de oare helte fan deselde wegering. Yn ien gefal stjoerde Windows in Microsoft-accountidentiteit fan de foarm MicrosoftAccount\[email protected] wylst de tsjinner in lokaal of domeinaccount woe. SERVERNAME\username typen fertelde Windows hokker accountopslach rieplachte wurde moat en helle de flater fuort. Fier de namme mei de hân yn ynstee fan in bewarre bewiis fan identiteit in earder formaat werhelje te litten.

Fallen nei in minút binne in keepalive-beslút

As de tunnel ferbynt, in bytsje ferkear trochlit en dan ôfbrekt, sjoch dan nei it LCP-echogedrach fan de tsjinner foar’tst de klant oanrekkest. De daemon freget de partner geregeldwei om te befêstigjen dat er noch dêr is. As der te min antwurden binnen it ynstelde budzjet komme, wurdt de sesje ôfbrutsen ek al hat de brûker noch in wurkjende keppeling.

Op in Linux pptpd-tsjinner wenje dy wearden yn /etc/ppp/options.pptpd, en de gewoane reparaasje is it budzjet te ferbreedzjen ynstee fan it ynterval te ferkoartsjen:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Tritich misten by in ynterval fan fiif sekonden ferjaan in koarte stoppen ynstee fan de partner as fuort te ferklearjen. It oantal werombringe nei ien of twa makket gewoane jitter op in oerset paad in ôfbrekken omtrint elke minút. As dyn tsjinner Windows RRAS is ynstee fan pptpd, sjoch dan ynstee nei de PPP-sesjetiidlimit en it belied foar ôfbrekken by ydle steat. Dy wenje earne oars, en in pppd-bestân bewurkje dat net bestiet sil neat feroarje.

Oerlaapjende subnetten brekke it datapaad

In PPTP-tunnel kin skjin ferifiearje en dochs neat berikke as beide plakken itselde partikuliere berik brûke, bygelyks 192.168.1.0/24 op kantoar en thús. De klant kin net sizze hokker host in opjûn adres bedoelt, en guon stapels wegerje de rûte hielendal te ynstallearjen ynstee fan ien te kiezen.

Behannelje dat as in ûntwerpfout en nûmerje ien kant opnij, of jou de klant in bewust oerset berik foar tagong. It debuggen fan de PPTP-klant kin in adresromte dy’t twa kear bestiet net reparearje, en it symptoom sil bliuwe lykjen op in tafallich fal.

Begjin by it stadium dat mislearre: GRE foar 800, de metoade en accountstring foar 812, echoynstellingen foar in tunnel dy’t neffens skema stjert.

Relatearre artikelen