Nawawala ang web server kapag kumokonekta ang VPN client

Ang serbisyong nawawala sa sandaling kumonekta ang isang VPN client ay karaniwang hindi hinaharangan, sumasagot ito sa maling interface. Dumarating ang kahilingan sa pisikal na network card, nagsusulat ang daemon ng sagot, at ibinibigay ng routing table ang sagot na iyon sa tunnel, dahil kinuha na ng tunnel ang default na ruta. Hindi kailanman nakikita ng malayong client ang sagot sa koneksiyong binuksan niya, kaya naghihintay ito at pagkatapos ay nag-uulat ng timeout. Walang patakaran ng firewall na kasangkot saanman sa pagkakasunod-sunod na iyon.

Ang sintomas: mga kahilingan papasok, mga sagot palabas sa maling pinto

Ang palatandaan ay isang papasok na koneksiyon na nabibigo habang gumagana ang lahat ng iba pa sa host. Isa pang palatandaan ay isang host na maabot mula sa LAN ngunit hindi mula sa internet, o isang gumagana hanggang sa muling kumonekta ang tunnel at pagkatapos ay tumitigil. Sa bawat kaso gumana nang maayos ang pasulong na direksiyon at hindi ang pabalik, na tumutukoy sa asimetriya ng routing at hindi sa patakaran.

Kumpirmahin ito sa pamamagitan ng pagtingin kung saan pumupunta ang sagot, hindi sa pagtingin kung paano dumarating ang kahilingan.

Kunin nang sabay sa pisikal na interface at sa aparato ng tunnel. Kung lumitaw ang kahilingan sa pisikal na interface at ang sagot sa tunnel, tapos na ang diagnosis. Ang sagot na hindi lumilitaw kahit saan ay nangangahulugang hindi kailanman tinanggap ng serbisyo ang koneksiyon, na isang hiwalay na imbestigasyon na may hiwalay na dahilan.

Dalawang default na ruta at isang desisyon sa routing

Ang client na naglalagay ng default na ruta ay nagdaragdag ng pangalawang entry na may mas mahusay na metro kaysa sa gateway ng LAN. Ang ilang client ay naglalagay sa halip ng dalawang kalahating-saklaw na ruta, na sumasaklaw sa parehong espasyo nang mas partikular at nananalo sa paghahanap sa parehong paraan. Ang alinman sa dalawang pamamaraan ay nag-iiwan sa mga ordinaryong palabas na packet na pumipili ng interface ng tunnel.

Ang pagpiling iyon ay ginagawa sa destinasyon lamang. Ang kernel ay hindi nagtatanong kung saan galing ang isang packet maliban kung utusan ito ng patakaran. Kaya ang sagot sa isang pampublikong address ng client ay ibinibigay sa tunnel, na ang malayong dulo ay tumatanggap ng packet na may source address na hindi pag-aari nito at itinatapon ito o ipinapasa sa kung saan walang silbi. Sa Linux, ang mahigpit na reverse-path filtering ay maaari ring itapon ang orihinal na kahilingan bago pa man ito makita ng iyong serbisyo, na mukhang pareho mula sa labas. Ang parehong sintomas ay nagmumula sa parehong nawawalang kaugnayan sa pagitan ng papasok na daloy at ng sagot nito.

Kumikilos nang tama ang tunnel sa buong panahon. Sinabihan itong magdala ng default na ruta at ginagawa nito nang eksakto iyon.

Ayusin ang pabalik na landas nang hindi sinisira ang tunnel

May tatlong matibay na anyo ng pag-aayos, at ang pagpili ay nakadepende sa kung gaano karami sa sariling trapiko ng host ang dapat manatili sa loob ng tunnel. Ang pagbubukod sa destinasyon o port ng serbisyo ang pinakamaliit na pagbabago. Ang policy routing ayon sa source o marka ang pinakatumpak. Ang pagsasalin ng source ang pinakamagaspang at pinakamadaling ipaliwanag pagkalipas ng dalawang taon.

Pumili ayon sa dapat gawin ng host, hindi ayon sa kung aling sipi ang una mong nakita.

Ang pagbubukod ng destinasyon ay bagay sa serbisyong may matatag na pampublikong address, at ang pagbigkis ng daemon sa pisikal na address sa halip na sa bawat address ay ginagawang mas ligtas ang pagbubukod na iyon. Ang patakaran na pumipili ng table ayon sa source ay nagpapanatili sa mga koneksiyon ng host sa loob ng tunnel habang ibinabalik ang mga sagot ng serbisyo sa pamamagitan ng gateway ng WAN. Ang pag-mask ng mga sagot sa interface ng WAN ay umabot sa parehong landas kapalit ng pagtatago ng address ng client mula sa mga log ng serbisyo. Ang ad hoc na pagbabago ng default na ruta ay isang diagnosis at hindi isang konfigurasyon, dahil isinusulat muli ng client ang mga ruta sa bawat muling pagkonekta.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Kapag ang host ay nagru-ruta rin para sa isang LAN sa likuran nito

Isang hakbang pa palabas, bumabalik ang parehong asimetriya na may mas maraming gumagalaw na bahagi. Umaabot ang trapiko sa router mula sa internet, ipinapasa sa isang panloob na aparato, at ang tanging pabalik na landas ng aparatong iyon ay ang tunnel, kaya umaabot ang sagot sa orihinal na client mula sa address ng provider mismo. Pagkatapos ay nakatagpo ang pagsubaybay ng koneksiyon ng sagot para sa isang daloy na hindi nito nakitang nagsimula, at itinatapon ito. Samantala, wala talagang nakikita ang client.

Dalawang pagbabago ang nag-aayos nito: pagsasalin ng destinasyon upang maabot ng papasok na koneksiyon ang panloob na aparato, at pagsasalin ng source upang ang sagot ng aparatong iyon ay tila nagmumula sa router mismo.

Sa firmware ng router ang karaniwang pananalita ay isang patakaran na nagtatakda ng port forwarding sa gilid ng WAN habang ang sariling trapiko ng router ay sumasakay sa tunnel. Kung walang pagsasalin ng source, ang sagot na iyon ay naka-address sa panlabas na client at ang panloob na aparato ay simpleng walang ruta papunta roon. Subukan ang tatlong bagay nang hiwalay, dahil nabibigo sila sa magkaibang dahilan: isang koneksiyong dumarating mula sa labas, isa na ang host mismo ang nag-uumpisa, at isang paghahanap ng pangalan.