Aplikacija, vezana na naslov VPN, še vedno uporablja napačno pot

Aplikacija se veže na naslov VPN, povezava pa vseeno odide po običajni privzeti poti. Pri vezavi ni nič spodletelo; naredila je natanko to, kar počne vezava. Vezava vtičnice na lokalni naslov izbere naslov vira, ki ga jedro vpiše v glavo. Ne namesti poti in ne ustvari pravila politike, ki bi pakete s tem virom pošiljalo v določen tunel.

Preostanek tega priročnika je vrstni red preverjanj, ki ga uporabljam, skupaj z ukazom, ki da vsako opažanje.

Kaj vezava v resnici odloči

Vezava dodeli vtičnici lokalni naslov. Nato jedro izvede isto iskanje poti, kot bi ga sicer, razen če pravilo politike spremeni, katero tabelo to iskanje bere.

Zato lahko paket odide z izvornim naslovom VPN na fizičnem vmesniku. Na drugi strani prispe iz zasebnega obsega, ki ga omrežje na tej poti nikoli ni pričakovalo, povratni promet nima poti nazaj in povezava se ustavi ali ponastavi.

Referenca za vtičnice IP v Linuxu dokumentira semantiko vezave. Polovica o usmerjanju živi v ip-rule in ip-route, in to sta ločena priročnika z razlogom.

Potrdite, da naslov pripada temu imenskemu prostoru

Naslov, na katerega se lahko vežete, mora obstajati na vmesniku znotraj omrežnega imenskega prostora, v katerem teče aplikacija. Naslova drugega konca, naslova prehoda ali naslova, ki obstaja samo v drugem imenskem prostoru, ni mogoče vezati, klic pa spodleti z EADDRNOTAVAIL.

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

Zaženite te tri v istem kontekstu kot aplikacijo: isti imenski prostor in, če ga dobite, isti uporabnik. Stara shema net30 ni dokaz, kateri naslov je vaša sedanja topologija dodelila odjemalcu. Berite vmesnik, ki je resnično aktiven.

Preberite iskanje za ta vir in cilj

En ukaz odgovori na vprašanje, na katero vezava ni odgovorila:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Prva vrstica izpiše pot, po kateri bi paket od tega vira do tega cilja šel, vključno z odhodnim vmesnikom in prednostnim virom. Če navede fizični vmesnik, se vezava in pot razhajata, paket pa bo odšel z virom, v katerega se pot ne more vrniti.

Nato ip rule show pove, ali bi katero pravilo izbralo drugo tabelo. Prioritete so tu pomembne, ker zmaga prvo ujemajoče pravilo, pravilo, ki ujame vse nad vašim, pa naredi vaše pravilo nevidno.

Namestite pravilo politike le, če je to zasnova

Usmerjanje na podlagi vira je namerna zasnova, ne popravilo za eno aplikacijo. Če lastnik politike želi, da promet iz podomrežja tunela uporablja tunel, pravilo spada v njegovo konfiguracijo in ne v enkratni ukaz na vašem prenosniku.

Delujoča oblika je ločena tabela s privzeto potjo skozi tunel in pravilom, ki pošlje obseg vira VPN v to tabelo. Dodajte izjeme, ki jih zasnova potrebuje, ker bo tabela samo s privzeto potjo tunela zajela tudi cilje, ki morajo ostati lokalni ali dosegljivi po fizični poti.

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

Razveljavite z ip rule del in ip route flush table 100. Vse tako dodano izgine ob ponovnem zagonu, razen če to zapiše upravitelj, kar je hkrati varnostna lastnost in razlog, da edine kopije ne hranite v zgodovini lupine.

Preverite s tremi opažanji

Zapišite vir, ki ga je zahtevala aplikacija, pot, ki jo je izbralo iskanje, in vir, ki ga je strežnik dejansko videl.

Ti trije se lahko razhajajo in vsako razhajanje kaže drugam. Zajem na vmesniku tunela dokazuje, da je paket odšel s pravim virom. Zajem na fizičnem vmesniku dokazuje, da je odšel po napačni poti. Samo pogled s strani strežnika dokazuje pot od začetka do konca.

Če aplikacija ponuja možnost vezave na napravo ali način usmerjanja za posamezno aplikacijo, to obravnavajte kot drug mehanizem z drugimi omejitvami. Podobno vidne nastavitve ne vodijo vse do iste odločitve jedra.