Kaksi yhdyskäytävää, yksi VPN: miksi OpenVPN valitsee väärän lähtevän yhteyden

Kaksi lähtevää yhteyttä, yksi tunneli, ja liikenne lähtee sitä kautta, jota et valinnut. Yksityiset aliverkot ovat tavoitettavissa, loki ilmoittaa onnistuneesta yhteydestä, ja juuri mitattu linkki on se, joka sitä kantaa. Mikään OpenVPN:n tulosteessa ei mainitse yhdyskäytävää, koska asiakas ei koskaan valinnut sellaista. Se avasi socketin etäosoitteeseen ja jätti ytimelle päätettäväksi, miten siihen osoitteeseen päästään.

Tunnelin osoite ei ole päätepiste

Jokaisessa istunnossa on kaksi eri polkua. Ulompi polku kuljettaa salatun liikenteen palvelimen julkiseen osoitteeseen. Sisempi polku kuljettaa kaiken, mitä palvelin työntää tunneliin, eivätkä yhden reittisäännöt vaikuta toiseen.

Profiilin remote-merkintä nimeää ulomman kohteen, joten se on kiinnitettävä osoite. Se on myös arvo, joka muuttuu, kun isäntänimi ratkeaa eri tavalla tai profiili luettelee useita remote-merkintöjä.

Etsi osoite, johon asiakas todella soitti

Lue elävää socketia konfiguraatiotiedoston sijaan. Socket-taulukko näyttää vertaisen, johon prosessi todella yhdisti, ja se on arvo, johon poikkeuksen on osuttava. Profiilia voidaan muokata istunnon alettua, ja socket on ainoa todiste siitä, mihin soitettiin:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Lokirivi ilmoittaa vertaisen osoitteen ja portin yhteyden hetkellä. Jos se poikkeaa profiilista, jokin asiakkaan edessä kirjoittaa kohteen uudelleen ennen kuin yhteys alkaa.

Tarkista myös osoiteperhe. Kahden pinon profiili voi yhdistää IPv6:n kautta, kun poikkeuksesi kattaa vain IPv4:n, ja silloin liikenne noudattaa eri sääntöä kuin kirjoittamasi. Sama koskee välityspalvelinta, joka vastaa päätepisteen puolesta. Molemmat tapaukset tuottavat tunnelin, joka toimii, kun taas reittisi ei tee mitään.

Kiinnitä päätepiste ja lue käytännön järjestys

Isäntäreitti on täsmällisempi kuin mikään oletusreitti. Siksi vertaisosoitteen /32 voittaa taulukossa, joka sen sisältää. Tavallinen muoto nimeää yhdyskäytävän ja laitteen selvästi:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Reitistä on hyötyä vain, jos haku saavuttaa kyseisen taulukon. Käytäntösäännöt arvioidaan järjestyksessä ja ensimmäinen osuma ratkaisee, joten sääntö, joka lähettää kaiken toiseen taulukkoon, ohittaa isäntäreittisi main-taulukossa. Lue säännöt ennen kuin oletat reitin olevan määräävä:

ip rule show
ip route get 203.0.113.40

Kysy toista komentoa samalla lähdeosoitteella tai merkillä, jota asiakas käyttää, kun käytäntö riippuu niistä. Se ilmoittaa reitin, jonka ydin valitsisi, mikä on todiste hausta eikä todiste siitä, että elävä socket käyttää tuota polkua.

Kun päätepiste liikkuu

Isäntänimi, joka ratkeaa useisiin osoitteisiin, mitätöi pysyvän /32:n heti kun vastaus muuttuu. Profiililla, jossa on useita remote-rivejä, on sama ongelma, koska asiakas voi laskeutua mille tahansa niistä. Päivitä reitti asiakkaan omista elinkaaren koukuista sen sijaan, että lisäisit sen käsin. up-skripti, joka lukee neuvotellun vertaisen ja asentaa isäntäreitin, pitää poikkeuksen linjassa todellisuuden kanssa, ja vastaava down-skripti poistaa sen.

Kirjaa päivitys samaan paikkaan kuin muu isännän reitityskonfiguraatio. Reitti, joka on olemassa vain seuraavaan uudelleenkäynnistykseen asti, on testi, ei korjaus.

Pidä sisäinen käytäntö erillään

Ulomman polun siirtäminen ei anna pääsyä uuteen yksityiseen aliverkkoon eikä muuta sitä, mitä kohteita palvelin työntää tunneliin. Alemman kerroksen reitti valitsee johdon; työnnetyt reitit valitsevat, mitä tunneliin tulee. Näiden kahden päätöksen pitäminen erillään tekee jaosta ennustettavan.

Jos tavoitteena on vain pitää salattu liikenne poissa mitatusta linkistä, jätä oletusreitti rauhaan ja lisää yksittäinen isäntäpoikkeus. Koneenlaajuisen oletusreitin korvaaminen yhden VPN-yhteyden siirtämiseksi rikkoo jokaisen muun sovelluksen isännällä.

Vahvista tulos kahdella riippumattomalla havainnolla: socketin paikallisella osoitteella ja laitteella sekä reitillä, johon yksityinen kohde ratkeaa. Kun molemmat vastaavat aikomustasi, jako on todellinen. OpenVPN 2.6 -käsikirja kattaa remote- ja paikallisen sidonnan vaihtoehdot, jotka päättävät, mihin osoitteeseen asiakas soittaa.