Kuinka lähettää yksi IPv4-kohde OpenVPN-tunnelin ulkopuolelle

Useimmat täystunnelin asetukset lähettävät jokaisen paketin VPN:n kautta, ja redirect-gateway on direktiivi, joka tekee sen mahdolliseksi. Yksi kohde voidaan silti jättää pois. Isäntäreitin lisääminen kyseiselle osoitteelle net_gateway-paikkamerkin kanssa kertoo asiakasohjelmalle, että se saavuttaa osoitteen koneen alkuperäisen yhdyskäytävän kautta, kun taas kaikki muu käyttää edelleen tunnelia.

Rivi näyttää harmittomalta ja usein onkin, mutta se ratkaisee vain yhden kysymyksen: minne juuri tuon IPv4-osoitteen paketit menevät. Se ei muuta DNS:ää, IPv6:tta, palomuurikäytäntöä eikä sitä, mikä prosessi avasi yhteyden, ja mikä tahansa näistä voi hiljaa kumota poikkeuksen.

Mitä net_gateway oikeastaan nimeää

Kyseisen poikkeuksen profiilimerkintä on yksi rivi: route 198.51.100.77 255.255.255.255 net_gateway. Ensimmäinen osoite on dokumentaatiopaikkamerkki kohteelle, peite tekee siitä yhden isännän reitin ja viimeinen token nimeää yhdyskäytävän paikkamerkin. OpenVPN ratkaisee yhdyskäytävän paikkamerkit asentaessaan reittejä. vpn_gateway tarkoittaa tunnelin omaa yhdyskäytävää, VPN-linkin kaukaista puolta. net_gateway tarkoittaa oletusyhdyskäytävää, joka isännällä oli ennen kuin VPN muutti mitään, yleensä fyysisen verkon paikallista reititintä.

Kolmas paikkamerkki, remote_host, viittaa VPN-palvelimen osoitteeseen, ja se on olemassa, jotta tunneli voi tavoittaa palvelimen fyysistä polkua pitkin. Näiden kolmen sekoittaminen on yleisin syy siihen, että poikkeus päätyy väärään paikkaan tai jää kokonaan asentamatta.

Arvo luetaan yhteyden muodostamisen hetkellä, sitä ei kirjoiteta tiedostoon. Jos kone siirtyy toiseen verkkoon, VPN:ää edeltävä yhdyskäytävä vaihtuu ja reitti seuraa uutta. Se on yleensä se, mitä haluat, mutta se tarkoittaa myös, että poikkeuksen käyttäytyminen riippuu verkosta, josta asiakasohjelma aloitti.

Miksi isäntäreitti voittaa tunnelin oletusreitin

Reitityksen ratkaisee tarkin vastaava etuliite. redirect-gateway def1 ei yleensä korvaa oletusreittiä; se lisää kaksi puoliskoa, reitin osoiteavaruuden alapuoliskolle ja toisen yläpuoliskolle, joten alkuperäinen oletusreitti säilyy muuhun käyttöön. Nuo puoliskot ovat leveämpiä kuin yksi osoite.

Yhden osoitteen reitti peitteellä 255.255.255.255 on /32, mikä on niin tarkka kuin IPv4 voi olla. Kun kyseiselle osoitteelle tarkoitettua pakettia arvioidaan, /32 täsmää ja voittaa riippumatta siitä, mikä reitti asennettiin ensin. Se on poikkeuksen takana oleva mekanismi, ja se toimii samoin Linuxissa, macOS:ssä ja Windowsissa, kunhan reitti todella on olemassa.

Windows lisää toisen ulottuvuuden. Kun kaksi reittiä on yhtä tarkkoja, pienemmän metrisen arvon omaava voittaa, ja VPN-sovitin voi kantaa liitännän metriikkaa, joka muuttaa tuloksen. /32 on edelleen tarkempi kuin puoliskot, joten poikkeus yleensä pitää, mutta aiemmasta istunnosta jäänyt vanhentunut reitti voi tuottaa hämmentävän tuloksen, jos se on yhtä tarkka.

Mitä poikkeus ei kata

DNS on ensimmäinen aukko. Asiakasohjelma voi työntää sisäisiä resolver-asetuksia, ja käyttöjärjestelmä käyttää niitä edelleen kyselyihin. Sovellus, joka ratkaisee nimen ennen yhdistämistä, voi saada sisäisen osoitteen palvelulle, jonka pitäisi mennä suoraan, tai ulkoisen osoitteen, joka ratkeaa oikein mutta kompastuu sitten seuraavaan aukkoon.

IPv6 on toinen. Reittidirektiivi käsittelee vain IPv4:tä. Kaksoispino-kohde voi suosia IPv6:tta, joka seuraa tunnelia tai isännän IPv6-oletusreittiä käytännöstä riippuen, joten IPv4-poikkeus ei koskaan tule voimaan. Tarvitset vastaavan IPv6-reitin tai tietoisen päätöksen poistaa IPv6 käytöstä kyseiseltä asiakasohjelmalta.

Sovelluslaajuus on kolmas. Sääntö perustuu kohteeseen, joten jokainen prosessi, joka yhdistää kyseiseen osoitteeseen, käyttää suoraa polkua, olipa se ajattelemasi tai ei. Toisaalta verkkosivusto voi vastata useasta osoitteesta, joten yhden /32:n poikkeus ei poikkea sivustoa. Jos todellinen vaatimus on sovelluskohtainen reititys, Community-asiakasohjelman reittitaulu on väärä työkalu.

Poikkeuksen tarkistaminen itseään huijaamatta

Aloita asennetusta reitistä, älä selaimesta. Kysy Linuxissa ytimeltä, mitä reittiä ja seuraavaa hyppyä se käyttää kyseiselle osoitteelle; lue Windowsissa kyseisen /32:n reittitaulu. Varmista, että yhdyskäytävä on fyysinen eikä tunneli. Jos merkintä puuttuu, profiilia ei otettu käyttöön tai asiakasohjelmalla ei ollut oikeutta muuttaa reittejä.

Testaa sitten kahta kohdetta. Pyynnön poikkeuksen kohteena olevaan osoitteeseen pitäisi lähteä fyysisen liitännän kautta, ja pyynnön sisäiseen kontrolliosoitteeseen pitäisi edelleen käyttää tunnelia. Vain poikkeuksen kohteena olevan osoitteen testaaminen ei todista mitään tunnelin muusta osasta, ja julkisen verkkosivuston testaaminen testaa osoitetta, johon kyseinen sivusto ratkesi, joka ei välttämättä ole säännön osoite.

Tarkista lopuksi säätimet, jotka voivat ohittaa reitin. Asiakaspuolen kill switch tai Windowsin block-outside-dns-asetus voi kieltää suoran liikenteen, mikä näkyy yhteytenä, joka epäonnistuu vaikka reitti on oikein. Älä poista näitä säätimiä käytöstä saadaksesi poikkeuksen näyttämään toimivalta; jos käytäntö kieltää suoran polun, poikkeus on suunnitteluongelma VPN-palvelun omistajalle.

Tarkista uudelleen yhteyden palauttamisen tai verkon vaihdon jälkeen, koska VPN:ää edeltävä yhdyskäytävä ja käytettävissä oleva polku ovat hetken ominaisuuksia, eivät profiilin.