Miksi toinen VPN-tunneli rikkoo ensimmäisen?

Toisen VPN-asiakkaan asentaminen yhden asiakasverkon saavuttamiseksi on tavallinen tapa, jolla tämä alkaa, ja ensimmäinen tunneli pimenee, kun molemmat asiakkaat raportoivat onnistumisesta. Kukin asiakas asensi oletusreitin, toinen oli tarkempi, ja ydin seuraa sitä nyt kaikelle paitsi ensimmäisen tunnelin omalle ulkoyhteydelle. Mikään ei kaatunut eikä mikään profiili ole väärin. Yksi reitti korvasi toisen, ja ratkaisu on päättää, kumman tunnelin pitäisi omistaa oletusreitti.

Oire: toinen asiakas voittaa hiljaa

OpenVPN: redirect-gateway def1-valinta ei korvaa 0.0.0.0/0-reittiä. Se lisää 0.0.0.0/1 ja 128.0.0.0/1: yhdessä ne kattavat jokaisen IPv4-osoitteen, ja jokainen etuliite voittaa tavallisen oletusreitin pituudellaan. Alkuperäinen oletusreitti jää tauluun eikä sitä enää käytetä tavalliseen liikenteeseen, ja isäntäreitti VPN-palvelimelle estää tunnelia kaappaamasta omia ulkopakettejaan. Molemmat asiakkaat tekevät näin, ja toinen yksinkertaisesti asentaa parinsa myöhemmin.

Siksi ensimmäinen tunneli näyttää kuolleelta eikä katkenneelta. Sen rajapinta on ylhäällä, ohjauskanava elää, eikä sinne enää saavu sovellusliikennettä. Vastakkainen valitus johtuu samasta puuttuvasta pushista: puhelin, joka yhdistää mutta ei lähetä mitään, puhuu yleensä palvelimelle, joka ei koskaan mainostanut redirect-gatewayta, joten laite pitää oman oletusreittinsä ja tavoittaa vain altaan.

Ota reittikuvakaappaus ennen toisen asiakkaan yhdistämistä ja sen jälkeen. Tauluun ilmestyvät kaksi puolireittiä ovat koko muutos, ja ne selittävät molemmat valitukset. Mikään muu taulussa ei tarvitse liikkua, jotta oire ilmaantuisi. Siksi toisen asiakkaan poistaminen palauttaa ensimmäisen heti.

Lue, kumpi tunneli todella voittaa

Älä päättele voittajaa asiakkaiden käynnistysjärjestyksestä äläkä ilmaisinalueen kuvakkeesta. Kysy ytimeltä, mitä reittiä se käyttäisi kohteeseen molempien yksityisverkkojen ulkopuolella, ja lue palautuva rajapinta.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Kaksi ensimmäistä ovat Linuxin vastaus ja kaksi viimeistä Windowsin vastine. Suorita ne, kun molemmat tunnelit ovat ylhäällä, katkaise sitten toinen ja suorita ne uudelleen. Kahden tulosteen ero on se tosiasia, jonka tarvitset ennen ratkaisun valintaa, ja se vie vähemmän aikaa kuin kummankaan asiakkaan lokin lukeminen.

Kirjaa tulos, mukaan lukien rajapinnan nimi ja täsmännyt etuliite. Tiketti, joka sanoo toisen VPN:n rikkoneen ensimmäisen, on oireen kuvaus, ei reititysväite, jonka pohjalta kukaan voisi toimia. Haku tekee siitä tosiasian, jonka seuraava insinööri voi toistaa yhdellä komennolla.

Windows: estä yhtä profiilia omistamasta oletusreittiä

