Aplikacija vezana za VPN adresu ipak koristi pogrešan put

Aplikacija se vezuje za adresu VPN-a, a veza ipak izlazi kroz uobičajenu zadanu rutu. Ništa u vezivanju nije omanulo; ono je uradilo tačno ono što vezivanje radi. Vezivanje soketa za lokalnu adresu bira izvornu adresu koju jezgro upisuje u zaglavlje. Ono ne postavlja rutu i ne pravi pravilo politike koje bi pakete sa tim izvorom slalo u određeni tunel.

Ostatak ovog priručnika je redosled provere koji koristim, zajedno sa komandom koja daje svako zapažanje.

Šta vezivanje zapravo odlučuje

Vezivanje dodeljuje soketu lokalnu adresu. Zatim jezgro obavlja istu pretragu rute koju bi obavilo i inače, osim ako pravilo politike ne promeni koju tabelu ta pretraga čita.

Zato paket može izaći sa 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. Deo 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 možete da se vezujete mora postojati na interfejsu unutar mrežnog imenskog prostora u kome aplikacija radi. Adresa sagovornika, adresa mrežnog prolaza ili adresa koja postoji samo u drugom imenskom prostoru ne može da se veže, a poziv pada sa 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 dodelila klijentu. Čitajte interfejs koji je zaista podignut.

Pročitajte pretragu za taj izvor i odredište

Jedna komanda 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 kojom bi paket od tog izvora do tog odredišta prošao, uključujući izlazni interfejs i željeni izvor. Ako navede fizički interfejs, vezivanje i ruta se razilaze, i paket će izaći sa izvorom u koji put ne može da se vrati.

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

Postavite pravilo politike samo ako je to dizajn

Rutiranje zasnovano na izvoru je namerni dizajn, a ne popravka za jednu aplikaciju. Ako vlasnik politike želi da saobraćaj iz podmreže tunela koristi tunel, pravilo pripada njegovoj konfiguraciji, a ne jednokratnoj komandi na vašem prenosnom računaru.

Izvodljiv oblik je posebna tabela sa zadanom rutom kroz tunel, plus pravilo koje šalje VPN izvorni opseg u tu tabelu. Dodajte izuzetke koje dizajn zahteva, jer tabela samo sa tunelskim zadatim unosom uhvatić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 sa ip rule del i ip route flush table 100. Sve tako dodato nestaje nakon restarta ako to ne zapiše neki menadžer, što je istovremeno sigurnosna osobina i razlog da jedinu kopiju ne držite u istoriji svog šela.

Proverite sa tri zapažanja

Zabeležite izvor koji je aplikacija tražila, rutu koju je pretraga izabrala i izvor koji je server zaista video.

Ta tri mogu da se razlikuju, a svaka razlika pokazuje na drugo mesto. Snimak na tunelskom interfejsu dokazuje da je paket izašao sa 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 za uređaj ili režim rutiranja po aplikaciji, tretirajte to kao drugi mehanizam sa drugim ograničenjima. Slične postavke ne vode sve do iste odluke jezgra.