Nakakonekta ang VPN pero isang serbisyo ang nabibigo: ihiwalay ang yugto

Ang «nakakonekta» ang pinakakaunting impormasyong katotohanan sa isang VPN ticket. Itinatala nito na natapos ng dalawang panig ang handshake at wala tungkol sa pangalang tinanong, ang interface na nilabasan ng packet, ang laki nito, o kung tinanggap ito ng malayong dulo. Kaya nabibigo ang isang serbisyo habang gumagana ang bawat ibang aplikasyon sa parehong laptop. Dumaan sa mga yugto nang sunod-sunod at ang unang nabigo ang magpapangalan sa depekto.

Magsimula sa pangalan, hindi sa tunnel

I-resolve bago mag-ruta, dahil ginagawang walang saysay ng masamang sagot ang bawat susunod na pagsubok. Tanungin ang pangalan sa resolver ng system at ihambing ang sagot sa address na aktuwal na ginamit ng aplikasyon. Ang pribadong pangalan na bumabalik bilang pampublikong address ay nangangahulugang napunta ang query sa resolver na walang kinalaman sa pagsagot nito. Ang pangalang hindi nagre-resolve ay parehong kategorya, mas malakas lang.

resolvectl query host.internal
getent hosts host.internal

Ang mga browser na may sariling setting ng secure DNS ay nabibigo rito habang gumagana ang ibang bahagi ng system. Kaya ang reklamong tungkol lamang sa browser ay kabilang muna sa yugtong ito, bago may humawak ng ruta. Ihambing ang dalawang command at hindi isa, dahil sinusundan ng getent ang landas ng NSS at hindi ang query sa resolver.

Tanungin ang kernel kung aling landas ang pinili nito

Ang routing table ay isang pagkakasunod-sunod ng priyoridad, at ang landas na pinipili ng kernel ay hindi laging iyon sa diagram. Tanungin ito nang direkta tungkol sa destinasyong pinag-uusapan. Pinapangalanan ng sagot ang interface, ang susunod na hop at ang source address na gagamitin. Maaaring lumabas ang packet sa tunnel dala ang source address na tinatanggihan ng malayong dulo, at ang mas tiyak na entry sa pisikal na table ay maaaring magpadala nito sa interface ng Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Basahin ang mga field na dev, via at src sa ganoong ayos, dahil inaalis ng bawat isa ang ibang hinala. Pagmamay-ari rin ng yugtong ito ang estadong inilagay ng kliyente, dahil ang mga patakaran ng firewall at ruta ay maaaring manatili pagkatapos ng abnormal na paglabas. Kaya ang «walang internet kung walang tunnel» at «walang internet maliban kung tumatakbo ang kliyente» ay isang pamilya ng depekto, hindi dalawa.

Subukan ang laki ng packet

Ang maliit na sagot na bumabalik habang natigil ang malaking paglilipat tumuturo muna sa MTU ng landas. Isang probe na may nakatakdang do-not-fragment bit, na ipinadala mula sa loob ng tunnel, ang naghihiwalay sa yugtong ito mula sa iba. Itaas ang payload hanggang mabigo ang probe at mayroon ka na ang numerong mahalaga.

ping -M do -s 1400 10.20.30.40

Ang pagpasa ng maliliit na probe habang nakabitin ang listahan ng folder o upload ay ang lagda ng yugtong ito. Ang reklamo ay parang kredensyal o patakaran ng firewall, at hindi ito alinman sa dalawa.

Ang numero ay katangian ng landas, hindi ng kliyente, kaya ang halagang gumagana sa koneksyon sa opisina ay maaaring mabigo sa mobile link. Itago ang probe command kasama ng ticket, dahil kailangan ng susunod na tao ang parehong pagsukat. Kung pumasa ang mas maliit na payload, ang solusyon ay clamp o mas mababang MTU ng tunnel, hindi bagong cipher.

Subukan ang malayong dulo

Subukan ang destinasyon sa address nito, pagkatapos tingnan kung ano ang nakikinig doon. Ang tinanggihang koneksyon at koneksyong hindi kailanman sumasagot ay magkaibang natuklasan. Sinasabi ng una na may tumatakbo at hindi nagseserbisyo sa port na iyon, at sinasabi ng pangalawa na walang bumalik. Wala sa dalawa ang problema ng kliyente bilang default.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Wala sa maaabot sa pamamagitan ng tunnel ang maaaring maging serbisyong nakikinig lamang sa 127.0.0.1, dahil hindi kailanman nakikita ng listener ang packet. Kapag pinapayagan ng firewall ng malayong host ang subnet ng opisina at tinatanggihan ang pool ng tunnel, ang resulta ay mukhang depekto ng kliyente at hindi. Ang Remote Desktop o pagbabahagi ng file na nasisira habang nabubuhay ang trapik ng web ay karaniwang napupunta rito, anuman ang sabihin ng gumagamit.

Itugma ang reklamo sa isang yugto

Karamihan sa mga ulat ay nahuhulog sa isa sa limang hugis, at pinapangalanan ng bawat hugis ang isang yugto. Ang isang site na gumagana lamang sa tunnel ay sagot ng pangalan o patakarang nakatali sa source address. Ang mga update na nabibigo nang walang tunnel habang gumagana ang pagba-browse ay problema ng pangalan o ruta para sa kliyenteng iyon.

Ang paghinto ng lahat kapag nagsimula ang kliyente ng provider ay naka-install na estado, ibig sabihin, usapin ng ruta at firewall. Ang isang serbisyong hindi maabot habang maayos ang iba ay ang malayong dulo. Ang mga paglilipat na natitigil pagkalipas ng ilang segundo ay ang laki ng packet. Itugma ang hugis bago magpatakbo ng mga command, dahil ito ang nagtatakda kung aling ebidensya ang unang kokolektahin.

Itala ang yugtong gumawa ng unang pagkabigo kasama ang output ng command. Ang ticket na nagsasabing mali ang source address, na may nakalakip na linya ng ruta, ay karapat-dapat aksyunan, samantalang ang nag-uulat na sira ang VPN ay hindi.