Windows säilyttää tallennettuja profiileja, ja sisäänrakennettu asiakas sallii yhden riippua toisesta, jotta ensimmäinen nousee automaattisesti, kun toinen soittaa. Viimeksi yhdistetty profiili tapaa pitää oletusreitin, joten käytännön omistaja on viimeinen soitto eikä ensimmäinen. Anna kullekin profiilille omat push-reittinsä ja kytke split tunneling päälle sille, joka ei saisi omistaa oletusreittiä.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling muuttaa tätä: vain palvelimen pushaamat etuliitteet päätyvät tauluun, mikä jättää oletusreitin ensimmäiselle tunnelille. Suunnittelu epäonnistuu silti, jos molemmat palvelimet pushaavat oletusreitin, sillä silloin viimeinen yhteys voittaa eikä mikään asiakaspuolen asetus muuta sitä. Korjaa push palvelinpuolella tai hyväksy yksi omistaja.

Sovelluksen käynnistämät profiilit ovat eri ominaisuus ja kannattaa tuntea: Windows-profiili voi käynnistyä, kun nimetty suoritettava tiedosto käynnistyy, ja liikennesuodattimet päättävät, mitä se kuljettaa. Se on profiiliasetus eikä palomuurisääntö, ja se ratkaisee eri ongelman kuin oletusreitin ristiriita.

Linux: pidä toinen tunneli poissa päätaulusta

Kahden openvpn --config-esiintymän ajaminen yhdellä koneella laittaa molemmat asiakkaat samaan tauluun, ja kolme vaihtoehtoa erottaa ne kasvavalla eristyksellä. Kevyin on estää toista asiakasta muokkaamasta taulua lainkaan: route-nopull ja eksplisiittiset reitit tai route-up-skripti, joka asentaa vain sen, mitä aiot. Silloin toinen tunneli kuljettaa täsmälleen nimeämäsi etuliitteet eikä mitään muuta. Silloin sinä päätät, mitkä etuliitteet menevät minne, sen sijaan että löytäisit sen jälkikäteen.

Käytäntöperusteinen reititys on keskimmäinen vaihtoehto. Sääntö valitsee erillisen taulun yhdelle lähdeosoitteelle tai palomuurimerkille, ja tämä taulu kuljettaa toisen tunnelin reitit. Käänteisen polun suodatus on tässä ansa, koska vastaus, joka saapuu eri rajapinnalle kuin taulu valitsisi, pudotetaan, joten tarkista rp_filter-asetus ennen kuin päättelet tunnelin olevan rikki.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Verkkonimiavaruudet ovat raskain ja puhtain vaihtoehto. Käynnistä toinen asiakas ip netns-nimiavaruuden sisällä, anna sille veth-pari ja astu siihen nimiavaruuteen käyttääksesi sitä. Häiriöt katoavat, koska jokainen nimiavaruus omistaa omat taulunsa jakamisen sijaan, mikä on lisäasetuksen arvoista, kun molempien tunnelien on pysyttävä ylhäällä viikkoja.

Sovelluskohtaisesti, ja ketjutus erillisenä ongelmana

Joskus vain yhden ohjelman pitäisi käyttää toista tunnelia. Linuxissa käyttäjä-, cgroup- tai porttikohtainen käytäntöreititys saavuttaa tämän, ja yksi kohde voidaan kiinnittää rajapintaan koskematta oletusreittiin lainkaan. Sovellus, joka kiinnittää pistokkeensa yhteen rajapintaan, ei lainkaan konsultoi reititystaulua, joten käynnistin voi jatkaa fyysisen sovittimen käyttöä, kunnes sen omista asetuksista valitaan osoite.

Ketjutus on eri toimenpide kuin kahden tunnelin ajaminen rinnakkain. A:n ketjuttaminen B:n yli tarkoittaa, että sisemmän palvelimen osoitteen on oltava saavutettavissa ulomman tunnelin sisältä. Ulompi asiakas ei myöskään saa pitää sisemmän asiakkaan salattuja paketteja vuotona. Yksi asiakas virtuaalikoneen sisällä on karkea mutta luotettava versio; molemmat yhdellä isännällä vaativat yllä olevan reititystyön sekä ulkoisen polun sisempää palvelinta kohti, joka ei koskaan mene sisempään tunneliin.

Kirjoita ylös oletusreitin omistaja, kunkin tunnelin kuljettamien etuliitteiden luettelo ja DNS-polku. Nämä kolme tosiasiaa muuttavat seuraavan tapauksen hauksesi tutkinnan sijaan.