Hindi gumagana ang split tunneling ng PPTP: ayusin muna ang GRE path

Panoorin ang isang PPTP connection na bumangon at madaling maniwala na tapos na ang mahirap na bahagi: nagpapatotoo ang client, may lumilitaw na ppp0 adapter o WAN Miniport, at nagiging berde ang status window. Pagkatapos ay nag-timeout ang unang kahilingan sa isang panloob na host, at ang profile ang sinisisi. Sa pagsasagawa, may dalawang independiyenteng layer na dapat linisin: ang panlabas na transport na nagdadala ng TCP 1723 at GRE, at ang panloob na patakaran na nagpapasya kung aling mga destinasyon ang gumagamit ng PPP interface. Ang berdeng status ay nagpapatunay lamang na nakipag-usap ang unang layer; wala itong sinasabi tungkol sa pangalawa.

Sundan ang client mula sa profile hanggang sa control socket

Buksan ang log ng client at hanapin ang puntong nakikipag-ugnayan ito sa server. Bumubukas muna ang PPTP ng TCP connection sa port 1723 at nakikipag-usap sa mga parameter ng tunnel sa channel na iyon. Kung mabigo ang hakbang na ito, wala nang mahalaga pagkatapos, at karaniwang tinutukoy ng error ang address ng server o timeout.

Kumpirmahin ang control connection sa wire bago hawakan ang anumang ruta. Sa client o mirror port, hulihin ang TCP 1723 para sa isang pagtatangkang kumonekta:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Ang natapos na handshake at naitatag na session ay nangangahulugang gumagana ang panlabas na control channel. Ang SYN na hindi kailanman tumatanggap ng SYN-ACK ay tumutukoy sa firewall, maling address ng server, o provider na nagsasala ng port. Ang handshake na sinusundan ng agarang reset ay kadalasang nangangahulugang tinanggihan ng server ang mga kredensyal o ang uri ng tunnel.

Ang GRE ay pangalawang protocol, hindi port

Dinadala ng PPTP ang PPP payload sa loob ng pinalawak na GRE, IP protocol 47, na walang port number na masusubaybayan ng router. Kaya naman ang panuntunang nagpapahintulot ng TCP 1723 ay maaari pa ring mag-iwan ng tunnel na walang data path. Kailangang maunawaan ng stateful NAT devices ang call ID sa loob ng GRE para ma-map pabalik ang mga tugon, at marami ang hindi ito ginagawa. Pinapanatili ng espesipikasyon ng PPTP ang control channel at GRE payload bilang magkahiwalay na bahagi, at ganoon din dapat ang plano mong pagsubok.

Panoorin ang protocol 47 sa parehong capture, pagkatapos ihambing ang lumalabas sa bumabalik:

sudo tcpdump -ni any 'proto gre' -c 20

Ang mga packet na lumalabas na walang tugon, habang nananatiling malusog ang TCP 1723, ay klasikong tanda ng naka-block na GRE. Ang passthrough ng PPTP sa consumer router ay tampok ng partikular na firmware na iyon, kaya ang gumaganang hotel network ay walang pinapatunayang anuman tungkol sa susunod. Kung walang passthrough ang router at hindi mo ito mababago, ang problema ay ang pagpili ng protocol, hindi ang routing table.

Patunayan na naglilipat ng isang packet ang tunnel

Kapag dumaloy ang GRE, naglalaan ang PPP negotiation ng address sa client interface. Basahin ang paglalaan sa halip na ipalagay ito:

ip -4 addr show ppp0

Ping ang peer address na ipinapakita bilang destinasyon ng point-to-point link. Ang tugon sa yugtong ito ay nagpapatunay na gumagana ang encapsulated path mula simula hanggang dulo at sumasagot ang server sa loob ng tunnel. Kung sumasagot ang peer pero hindi ang panloob na host, maayos ang panlabas na transport at lumipat papasok ang problema.

Gawin ito bago magdagdag ng anumang split route. Ang pagbabago ng ruta na ginawa habang sira ang transport ay lumilikha ng pangalawang variable at nagtatago ng una.

Isulat ang split policy, kasama ang DNS

Ang split routing ay listahan ng mga desisyon, hindi checkbox. Bawat pribadong prefix na kailangang tumawid sa tunnel ay nangangailangan ng ruta sa PPP interface, at bawat prefix na dapat manatiling lokal ay dapat na wala rito. Ang ruta para sa isang application subnet na walang tugmang ruta sa pribadong resolver nito ay karaniwang paraan ng paglikha ng pagkaantala na mukhang sirang app.

Tingnan ang desisyong ginagawa ng kernel para sa isang address sa bawat kategorya:

ip route get 10.20.5.10
ip route get 203.0.113.25

Dapat pangalanan ng una ang ppp0, ng pangalawa ang ordinaryong gateway. Kung pareho silang tumutukoy sa parehong interface, hindi talaga split ang patakaran. Idagdag ang address ng DNS server mismo sa tunnel list, kung hindi, ang name resolution para sa panloob na host ay lumalabas sa lokal na resolver at walang ibinabalik na kapaki-pakinabang.

Maugnaying pagsusuri sa limang hakbang

Patakbuhin ang mga layer sa pagkakasunod-sunod at huminto sa unang mabibigo: control channel, visibility ng GRE, tugon ng PPP peer, split route para sa isang panloob na address, at kahilingan ng application sa tunnel. Bawat hakbang ay may sariling command, kaya ang pagkabigo ay maiuugnay sa halip na mahiwaga.

Ang compact na bersyon para sa Linux client ay ganito:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Sa Windows, ang parehong pagkakasunod-sunod ay nalalapat sa route print at status ng adapter na ipinapakita sa client. Ang PPTP ay legacy protocol, at kung nag-aalok ang server ng SSTP o IKEv2, ang paglipat ay karaniwang mas mabuting paggamit ng oras kaysa sa pag-tune ng path na umaasa sa pagdaan ng protocol 47 sa bawat hop. Suriin ang certificate at authentication contract ng kapalit sa halip na kopyahin ang lumang profile sa bagong release.