Vanha oletusreittisi selviää tarkoituksella OpenVPN:stä

Yhdistät tunnelin, suoritat ip route -komennon, ja alkuperäinen oletusyhdyskäytävä on yhä paikallaan. Seuraava ajatus on, että asiakasohjelma ei ottanut reittiä haltuunsa, joten poistat oletusreitin käsin ja menetät yhteyden kokonaan. Sen merkinnän on tarkoitus jäädä. Valitsimella redirect-gateway def1 OpenVPN asentaa kaksi tarkempaa reittiä, jotka ohittavat tavallisen oletusreitin sen korvaamisen sijaan. Vanha yhdyskäytävä jää ja lakkaa kuljettamasta liikennettä, jota testasit.

Mitä def1 oikeastaan tekee

Valitsin lisää 0.0.0.0/1- ja 128.0.0.0/1-reitit, molemmat tunneliin osoittaen. 0.0.0.0/1 kattaa jokaisen osoitteen, jonka ensimmäinen oktetti on 0–127, ja 128.0.0.0/1 kattaa 128–255, joten jokaisella IPv4-kohteella on tarkempi osuma kuin vanhalla oletusreitillä. Etuliitteen pituus, ei metriikka, ratkaisee, kumpi reitti voittaa.

Alkuperäisen oletusreitin paikalleen jättäminen on tahallista. Asiakasohjelman ei tarvitse muistaa, mitä se korvasi, eikä se kirjoita uudelleen reittiä, joka kuljettaa sen oman yhteyden VPN-palvelimeen. Katkaisussa se poistaa kaksi puolikasta reittiä ja taulukko palaa siihen, mitä se oli.

Miksi /1 eikä /0

Reititys valitsee pisimmän sopivan etuliitteen, ei alinta metriikkaa, joten /1 voittaa /0:n riippumatta siitä, mitä oletusreitin metriikka sanoo. Molemmat puolikkaat ovat olemassa, koska yksi /1 kattaa vain puolet avaruudesta; kun vain 0.0.0.0/1 on läsnä, kaikki 128.0.0.0:sta ylöspäin seuraa yhä vanhaa oletusreittiä, mikä tuottaa hämmentävän oireen: jotkin sivustot toimivat ja toiset eivät.

Vanhan oletusreitin metriikan nostaminen tai laskeminen ei muuta mitään, eikä toisen liitännän alemman metriikan oletusreitti varasta liikennettä. Ensin ratkaisee etuliitteen pituus, ja vain samat etuliitteet turvautuvat metriikkaan.

Lue todellinen reititystaulukko

Yhdistetty isäntä voi näyttää kaikki kolme merkintää kerralla, kun tunneli kuljettaa puolikkaat ja alkuperäinen yhdyskäytävä on yhä luettelossa. Osoitteet ovat esimerkkejä, eivät kopioitava kokoonpano, koska liitäntöjen nimet, tunnelin topologia ja lisäreitit vaihtelevat alustan ja asiakasohjelman mukaan.

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ärkeä on suhde: kaksi tiettyä puolikasta yhden yleisen oletusreitin yläpuolella. Vanhan yhdyskäytävän rivi jää, koska mikään ei korvannut sitä.

Tarkista, minkä reitin paketti todella ottaa

Tarkemmat reitit voivat silti voittaa: reitti yksityiselle alueelle, paikalliselle aliverkolle tai VPN-palvelimen oma osoite on pidempi kuin /1. Tunneli tarvitsee ulkoisen polun palvelimelleen, ja kyseisen yhteyden lähettäminen takaisin tunneliin rikkoisi sen heti. Linuxissa kysy ytimeltä sen sijaan, että lukisit taulukkoa silmällä: ip route get kiinnostavalla kohteella tulostaa valitun reitin, liitännän ja lähteen. Jos käytäntöpohjainen reititys on määritetty, tarkista myös säännöt, koska sääntö voi valita toisen taulukon ennen kuin päätaulukkoa katsotaan.

Jos vain osa IPv4:stä käyttäytyy väärin, varmista, että molemmat puolikkaat on asennettu, ja etsi sitten poikkeus, joka vastaa epäonnistuvaa kohdetta. Vanhan oletusreitin poistaminen ei ole korjaus, ja se poistaa reitin, jonka asiakasohjelma tarvitsee purkaakseen tunnelin puhtaasti.

Mitä def1 ei kata

Kaksi IPv4-merkintää ei kerro mitään IPv6:sta: IPv6-yhteyden isäntä käyttää yhä omaa oletusreittiään, kunnes jokin ohjaa kyseisen perheen erikseen, minkä vuoksi kaksoispino-verkossa osa liikenteestä näyttää kiertävän tunnelin. Muut asiakasohjelmat ja verkkohallintaohjelmat toteuttavat täystunnelin reitityksen eri tavalla, eivätkä niiden taulukot täsmää. Tässä kuvattu def1:n käyttäytyminen kuuluu OpenVPN:n dokumentoituun valitsimeen, ei jokaiseen koneen VPN:ään.

Kill switch vastaa toiseen kysymykseen: mitä kone tekee, kun tunneli putoaa. Reittien prioriteetti ratkaisee, minne liikenne menee tunnelin ollessa pystyssä; se ei ratkaise, mitä palomuuri tekee sen jälkeen. Työjärjestys: lue taulukko, varmista että molemmat puolikkaat ovat olemassa, suorita ip route get epäonnistuvalle kohteelle, tarkista käytäntösäännöt ja katso sitten IPv6:ta erikseen. Jätä vanha oletusreitti paikalleen.