Palvelin vai asiakas: mikä OpenVPN-yksikkö kaksoisroolin Pi:ssä

Yhdellä Pi:llä ajaa kaksi OpenVPN-prosessia, jotka sekä ottavat vastaan vierailijoita että tavoittavat ylätason tarjoajan, eivätkä ne jaa laitteiston lisäksi juuri mitään. Toinen kuuntelee saapuvia tunneleita, toinen soittaa ulos. Kumpikin lukee oman hakemistonsa, ja kummallakin on oma vikatilansa. Väärän yksikön uudelleenkäynnistys on yleisin tapa, jolla asiakaskorjaus päätyykin horjuttamaan kuuntelijaa.

Sovita yksikön nimi hakemistoon, jonka se lataa

Upstream 2.6 toimittaa kaksi mallipohjayksikköä, [email protected] ja [email protected]. Palvelinmalli käynnistyy hakemistossa /etc/openvpn/server ja lataa sieltä %i.conf. Asiakasmalli käynnistyy hakemistossa /etc/openvpn/client. roaming-niminen instanssi voi olla molemmissa paikoissa yhtä aikaa, sekä palvelimena että asiakkaana, kahdella toisiinsa liittymättömällä kokoonpanolla ja ilman muuta yhteyttä niiden välillä kuin merkkijono.

Kysy systemd:ltä tiedostojärjestelmän sijaan, koska paketoijat lisäävät lisätiedostoja, jotka voivat muuttaa työhakemistoa tai argumentteja, jotka binääri saa.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Ensimmäinen komento luettelee jokaisen luodun yksikön, myös ne, jotka epäonnistuivat ja jäivät ladatuiksi. Toinen tulostaa yksikkötiedoston yhdessä mahdollisen ohituksen kanssa. Kolmas on nopein tapa nähdä ne kaksi tosiasiaa, jotka ratkaisevat kysymyksen: hakemisto, jossa prosessi käynnistyy, ja kokoonpanopolku, joka sille annettiin.

Ratkaise paketin suunnan, älä liitännän nimen perusteella

Palvelininstanssilla on kuunteleva socket ja se hyväksyy yhteyksiä. Sen salattu siirto on paikallinen tulo ja paikallinen lähtö Pi:llä, kun taas käyttäjille välitettävä liikenne seuraa välityspolkua ja vastaa eri sääntöjoukkoa. Asiakasinstanssilla ei ole kuuntelijaa siinä mielessä: se soittaa vertaiselleen, joten sen salattu siirto on paikallinen lähtö alakerrosta kohti.

Tämä ero kertoo, mihin sääntö kuuluu. Välitysketjun sisällä liitäntään sopiva sääntö sallii vain liikenteen, jonka reititys on jo valinnut; se ei koskaan valitse reittiä. Kun vierailijan paketit lähtevät väärää tietä, tarkistettava ketju on forward, ei output.

Katso socketeja ennen kuin teoretisoit. udp/1194:ään sidottu palvelin näyttää kuuntelevan socketin. Asiakas näyttää liitoksen tarjoajan osoitteeseen eikä mitään kuuntelevaa.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Yhden instanssin oletusreitti voi napata toisen vastaukset

Ylätason asiakkaan työntämä redirect-gateway asentaa oletusreitin, joka kilpailee kaiken muun kanssa koneella, mukaan lukien ne vastaukset, jotka palvelin lähettää vierailijoille. OpenVPN tekee poikkeuksen omalle vertaisosoitteelleen, jotta tunneli pysyy tavoitettavana, mutta poikkeus ei kerro mitään hotelliverkossa istuvasta puhelimesta.

Oire on yleensä epäsymmetrinen. Kättely valmistuu, asiakas ilmoittaa yhteydestä, ja liikenne kuolee ensimmäisen vastauspaketin jälkeen. Lähdeperusteinen käytäntöreititys tai palvelininstanssille --mark:llä asetettu pakettimerkki pitää kaksi virtaa erillään; kumpikaan ei ole yksinään täydellinen sääntöjoukko, ja molemmat tarvitsevat kelvolliset reitit siinä taulussa, jonka ne valitsevat.

Testaa paikallista päätöstä tunnelin tilan sijaan, koska ydin valitsee lähteen ja liitännän ennen kuin OpenVPN näkee paketin.

ip route get 203.0.113.44
ip rule show

Käynnistä yksi rooli uudelleen ja todista, että toinen selvisi

Järjestyksellä on väliä, kun molemmat roolit riippuvat samasta alakerroksesta. Käynnistä asiakas ensin uudelleen, jos ylätason reitin on oltava olemassa ennen kuin käyttäjäliikennettä voidaan välittää, ja käynnistä palvelin ensin uudelleen, kun muutat vain sen kuuntelijaa tai sen poolia. Vahvista joka tapauksessa molemmat yksiköt jälkeenpäin, koska epäonnistunut uudelleenkäynnistys voi jättää toisen roolin käymään vanhentuneella tilalla.

Kirjoita pysäytysehto muistiin ennen muutosta: estääkö ylätason tunnelin menetys vierailijat, vai putoaako se Pi:n omaan ylälinkkiin? Myös DNS ja IPv6 tarvitsevat selvän vastauksen, koska työnnetty resolver elää usein kauemmin kuin reitti, joka teki siitä hyödyllisen.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Hyväksy muutos vain, kun kolme asiaa pätee yhtä aikaa: uusi saapuva yhteys valmistuu, välitetty sovellus saavuttaa kohteensa aiottu lähdön kautta ja molemmat prosessit ilmoittavat edelleen odotetun vertaisensa. Jos yksi kolmesta epäonnistuu, muutit väärää instanssia tai väärää reittiä, ja seuraava askel on lukea yksikkö uudelleen eikä käynnistää mitään muuta uudelleen.