Teie vana vaikimisi marsruut jääb OpenVPN-i järel meelega alles

Ühendate tunneliga, käivitate ip route ja algne vaikimisi lüüs on endiselt seal. Järgmine mõte on see, et klient ei võtnud marsruuti üle, nii et kustutate vaikimisi marsruudi käsitsi ja kaotate ühenduse täielikult. See kirje peab jääma. Valikuga redirect-gateway def1 paigaldab OpenVPN kaks täpsemat marsruuti, mis ületavad tavalise vaikimisi marsruudi, selle asemel et see asendada. Vana lüüs jääb alles ja lakkab kandmast liiklust, mida te katsetasite.

Mida def1 tegelikult teeb

Lipp lisab 0.0.0.0/1 ja 128.0.0.0/1, mõlemad tunnelile osutavad. 0.0.0.0/1 haarab iga aadressi, mille esimene oktett on 0 kuni 127, ja 128.0.0.0/1 haarab 128 kuni 255, nii et igal IPv4 sihtkohal on täpsem vastavus kui vanal vaikimisi marsruudil. Marsruudi võidu otsustab prefiksi pikkus, mitte metriika.

Algse vaikimisi marsruudi paigale jätmine on meelega. Klient ei pea meeles pidama, mida ta asendas, ega kirjuta üle marsruuti, mis kannab tema enda ühendust VPN-serveriga. Katkestamisel eemaldab see kaks poolmarsruuti ja tabel taastub endiseks.

Miks /1, mitte /0

Marsruutimine valib pikima sobiva prefiksi, mitte madalaima metriika, seega /1 võidab /0 sõltumata sellest, mida vaikimisi marsruudi metriika ütleb. Mõlemad pooled on olemas, sest üks /1 katab ainult poole ruumist; kui olemas on ainult 0.0.0.0/1, järgib kõik alates 128.0.0.0 vana vaikimisi marsruuti, mis tekitab segadust tekitava sümptomi, kus mõned saidid töötavad ja teised mitte.

Vana vaikimisi marsruudi metriika tõstmine või langetamine ei muuda midagi ja ka madalama metriikaga vaikimisi marsruut teisel liidesel ei varasta liiklust. Esmalt otsustab prefiksi pikkus ja metriika poole pöördutakse ainult võrdsete prefiksite puhul.

Lugege tegelikku marsruutimistabelit

Ühendatud host saab näidata kõiki kolme kirjet korraga, kusjuures tunnel kannab pooled ja algne lüüs on endiselt loendis. Aadressid on näited, mitte kopeeritav konfiguratsioon, sest liidese nimed, tunneli topoloogia ja lisamarsruudid erinevad platvormi ja kliendi kaupa.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Tähtis on suhe: kaks konkreetset poolt ühe üldise vaikimisi marsruudi kohal. Vana lüüsi rida jääb alles, sest miski ei asendanud seda.

Kontrollige, millise marsruudi pakett tegelikult valib

Täpsemad marsruudid võivad siiski võita: marsruut privaatsele vahemikule, kohalikule alavõrgule või VPN-serveri enda aadress on pikem kui /1. Tunnel vajab väljapoole suunduvat teed oma serverini ja selle ühenduse tagasi tunnelisse saatmine lõhuks selle kohe. Linuxis küsige tuumalt, selle asemel et tabelit silmaga lugeda: ip route get huvipakkuva sihtkohaga trükib valitud marsruudi, liidese ja allika. Kui poliitikapõhine marsruutimine on seadistatud, kontrollige ka reegleid, sest reegel võib valida teise tabeli enne, kui peaktabelit vaadatakse.

Kui ainult osa IPv4-st käitub valesti, kinnitage, et mõlemad pooled on paigaldatud, ja otsige seejärel erandit, mis vastab ebaõnnestuvale sihtkohale. Vana vaikimisi marsruudi kustutamine ei ole lahendus ja see eemaldab marsruudi, mida klient vajab tunneli puhtaks lammutamiseks.

Mida def1 ei kata

Kaks IPv4 kirjet ei ütle midagi IPv6 kohta: IPv6 ühendusega host jätkab oma vaikimisi marsruudi kasutamist, kuni miski selle perekonna eraldi ümber suunab, mistõttu kahekihilises võrgus näib osa liiklust tunnelist mööda minevat. Teised kliendid ja võrguhaldurid rakendavad täistunneli marsruutimist erinevalt ja nende tabelid ei ühti. Siin kirjeldatud def1 käitumine kuulub OpenVPN-i dokumenteeritud lipu juurde, mitte igale masinas olevale VPN-ile.

Kill switch vastab teisele küsimusele: mida masin teeb, kui tunnel langeb. Marsruutide prioriteet otsustab, kuhu liiklus läheb, kuni tunnel on üleval; see ei otsusta, mida tulemüür pärast teeb. Töö järjekord: lugege tabelit, kinnitage, et mõlemad pooled on olemas, käivitage ip route get ebaõnnestuva sihtkoha jaoks, kontrollige poliitikareegleid ja vaadake seejärel IPv6-t eraldi. Jätke vana vaikimisi marsruut sinna, kus see on.