Paano makilala ang mga rutang itinutulak ng VPN mula sa mga static sa Linux

May prefix na lumilitaw sa laptop kapag bumangon ang tunnel, kaya parang ang VPN ang nag-install nito. Maaaring gayon nga, ngunit ang parehong resulta ay maaaring magmula sa client script na tumatakbo kapag kumokonekta, sa profile ng koneksyon na naglilista ng subnet, o sa static na ruta na naroon mula pa noon at nagsimulang gumana lamang nang umiral ang interface. Ang maling may-ari ay nangangahulugang bumabalik ang ruta pagkatapos ng bawat paglilinis, at inuulit ng susunod na tao ang parehong pagwawasto. Hinihiwalay ng sumusunod na pagkakasunod-sunod ang tatlo bago baguhin ang anuman.

Hakbang 1: pangalanan ang mekanismong nag-iinstall ng mga prefix

Iba't ibang protocol ang nagbibigay ng maabot sa iba't ibang paraan, at ang tawagin ang lahat ng ito na anunsyo ay nagtatago ng pagkakaiba. Ang OpenVPN server ay nagtutulak ng direktiba ng ruta sa control channel at ini-install ito ng client maliban kung haharangin ito ng pull filter. Ang WireGuard configuration ay naglilista ng mga pinapayagang prefix nang lokal, na ginagamit ng client para sa crypto-key routing at sa mga rutang idinadagdag nito. Ang IPsec tunnel ay sumasang-ayon sa mga traffic selector sa peer, at ang kernel ay nag-iinstall ng mga ruta mula sa mga selector na iyon.

Tukuyin kung alin sa mga ito ang ginagamit ng iyong tunnel bago magbasa ng anumang talahanayan. Ang rutang itinutulak sa oras ng koneksyon ay hindi anunsyo ng isang routing protocol at hindi nangangako na maabot ang prefix sa likod ng malayong dulo. Itala ang mekanismo sa tabi ng prefix, dahil ito ang nagtatakda kung saan nararapat ang pagwawasto.

Hakbang 2: ihambing ang talahanayan sa isang koneksyon

I-save ang pangunahing talahanayan habang nakababa ang tunnel, itaas ito, i-save muli, at ihambing ang dalawang kuha. Ang anumang lumitaw ay kabilang sa lifecycle ng koneksyon, at ang anumang natira ay kabilang sa lokal na configuration.

Kunin ito gamit ang ip route show table main > /tmp/route-down.txt, kumonekta, at kumuha muli. Gawin din ito para sa ip -6 route kung gumagamit ng IPv6 ang site, dahil ang nawawalang prefix doon ay lumilikha ng mga pagpalya na parang walang kaugnayan sa routing.

Hakbang 3: basahin ang metric, hindi lamang ang presensya

Dalawang entry para sa parehong prefix ay maaaring magkasabay, at pinipili ng kernel ang mas mababang metric. Ang static na ruta na may metric 50 ay patuloy na mananalo laban sa rutang itinulak sa 100 kahit nakikita ang dalawa, kaya ang 'may ruta doon' at 'ginagamit ito ng traffic' ay magkaibang pahayag.

Tanungin ang kernel nang direkta gamit ang ip route get 10.20.5.7 at basahin ang interface na iniuulat nito. Kung lumalabas ang traffic sa pisikal na adapter habang nasa talahanayan ang ruta ng tunnel, ang metric o haba ng prefix ang nagpapaliwanag nito, hindi ang VPN client. Ulitin ang paghahanap para sa host na alam mong nasa likod ng tunnel at sa isang alam mong wala, at ang pagkakaiba ay magpapakita kung gumagana ang paghahati ayon sa layunin.

Hakbang 4: hanapin ang mga entry na mas matagal kaysa sa tunnel

Ang mga static na ruta ay nakakalampas sa paghihiwalay ayon sa disenyo, at doon nagmumula ang mga lumang entry. Ang permanenteng ruta na tumuturo sa interface na wala nang umiiral ay maaaring tahimik na lumamon ng subnet, at ang tumuturo sa muling ginamit na pangalan ng interface ay maaaring magpadala ng pribadong traffic sa maling pinto pagkatapos ng reboot.

Suriin ang permanenteng bahagi sa lugar na ginagamit ng iyong distribution, maging unit ng systemd-networkd, profile ng NetworkManager, o script sa up directory ng client. Ang pagwawasto sa live na talahanayan gamit ang ip route del ay tumatagal lamang hanggang sa susunod na koneksyon. Ituring ang pagbura na iyon bilang pagsubok ng hypothesis at hindi bilang pag-aayos.

Kung mali ang coverage na ibinibigay ng malayong dulo, iharap ito sa operator sa halip na i-filter ang lahat. Ang pagtatapon ng lahat ng itinutulak na setting ay nagtatapon din ng DNS at patakaran ng split tunnel na pinagkakatiwalaan ng profile.

Hakbang 5: kumpirmahin ang pabalik na landas bago sisihin ang client

Para sa site-to-site o subnet sa likod ng tunnel, kailangan ng malayong panig ng rutang pabalik sa address ng iyong client at nakabukas na forwarding sa gateway. Ang isang-direksyong landas ay mukhang eksaktong bug sa routing ng client, maliban na parehong nagtagumpay ang handshake at ang papalabas na packet.

Ang reverse-path filtering ay nagdadagdag ng pangalawang bitag sa mga Linux gateway. Ang sagot na dumarating sa ibang interface kaysa sa hinuhulaan ng ruta ay itinatapon sa strict mode, at ang asymmetric na landas sa dalawang provider ay mapagkakatiwalaang nagpapataas nito. Ang mga drop counter sa gateway, hindi sa client, ang magsasabi kung ang filtering ang dahilan.

Hakbang 6: subukan ang resource, hindi ang ping

Kapag tama na ang piniling ruta, buksan ang aktwal na resource at kumpirmahin ang pabalik na traffic. Ang sagot ng ping ay nagpapatunay ng landas sa isang direksyon at wala tungkol sa serbisyo, at ang serbisyong sumasagot sa cached na koneksyon ay mas kaunti pa ang napatutunayan.

Pagkatapos ay ulitin ang buong pagsusuri pagkatapos ng muling pagkonekta. Ang halaga ng pagkakasunod-sunod ay hinuhulaan nito kung ano ang gagawin ng susunod na koneksyon, kaya pareho ang paghahambing at ang metric ay kabilang sa ticket.