PPTP-passthrough ûntbrekt: reparearje Windows VPN-flater 807

It trochjaan fan TCP 1723 iepent faak it earste part fan PPTP en lit de rest stikken, sadat Windows by de poging noch altiten flater 807 weromjout. De folgjende ympuls is in regel foar poarte 47 ta te foegjen, en krekt dy stap fergriemt in middei: GRE is in protokolnummer yn 'e IP-kop, gjin poarte dêr't in trochjaantabel op matchje kin. Oant de router protokol 47 trochlitte en oan deselde oprop ferbine sil, kin de tunnel net begjinne. De folgjende paragrafen skiede de twa kanalen en testen se dan ien foar ien.

In poartetabel hat gjin rige foar in protokolnummer

PPTP brûkt twa petearen dy't op ferskate wizen mislearje. It petear op TCP 1723 begjint de oprop, jout keppelingsynformaasje troch en brekt it ôf as de brûker ferbynt. De ladingkant rint binnen GRE, dat de IP-kop mei protokolnummer 47 markearret, en binnen dy tunnel ûnderhannelet PPP de keppeling wylst MS-CHAPv2 de oanmeldgegevens kontrolearret.

Om't GRE gjin ferfierkop draacht, lit it gjin poarten sjen, dus in regel dy't foar poarten skreaun is, hat neat om op te matchjen. In router dy't 1723 trochjout, makket in mapping foar dy TCP-sesje en hâldt dêr op. Firmware dy't de twadde helte ôfhannelet, neamt de funksje PPTP-passthrough of in PPTP-ALG, en guon firmware biedt gjin fan beide en neamt de gat nea. It label op it kontrôlefak is minder wichtich as de fraach oft protokol 47 hielendal werken wurdt.

Wat Windows meldt as it datapaad stjert

Flater 807 seit dat de ferbining net foltôge wurde koe, wat yn 'e praktyk betsjut dat de oprop de tsjinner berikte en it datakanaal net omheech kaam. It is in oardiel oer it ferfier, net oer it akkount. Flater 691 is dy't nei oanmeldgegevens of nei in misferstân yn it autentikaasjeprotokol wiist, dus dy stjoert dy hielendal earne oars hinne.

Wurkje oan it ferfier foardatst it wachtwurd oanrekket. Oanmeldgegevens feroarje om 807 te efterfolgjen lit de echte flater op syn plak en makket de folgjende poging dreger te lêzen.

Wêrom't in twadde klant in wurkjende tunnel brekt

Sûnder poarten om se te ûnderskieden, kin in NAT-apparaat twa PPTP-klanten net skiede sa't it twa HTTPS-sesjes skiedt. Dêrom tastean in protte konsuminteapparaten ien PPTP-oprop en folgje dat op boarneadres. In laptop dy't allinnich wurke, hâldt op mei foltôgjen sadree't in twadde masine útbelt, en fan 'e klantkant liket de flater tafallich. Dat patroan heart by de firmware, en gjin profylferoaring sil it feroarje.

Besjoch de ferbiningstabel wylst beide klanten útbelje. As allinnich de earste host ea in mapping hâldt, hat de router de grins fan syn stipe berikt en gjin klantynstelling sil dat ferwege.

Bewiis hokker helte mislearret

Befêstigje dat TCP 1723 oankomt foardatst wat op 'e router feroarret, want dat antwurd beslút hokker helte oftst testest. Fuortfierje dizze fan 'e Windows-klant tsjin dyn eigen tsjinnernamme. De earste prints oft de poarte antwurde, en de twadde belt sûnder dialooch, wat werhelle pogingen ferlykber makket.

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

In wier resultaat yn 'e poartetest betsjut dat it kontrôlekanaal iepen is en GRE de oerbliuwende fertochte. In falsk resultaat betsjut dat routing, in filter of it trochjaan stikken is, en gjin GRE-feroaring rêdt dat. De datakant moat besjoen wurde dêr't er te sjen is, by de tsjinner of by de router.

tcpdump -ni any proto 47

It ekwivalint yn Wireshark is it werjaanfilter ip proto 47, dat makliker is om oan immen te jaan dy't net noflik is op in kommandorigel. GRE dat oankomt sûnder dat der wat yn antwurd út giet, betsjut dat it werompaad reparearre wurde moat.

Wat de flater eins reparearret

Dêr't de router de ynstelling sjen lit, skeakelje PPTP-passthrough yn, of stean protokol 47 eksplisyt ta op firmware dy't regels akseptearret. Op RouterOS matcht de trochjaanregel it protokol direkt, wat in poartebasearre trochjaan nea kinnen hie. Konsumintefirmware ferberget itselde beslút meast efter in kontrôlefak, soms ûnder feiligensynstellingen ynstee fan ûnder poartetrochjaan. As sa'n kontrôle net bestiet, sil neat op 'e klant dat kompensearje.

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

PPTP ferfange is de oare opsje en faak de goedkeapere. In router dy't it VPN sels einiget, mijt dûbele NAT foar ynkommende klanten, en in protokol dat in poartebasearre NAT al oan kin, hat hielendal gjin passthrough nedich: OpenVPN oer UDP, SSTP oer TCP 443 of L2TP/IPsec mei NAT-T dat ESP yn UDP 4500 ynpakt. PPTP hinget ek fan MS-CHAPv2 ôf, waans dokumintearre swakheden it in minne kar meitsje foar in nije útrôl, sels nei't de flater fuort is.

Skriuw op hokker regel it ferskil makke, want deselde site sil deselde grins treffe as de twadde brûker tagong freget. In repaasje op protokolnivo heart yn 'e netwurknotysjes, dêr't de folgjende yngenieur sjen sil.