Talaan ng ruta laban sa aktwal na paghahanap: saan napupunta ang trapiko ng VPN

Ang dump ng talaan ng ruta ay ang pinakamaliit na kapaki-pakinabang na diagnostic sa pag-troubleshoot ng VPN at ang pinakamadalas na i-paste. Apatnapung linya ng mga prefix ang nagsasabi sa iyo kung ano ang kaya ng makina, hindi kung ano ang ginawa nito para sa nabigong kahilingan. Ang mekanismong talagang kailangan mo ay ang paghahanap: ibinigay ang pinagmulang ito at destinasyong ito, aling tuntunin ang tumugma, aling talaan ang sinangguni, at aling interface at susunod na hop ang lumabas. Magsimula sa isang destinasyon at isang pinagmulan, pagkatapos basahin ang talaan na may tanong na iyon sa kamay, at ang parehong output ay nagiging ebidensya sa halip na ingay.

Ang talaan ay isang hanay ng mga kandidato, hindi isang desisyon

Inilalarawan ng bawat entry ang isang prefix at kung ano ang gagawin sa trapikong tumutugma dito: ipadala ito sa isang interface, ibigay ito sa susunod na hop, o itapon ito. Wala sa listahang iyon ang nakaayos ayon sa layunin, at ang entry na pinakaspecific sa tingin ng tao ay hindi laging ang pinipili ng kernel, dahil ang pagpili ay sumusunod sa pinakamahabang tugma ng prefix at, sa magkatulad na prefix, sa metric.

Kaya ang unang hakbang ay tanungin ang kernel sa halip na basahin ang listahan. Ang utos ng paghahanap ay sumasagot para sa isang destinasyon, at sa argumentong pinagmulan ay sumasagot ito para sa eksaktong pares na gagamitin ng isang forward o bound na koneksyon:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Ang bawat address sa itaas ay halimbawa ng dokumentasyon. Ang punto ay ang hugis ng sagot: interface, piniling address ng pinagmulan, gateway, at ang talaan kung saan nagmula ang entry. Kung ang output na iyon ay hindi tumutugma sa interface na inaasahan mo, na-localize mo ang problema sa isang utos, at walang dami ng pagbasa ng buong talaan ang magsasabi sa iyo kung aling kandidato ang nanalo.

Ang paghahanap ay dumadaan sa mga tuntunin, pagkatapos sa mga talaan

Sa Linux ang desisyon ay nasa dalawang yugto. Ang mga tuntunin ng patakaran ay sinusuri sa pagkakasunod-sunod ng priyoridad, at ang unang tuntuning tumutugma ay nagsasabi ng talaang sasangguni; ang talaang iyon ang gagawa ng pinakamahabang tugma ng prefix. Ang isang tuntunin ay maaaring tumugma sa pinagmulan, destinasyon, marka ng firewall, interface o kumbinasyon, kaya ang dump ng pangunahing talaan ay maaaring ganap na tumpak at ganap na walang kaugnayan sa packet na iniimbestigahan mo.

ip rule show
ip route show table all | head -40
ip route show table 100

Kung ang isang tuntunin ay nagpapadala ng trapiko mula sa iyong VPN pool patungo sa talaan 100, ang mahalaga ay ang talaan 100, at ang pangunahing talaan ay pain. Ito rin ang mekanismo sa likod ng routing na nakabatay sa pinagmulan sa isang router: ang parehong destinasyon ay maaaring magkaroon ng dalawang magkaibang sagot depende sa pinanggalingan ng packet, at tanging ang paghahanap na may argumentong pinagmulan ang nagbubunyag kung alin ang naaangkop.

Ang IPv6 ay may sariling mga tuntunin at talaan. Ang disenyong nagpapatakbo ng parehong pamilya ay nangangailangan ng parehong paghahanap, at ang gumaganang sagot ng IPv4 ay walang sinasabi tungkol sa landas ng v6 na maaaring mas gusto ng dual-stack na kliyente.

Ano ang ini-install ng kliyente ng VPN

