OpenVPN redirect-gateway: mitä kukin lippu tekee reiteille

Yhdistä profiilissa redirect-gateway -asetuksella, ja koneesi oletusreitti voi kadota, jakautua kahtia tai pysyä täsmälleen paikallaan riippuen lipuista, joita kukaan ei lue kahdesti. Asetus muuttaa vain reitityksen tilaa eikä mitään muuta, joten ainoa luotettava todiste siitä, mitä se teki, on taulukko, jonka asiakas asensi sen jälkeen. Seuraavassa on taulukko yhteyden jälkeen, reitti joka pitää itse tunnelin elossa, ja IPv6-liikenne, jota direktiivi ei koskaan väitä kattavansa. Jokainen vaihe on komento, jonka voit suorittaa asiakkaalla tunnelin ollessa päällä.

Mitä kukin lippu tekee oletusreitille

Ilman mitään lippua asetus poistaa tavallisen oletusreitin ja asettaa tunnelin sen tilalle, joten vanha yhdyskäytävä katoaa taulukosta yhteyden ollessa päällä. Lisää def1, niin kyseinen oletus jää listaan ja työn tekevät kaksi kapeampaa reittiä. Lisää bypass-dhcp, niin myös DHCP-reitti säilyy, millä on merkitystä verkossa, jossa asiakkaan on vielä päästävä paikalliseen DHCP-palvelimeen. Lippujen luettelo OpenVPN 2.6:n käsikirjasivulla on riittävän lyhyt luettavaksi kerran, ja jokainen kohta muuttaa sitä, mitkä reitit päätyvät taulukkoon.

Työnnetty asetus käyttäytyy samoin saapuessaan, joten asiakasprofiilissa ei välttämättä ole mitään, vaikka taulukko näyttää täysin uudelleenohjatulta. Se on normaalia: palvelin lähetti liput, asiakas sovelsi ne, eikä paikallinen tiedosto maininnut direktiiviä koskaan. Kun työntö näyttää tekevän ei mitään, tarkista asiakaspuolen suodatin, joka hyväksyy tai hylkää vedetyt asetukset, sillä hylätty asetus ei aiheuta virhettä kummallakaan puolella.

def1 voittaa tarkkuudella koskematta oletukseesi

Kaksi puolikasta oletusreittiä kattavat yhdessä IPv4-avaruuden, 0.0.0.0/1 ja 128.0.0.0/1. Kumpikin on tarkempi kuin 0.0.0.0/0, joten haku suosii niitä, kun taas todellinen oletus jää taulukkoon kaikelle, mikä pyytää vähiten tarkkaa osumaa.

Lue taulukkoa äläkä profiilia, sillä vain taulukko näyttää, missä näistä tapauksista olet. Kaksi riviä riittää erottamaan ne:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Huomioi liitäntä ja metriikka jokaisella rivillä, älä vain kohde. Tunneliin osoittava oletus ja tunneliin osoittava puolikkaiden oletusten pari kuvaavat samaa aikomusta ja epäonnistuvat eri tavalla, kun tunneli putoaa, koska yhdessä tapauksessa varareitti on yhä olemassa. Kirjaa molemmat kentät muutoksen muistiinpanoon. Henkiin jäänyt varareitti pitää joskus etäistunnon elossa riittävän kauan tunnelin korjaamiseksi, ja se on myös se, mikä vuotaa liikennettä, kun aikomus oli täysi tunneli.

Pidä tunnelin päätepiste saavutettavana

Asiakas tarvitsee reitin tunnelin kauempaan päähän, joka ei itse kulje tunnelin läpi. OpenVPN asentaa kyseisen isäntäreitin ennen kuin muuttaa mitään muuta, ja käsin tehty reittimuutos tai toinen VPN-asiakas voi poistaa sen. Oire sen jälkeen on yhteys, joka ilmoittaa olevansa yhdistetty ja päästää sitten mitään läpi.

Kysy ytimeltä, mitä liitäntää se käyttäisi päätepisteen osoitteeseen tunnelin ollessa päällä. Vastauksen on nimettävä fyysinen liitäntä ja sen yhdyskäytävä, ei koskaan tun0:

ip route get 198.51.100.20

Jos haku palauttaa tunnelilaitteen, tunneli kuljettaa omaa siirtoaan ja romahtaa heti, kun paketin on lähdettävä. Paikalliset etuliitteet, toinen sovitin ja käytäntöpohjainen reititys merkitsevät yhä tässä, siksi puhtaalla kannettavalla toimiva uudelleenohjaus voi epäonnistua isännässä, jossa on hallintaliitäntä ja kaksi oletusta. Yleensä profiilia syytetään siitä, mitä osoitesuunnitelma teki.

IPv6-liikenne käyttää edelleen omaa taulukkoaan

IPv4:n uudelleenohjaus jättää IPv6:n rauhaan, ja kahta perhettä muuttavat eri liput. Kaksoispinoisännässä, jossa v6-oletus toimii, v4-liikenne voi istua täysin tunnelin sisällä, kun taas jokainen v6-kykyinen kohde lähtee fyysisen linkin kautta. Isäntä, joka näyttää oikealta yhdessä taulukossa, vuotaa toisessa.

Tarkista v6-taulukko yhteyden jälkeen sen sijaan, että olettaisit tunnelin kattaneen sen. Direktiivi kantaa osoiteperheen lippuja juuri tästä syystä, ja profiili, joka jättää ne pois, perii sen, mitä alusta tekee oletuksena:

ip -6 route show default
ip -6 route get 2001:db8::10

Todista, mitä liitäntää sovellus käyttää

Yhdistetty tila ei ole esto, eikä reittimuutos ole hätäkatkaisin. Jos suoran liikenteen on pysyttävä, kun tunneli epäonnistuu, se käytäntö elää palomuurissa ja tarvitsee oman testinsä.

Testaa reitti, jonka sovellus todella kulkee, älä reittiä, jonka profiili kuvaa. Pyydä ensin reitti, sido sitten pyyntö vuorollaan kuhunkin liitäntään ja vertaa, mitä kauko puoli raportoi:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Jos molemmat pyynnöt palauttavat saman osoitteen, sovellus ei käytä tunnelia, vaikka reititystaulukko sanoo sen pitävän. Jos vain tunneliin sidottu pyyntö onnistuu, fyysinen reitti on suodatettu kyseiselle kohteelle ja tunneli tekee sen, mitä pyysit. Kirjoita liput, asennetut reitit, päätepistehaku ja molemmat lähtötulokset muutoskirjaan, jotta seuraava henkilö perii tosiasiat eikä kuvakaappausta.