Kuidas saata üks IPv4-sihtkoht väljapoole OpenVPN-tunnelit

Enamik täistunneli seadistusi saadab iga paketi VPN-i kaudu ja redirect-gateway on direktiiv, mis selle võimalikuks teeb. Ühe sihtkoha võib siiski erandiks jätta. Hostimarsruudi lisamine sellele aadressile net_gateway kohahoidjaga ütleb kliendile, et see jõuaks kohale masina algse lüüsi kaudu, samal ajal kui kõik muu jätkab tunneli kasutamist.

Rida tundub kahjutu ja on seda sageli, kuid see lahendab ainult ühe küsimuse: kuhu lähevad paketid täpselt sellele IPv4-aadressile. See ei muuda DNS-i, IPv6-t, tulemüüri poliitikat ega seda, milline protsess ühenduse avas, ja igaüks neist võib erandi vaikselt nurjata.

Mida net_gateway tegelikult nimetab

Selle erandi profiilikirje on üks rida: route 198.51.100.77 255.255.255.255 net_gateway. Esimene aadress on sihtkoha dokumentatsiooni kohahoidja, mask teeb sellest üksiku hosti marsruudi ja viimane märk nimetab lüüsi kohahoidja. OpenVPN lahendab lüüsi kohahoidjad marsruute paigaldades. vpn_gateway tähendab tunneli enda lüüsi, VPN-lingi kaugemat poolt. net_gateway tähendab vaikelüüsi, mis hostil oli enne, kui VPN midagi muutis, mis tavaliselt on füüsilise võrgu kohalik ruuter.

Kolmas kohahoidja, remote_host, viitab VPN-serveri aadressile ja see on olemas selleks, et tunnel saaks serverini jõuda füüsilist teed pidi. Nende kolme segamini ajamine on kõige tavalisem põhjus, miks erand satub valesse kohta või ei paigaldata üldse.

Väärtust loetakse ühenduse ajal, seda ei kirjutata faili. Kui masin liigub teise võrku, muutub enne VPN-i olnud lüüs ja marsruut järgib uut. Tavaliselt on see see, mida soovite, kuid see tähendab ka, et erandi käitumine sõltub võrgust, millest klient alustas.

Miks hostimarsruut võidab tunneli vaikemarsruudi

Marsruutimise otsustab kõige spetsiifilisem sobiv prefiks. redirect-gateway def1 tavaliselt ei asenda vaikemarsruuti; see lisab kaks poolt, marsruudi aadressiruumi alumisele poolele ja ühe ülemisele poolele, nii et algne vaikemarsruut säilib muuks kasutuseks. Need pooled on laiemad kui üks aadress.

Ühe aadressi marsruut maskiga 255.255.255.255 on /32, mis on nii spetsiifiline, kui IPv4 üldse olla saab. Kui sellele aadressile mõeldud paketti hinnatakse, sobib /32 ja võidab sõltumata sellest, milline marsruut paigaldati esimesena. See on erandi taga olev mehhanism ja see töötab samamoodi Linuxis, macOS-is ja Windowsis seni, kuni marsruut tegelikult olemas on.

Windows lisab teise mõõtme. Kui kaks marsruuti on võrdselt spetsiifilised, võidab väiksema meetrikaga, ja VPN-adapter võib kanda liidese meetrikat, mis tulemuse muudab. /32 on endiselt spetsiifilisem kui pooled, seega erand tavaliselt kehtib, kuid varasemast sessioonist jäänud vana marsruut võib anda segase tulemuse, kui see on võrdselt spetsiifiline.

Mida erand ei kata

DNS on esimene lünk. Klient võib lükata siseresolveri seadeid ja operatsioonisüsteem jätkab nende kasutamist päringuteks. Rakendus, mis lahendab nime enne ühendamist, võib saada sisemise aadressi teenusele, mis peaks minema otse, või välise aadressi, mis lahendub õigesti, kuid komistab siis järgmise lünga otsa.

IPv6 on teine. Marsruudidirektiiv käsitleb ainult IPv4-te. Kahe virna sihtkoht võib eelistada IPv6-t, mis järgib poliitikast sõltuvalt kas tunnelit või hosti IPv6 vaikemarsruuti, nii et IPv4 erand ei rakendu kunagi. Teil on vaja sobivat IPv6 marsruuti või teadlikku otsust selle kliendi jaoks IPv6 välja lülitada.

Rakenduse ulatus on kolmas. Reegel põhineb sihtkohal, seega kasutab iga protsess, mis selle aadressiga ühendub, otsest teed, olgu see siis see, mida silmas pidasite, või mitte. Vastupidi, veebisait võib vastata mitmelt aadressilt, seega ühe /32 erandiks jätmine ei jäta saiti erandiks. Kui tegelik nõue on rakendusepõhine marsruutimine, siis Community kliendi marsruuditabel on vale tööriist.

Erandi kontrollimine ilma end petmata

Alustage paigaldatud marsruudist, mitte brauserist. Linuxis küsige kernellilt, millist marsruuti ja järgmist hüpet see konkreetse aadressi jaoks kasutab; Windowsis lugege selle /32 marsruuditabelit. Kinnitage, et lüüs on füüsiline, mitte tunnel. Kui kirje puudub, ei rakendatud profiili või ei olnud kliendil õigust marsruute muuta.

Seejärel katsetage kahte sihtkohta. Päring erandiks jäetud aadressile peaks lahkuma füüsilise liidese kaudu ja päring kontroll-sisemisele aadressile peaks endiselt tunnelit kasutama. Ainult erandiks jäetud aadressi katsetamine ei tõesta midagi ülejäänud tunneli kohta ja avaliku veebisaidi katsetamine testib aadressi, millele see sait lahendus, mis ei pruugi olla reeglis olev aadress.

Lõpuks kontrollige juhtelemente, mis võivad marsruudi üle kirjutada. Kliendipoolne kill switch või Windowsi säte block-outside-dns võib keelata otsese liikluse, mis väljendub ühendusena, mis ebaõnnestub, kuigi marsruut on õige. Ärge lülitage neid juhtelemente välja, et erand näiks toimivat; kui poliitika keelab otsese tee, on erand disainiprobleem sellele, kes VPN-teenust omab.

Kontrollige uuesti pärast taasühendamist või võrguvahetust, sest enne VPN-i olnud lüüs ja saadaolev tee on hetke, mitte profiili omadused.