Karaniwang hindi pinapalitan ng mga kliyente ang default na ruta, dahil masisira nito ang sariling panlabas na landas ng tunnel. Nag-i-install sila ng mas specific na nananalo sa haba ng prefix: ang pares ng half-default na sumasakop sa 0.0.0.0/1 at 128.0.0.0/1 ay ang klasikong trick, dahil pareho silang mas mahabang prefix kaysa 0.0.0.0/0 at magkasamang sumasakop sa buong espasyo. Ang iba ay nag-i-install ng mga partikular na pribadong prefix at tuntunin ng patakaran, at ang ilan ay nagdadagdag ng marka upang tanging piling trapiko ang mahuli.

Kaya ang "hindi binago ng VPN ang aking default na ruta" ay hindi ebidensya ng pagkabigo. Suriin kung ano talaga ang idinagdag nito, at kung ang destinasyong pinag-uusapan ay nasa loob ng mga prefix na iyon:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Ang dalawang half-route ay madaling makaligtaan sa isang dump dahil hindi sila mukhang default. Ang isang split-tunnel configuration na nakalimutang isama ang isang prefix ay gumagawa ng eksaktong sintomas na hinahabol mo: ang application na dapat gumamit ng tunnel ay nagre-resolve at kumokonekta nang lokal sa halip. Ihambing ang mga naka-install na prefix sa mga destinasyong talagang kailangan ng user, hindi sa mga address na nagkataon mong sinubukan. Ang isang listahan ng split-tunnel na sumasakop sa file server ngunit hindi sa resolver nito ay gumagawa ng koneksyong nagre-resolve sa isang pampublikong address at pagkatapos ay nabibigo sa authentication, na mukhang problema sa password at problema sa ruta.

Kailangan ding mabuhay ang panlabas na ruta

Ang tunnel mismo ay trapiko. Ang mga packet na nagdadala ng encapsulated payload ay pumupunta sa address ng peer sa pamamagitan ng pisikal na interface, at ang landas na iyon ay hindi dapat i-route pabalik sa tunnel. Kapag nangyari ito, makukuha mo ang kakaibang pagkabigo kung saan ang tunnel ay naitatag at pagkatapos ay tumitigil sa pagpapadala ng trapiko, dahil ang transport para sa tunnel ay nasa loob na ng tunnel.

Suriin ang address ng peer tulad ng pag-suri mo sa panloob na destinasyon, at kumpirmahin na nagre-resolve ito sa pisikal na interface at hindi sa tunnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Ang recursive na ruta, tuntunin ng patakarang humuhuli sa peer, o default na pinalitan ng full-tunnel na kliyente ay ang tatlong karaniwang dahilan. Lahat ng tatlo ay nakikita sa panlabas na paghahanap, at wala sa kanila ang nakikita sa dump ng pangunahing talaan na kinuha pagkatapos ng pangyayari.

Ano ang hindi masasabi sa iyo ng output ng routing

Ang tamang paghahanap ay nangangahulugan na ipapadala ng kernel ang packet sa isang makatwirang lugar. Hindi ito nangangahulugan na pinapayagan ito ng firewall, sinasaklaw ito ng patakaran ng IPsec, isinasalin ito ng tuntunin ng NAT, o may return route ang malayong panig. Ang bawat isa sa mga ito ay susunod na yugto, at ang mga tala ng strongSwan tungkol sa pag-forward ay naglalarawan ng chain na dapat daanan ng packet sa magkabilang dulo.

Hindi rin nito isinasaalang-alang ang binding sa antas ng application. Ang isang proseso ay maaaring mag-bind sa isang interface, magtakda ng marka, o gumamit ng sariling resolver at kumonekta sa isang pangalang nagre-resolve nang iba kaysa sa sinubukan mo. Kapag tama ang paghahanap at nabibigo pa rin ang koneksyon, ang susunod na tanong ay aling proseso ang gumagawa nito at nakikita ba ng prosesong iyon ang parehong talaan na nakikita mo.

Kaya panatilihing maayos ang diagnosis: pangalanan ang destinasyon at pinagmulan, patakbuhin ang paghahanap, basahin lamang ang talaan at tuntuning pinangalanan ng paghahanap, pagkatapos ay subukan ang susunod na yugto. Ang pagkakasunod-sunod na iyon ay nagpapanatili ng pagsisiyasat sa routing sa loob ng ilang minuto at nag-iiwan ng rekord na masusundan ng iba, na hindi kailanman ginagawa ng nakadikit na talaan.