Ang app na nakatali sa address ng VPN ay gumagamit pa rin ng maling ruta

Nakatali ang isang app sa address ng VPN, at lumalabas pa rin ang koneksyon sa karaniwang default na ruta. Walang nabigo sa bind; ginawa nito nang eksakto ang ginagawa ng bind. Ang pagtali ng socket sa lokal na address ay pumipili ng source address na inilalagay ng kernel sa header. Hindi ito nag-iinstall ng ruta, at hindi ito gumagawa ng tuntunin ng patakaran na magpapadala ng mga packet na may dalang source na iyon sa isang partikular na tunnel.

Ang natitirang bahagi ng runbook na ito ay ang pagkakasunod-sunod ng pagsusuri na ginagamit ko, kasama ang command na nagbibigay ng bawat obserbasyon.

Ano ang talagang itinatakda ng bind

Nagbibigay ang bind ng lokal na address sa socket. Pagkatapos ay gagawin ng kernel ang parehong paghahanap ng ruta na gagawin nito kung hindi man, maliban kung babaguhin ng tuntunin ng patakaran kung aling talahanayan ang binabasa ng paghahanap na iyon.

Kaya maaaring lumabas ang packet na may source address ng VPN sa pisikal na interface. Sa kabilang panig dumarating ito mula sa pribadong saklaw na hindi kailanman inasahan ng network sa rutang iyon, walang ruta pabalik ang return traffic, at nag-hang o nag-reset ang koneksyon.

Dinokumento ng sanggunian sa IP socket ng Linux ang semantika ng bind. Nasa ip-rule at ip-route ang kalahati ng rutahan, at magkahiwalay na manwal ang mga ito dahil may dahilan.

Kumpirmahin na ang address ay kabilang sa namespace na ito

Ang address na maaari mong talian ay dapat umiral sa isang interface sa loob ng namespace ng network kung saan tumatakbo ang app. Ang address ng peer, address ng gateway, o address na umiiral lamang sa ibang namespace ay hindi maaaring talian, at nabibigo ang tawag nang may EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Patakbuhin ang tatlong iyon sa parehong konteksto ng app: parehong namespace, at parehong user kung makukuha mo. Ang lumang diagram ng net30 ay hindi patunay kung aling address ang ibinigay ng kasalukuyang topolohiya mo sa kliyente. Basahin ang interface na talagang aktibo.

Basahin ang paghahanap para sa source at destinasyon na iyon

Isang command ang sumasagot sa tanong na hindi sinagot ng bind:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Ipinapakita ng unang linya ang rutang tatahakin ng packet mula sa source na iyon patungo sa destinasyong iyon, kasama ang palabas na interface at ang gustong source. Kung pinangalanan nito ang pisikal na interface, hindi nagkakasundo ang bind at ang ruta, at lalabas ang packet na may source na hindi kayang balikan ng landas.

Pagkatapos ay sinasabi ng ip rule show kung may tuntunin na pipili ng ibang talahanayan. Mahalaga ang mga priyoridad dito, dahil ang unang tugmang tuntunin ang nananalo, at ang tuntuning humahawak sa lahat sa itaas ng sa iyo ay nagpapawalang-bisa sa tuntunin mo.

Mag-install ng tuntunin ng patakaran kung iyon lamang ang disenyo

Ang rutahang nakabatay sa source ay sinadyang disenyo, hindi pagkukumpuni para sa isang app. Kung gusto ng may-ari ng patakaran na gamitin ng trapiko mula sa subnet ng tunnel ang tunnel, kabilang ang tuntunin sa kanyang configuration at hindi sa isang beses na command sa laptop mo.

Ang gumaganang anyo ay isang nakalaang talahanayan na may default na ruta sa tunnel, kasama ang tuntunin na nagpapadala ng saklaw ng source ng VPN sa talahanayang iyon. Idagdag ang mga eksepsiyon na kailangan ng disenyo, dahil ang talahanayang may default ng tunnel lamang ay mahuhuli rin ang mga destinasyong dapat manatiling lokal o maabot sa pisikal na landas.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Ibalik ito gamit ang ip rule del at ip route flush table 100. Anumang idinagdag sa ganitong paraan ay nawawala sa reboot maliban kung isusulat ito ng manager, na kapwa katangian ng seguridad at dahilan para hindi itago ang nag-iisang kopya sa history ng shell mo.

I-verify gamit ang tatlong obserbasyon

Itala ang source na hiningi ng app, ang rutang pinili ng paghahanap, at ang source na aktwal na nakita ng server.

Maaaring hindi magkasundo ang tatlong ito, at bawat hindi pagkakasundo ay tumuturo sa ibang lugar. Ang paghuli sa interface ng tunnel ay nagpapatunay na lumabas ang packet na may tamang source. Ang paghuli sa pisikal na interface ay nagpapatunay na lumabas ito sa maling landas. Tanging ang pananaw sa panig ng server ang nagpapatunay ng landas mula simula hanggang dulo.

Kung nag-aalok ang app ng opsiyon ng pagtali sa device o mode ng rutahan bawat app, ituring itong ibang mekanismo na may ibang limitasyon. Hindi lahat ng magkatulad na setting ay nauuwi sa parehong desisyon ng kernel.