Aplikacija vezana na VPN adresu i dalje koristi pogrešnu rutu

Aplikacija se veže na VPN adresu, a veza ipak izlazi kroz uobičajenu zadanu rutu. Ništa u vezivanju nije neuspjelo; ono je uradilo tačno ono što vezivanje radi. Vezivanje soketa na lokalnu adresu bira izvornu adresu koju kernel stavlja u zaglavlje. Ono ne instalira rutu i ne stvara pravilo politike koje pakete s tim izvorom šalje u određeni tunel.

Ostatak ovog priručnika je redoslijed provjere koji koristim, zajedno s naredbom koja daje svako opažanje.

Šta vezivanje zapravo odlučuje

Vezivanje dodjeljuje lokalnu adresu soketu. Kernel zatim izvodi istu pretragu rute koju bi izveo i inače, osim ako pravilo politike promijeni koju tabelu ta pretraga čita.

Zato paket može izaći s VPN izvornom adresom na fizičkom interfejsu. Na drugoj strani dolazi iz privatnog opsega koji mreža nikada nije očekivala na tom putu, povratni saobraćaj nema rutu nazad, a veza se blokira ili resetuje.

Linux referenca za IP sokete dokumentuje semantiku vezivanja. Polovina za rutiranje živi u ip-rule i ip-route, i to su odvojeni priručnici s razlogom.

Potvrdite da adresa pripada ovom imenskom prostoru

Adresa na koju se možete vezati mora postojati na interfejsu unutar mrežnog imenskog prostora u kojem aplikacija radi. Adresa partnera, adresa mrežnog prolaza ili adresa koja postoji samo u drugom imenskom prostoru ne može se vezati, a poziv pada s EADDRNOTAVAIL.

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

Pokrenite te tri u istom kontekstu kao aplikaciju: isti imenski prostor i isti korisnik ako ga možete dobiti. Stari net30 dijagram nije dokaz koju je adresu vaša trenutna topologija dodijelila klijentu. Čitajte interfejs koji je zaista podignut.

Pročitajte pretragu za taj izvor i odredište

Jedna naredba odgovara na pitanje na koje vezivanje nije odgovorilo:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Prvi red ispisuje rutu koju bi paket od tog izvora do tog odredišta prešao, uključujući izlazni interfejs i preferirani izvor. Ako imenuje fizički interfejs, vezivanje i ruta se ne slažu, a paket će izaći s izvorom u koji put ne može da se vrati.

ip rule show zatim kaže da li bi neko pravilo odabralo drugu tabelu. Prioriteti su ovdje važni, jer prvo pravilo koje se poklopi pobjeđuje, a pravilo koje hvata sve iznad vašeg čini vaše pravilo nevidljivim.

Instalirajte pravilo politike samo ako je to dizajn

Rutiranje zasnovano na izvoru je namjeran dizajn, a ne popravka za jednu aplikaciju. Ako vlasnik politike želi da saobraćaj iz tunelske podmreže koristi tunel, pravilo pripada u njegovu konfiguraciju, a ne u jednokratnu naredbu na vašem laptopu.

Izvediv oblik je namjenska tabela sa zadanom rutom kroz tunel, plus pravilo koje šalje VPN izvorni opseg u tu tabelu. Dodajte izuzetke koje dizajn zahtijeva, jer tabela samo s tunelskim zadanim unosom uhvatit će odredišta koja treba da ostanu lokalna ili dostupna preko fizičkog puta.

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

Poništite s ip rule del i ip route flush table 100. Sve tako dodano nestaje nakon restarta ako to ne zapiše neki menadžer, što je istovremeno sigurnosno svojstvo i razlog da jedinu kopiju ne držite u historiji svog shella.

Provjerite s tri opažanja

Zabilježite izvor koji je aplikacija tražila, rutu koju je pretraga odabrala i izvor koji je server zaista vidio.

Ta tri mogu se razlikovati, a svaka razlika pokazuje na drugo mjesto. Snimak na tunelskom interfejsu dokazuje da je paket izašao s ispravnim izvorom. Snimak na fizičkom interfejsu dokazuje da je izašao pogrešnim putem. Pogled sa serverske strane jedini dokazuje put od početka do kraja.

Ako aplikacija nudi opciju vezivanja na uređaj ili režim rutiranja po aplikaciji, tretirajte to kao drugi mehanizam s drugim ograničenjima. Slične postavke ne vode sve do iste odluke kernela.