VPN-i aadressiga seotud rakendus kasutab siiski vale marsruuti

Rakendus seotakse VPN-i aadressiga ja ühendus väljub siiski tavalise vaikemarsruudi kaudu. Sidumises ei ebaõnnestunud miski; see tegi täpselt seda, mida sidumine teeb. Socketi sidumine kohaliku aadressiga valib lähteaadressi, mille kernel päisesse paneb. See ei paigalda marsruuti ega loo poliitikareeglit, mis saadaks selle allikaga paketid kindlasse tunnelisse.

Ülejäänud osa sellest juhendist on kontrollijärjekord, mida ma kasutan, koos käsuga, mis annab iga vaatluse.

Mida sidumine tegelikult otsustab

Sidumine määrab socketile kohaliku aadressi. Seejärel teeb kernel sama marsruudiotsingu, mille ta oleks muidu teinud, kui poliitikareegel ei muuda, millist tabelit see otsing loeb.

Seetõttu võib pakett väljuda VPN-i lähteaadressiga füüsilisel liidesel. Teisel pool saabub see privaatsest vahemikust, mida võrk sellel teel kunagi ei oodanud, tagasitulev liiklusel pole tagasiteed ja ühendus jääb rippuma või lähtestatakse.

Linuxi IP-socketite viide dokumenteerib sidumise semantikat. Marsruutimise pool elab failides ip-rule ja ip-route ning need on põhjusega eraldi käsilehed.

Kinnitage, et aadress kuulub sellesse nimeruumi

Aadress, millega saab siduda, peab eksisteerima liidesel võrgu nimeruumis, kus rakendus töötab. Partneri aadress, lüüsi aadress või aadress, mis eksisteerib ainult teises nimeruumis, ei ole sidutav ja kutse ebaõnnestub veaga EADDRNOTAVAIL.

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

Käivitage need kolm rakendusega samas kontekstis: sama nimeruum ja sama kasutaja, kui selle saate. Vana net30 diagramm ei tõesta, millise aadressi teie praegune topoloogia kliendile määras. Lugege liidest, mis on tegelikult üleval.

Lugege selle allika ja sihtkoha otsingut

Üks käsk vastab küsimusele, millele sidumine ei vastanud:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Esimene rida trükib marsruudi, mille pakett sellest allikast sellesse sihtkohta läbiks, sealhulgas väljuva liidese ja eelistatud allika. Kui see nimetab füüsilist liidest, on sidumine ja marsruut vastuolus ning pakett väljub allikaga, kuhu tee ei saa tagasi pöörduda.

Seejärel ütleb ip rule show, kas mõni reegel oleks valinud teise tabeli. Prioriteedid on siin olulised, sest võidab esimene sobiv reegel ja kõike püüdev reegel teie reegli kohal teeb teie reegli nähtamatuks.

Paigaldage poliitikareegel ainult siis, kui see on disain

Allikapõhine marsruutimine on teadlik disain, mitte ühe rakenduse parandus. Kui poliitika omanik tahab, et tunnelialavõrgu liiklus kasutaks tunnelit, kuulub reegel tema konfiguratsiooni, mitte ühekordsesse käsku teie sülearvutis.

Toimiv vorm on eraldi tabel vaikemarsruudiga läbi tunneli, pluss reegel, mis saadab VPN-i allikavahemiku sellesse tabelisse. Lisage erandid, mida disain vajab, sest ainult tunneli vaikemarsruuti sisaldav tabel püüab sihtkohad, mis peaksid jääma kohalikuks või olema ligipääsetavad füüsilisel teel.

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

Võtke tagasi käskudega ip rule del ja ip route flush table 100. Kõik nii lisatu kaob taaskäivitamisel, kui haldur seda ei kirjuta, mis on ühtaegu turvaomadus ja põhjus mitte hoida ainsat koopiat oma shelli ajaloos.

Kontrollige kolme vaatlusega

Kirjutage üles allikas, mida rakendus küsis, marsruut, mille otsing valis, ja allikas, mida server tegelikult nägi.

Need kolm võivad erineda ja iga erinevus osutab eri kohta. Püük tunneli liidesel tõestab, et pakett väljus õige allikaga. Püük füüsilisel liidesel tõestab, et see väljus vale teed. Serveripoolne vaade on ainus, mis tõestab tee otsast otsani.

Kui rakendus pakub seadmele sidumise valikut või rakendusepõhist marsruutimisrežiimi, käsitlege seda teise mehhanismina, millel on teised piirangud. Sarnased seaded ei vii kõik sama kerneli otsuseni.