Tenar eller klient: kva OpenVPN-eining på ein Pi med dobbeltrolle

To OpenVPN-prosessar køyrer på ein Pi som både tek imot gjestebrukarar og når ein leverandør ovanfor, og dei deler nesten ingenting utover maskinvaren. Éin lyttar etter innkomande tunnelar medan den andre ringer ut. Kvar les sin eigen katalog, og kvar har sin eigen feilmodus. Å starte den gale på nytt er den vanlegaste måten ein klientretting endar med å velte lyttaren i staden.

Kople namnet på eininga til katalogen ho lastar

Upstream 2.6 leverer to maleiningar, [email protected] og [email protected]. Tenarmalen startar i /etc/openvpn/server og lastar %i.conf derfrå. Klientmalen startar i /etc/openvpn/client. Ein instans som heiter roaming kan finnast båe stadene samtidig, som tenar og som klient, med to uavhengige konfigurasjonar og inga samband mellom dei utover strengen.

Spør systemd i staden for filsystemet, fordi pakkebyggjarar legg til ekstra filer som kan endre arbeidskatalogen eller argumenta binæren får.

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

Den første kommandoen viser kvar instansiert eining, også dei som feila og vart liggjande lasta. Den andre skriv ut einingafila saman med kvar overstyring. Den tredje er den raskaste måten å sjå dei to fakta som avgjer spørsmålet: katalogen prosessen startar i, og konfigurasjonsstien han fekk.

Avgjer etter pakkeretning, ikkje etter grensesnittnamn

Ein tenarinstans eig ein lyttande socket og godtek tilkoplingar. Den krypterte transporten er lokal inngang og lokal utgang på Pi-en, medan trafikken han videresender for brukarar følgjer videresendingsstien og svarar til eit anna regelsett. Ein klientinstans har ingen lyttar i den forstanden: han ringer ein peer, så den krypterte transporten er lokal utgang mot underlaget.

Den skilnaden fortel deg kvar ein regel høyrer heime. Ein regel som samsvarar med eit grensesnitt inne i ei videresendingskjede tillèt berre trafikk som rutinga allereie har valt; han vel aldri ruta. Når pakka til ein gjestebrukar går ut gjennom feil veg, er kjedja som skal granskast forward, ikkje output.

Sjå på sockets før du teoretiserer. Ein tenar bunden til udp/1194 viser ein lyttande socket. Klienten viser ein assosiasjon til adressa til leverandøren og ingenting som lyttar.

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

Standardruta til éin instans kan fange svara til den andre

Ein redirect-gateway som blir dytta av klienten ovanfor installerar ei standardrute som konkurrerer med alt anna på maskinen, inkludert svara tenaren sender til gjestebrukarar. OpenVPN gjer eit unntak for si eiga peer-adresse slik at tunnelen held seg nåbar, men det unntaket seier ingenting om ein telefon på eit hotellnettverk.

Symptomet er vanlegvis asymmetrisk. Handtrykket blir fullført, klienten rapporterer tilkopla, og trafikken døyr etter den første svarpakka. Kjeldebasert policy-ruting, eller eit pakkemerke sett på tenarinstansen med --mark, held dei to straumane frå kvarandre; ingen av dei er eit fullstendig regelsett åleine, og begge treng gyldige ruter i tabellen dei vel.

Test den lokale avgjerda i staden for tilstanden til tunnelen, fordi kjernen vel kjelda og grensesnittet før OpenVPN ser pakka.

ip route get 203.0.113.44
ip rule show

Start éin rolle på nytt og prov at den andre overlevde

Rekkefølgja har mykje å seie når begge rollene er avhengige av same underlaget. Start klienten først på nytt om ruta ovanfor må finnast før brukartrafikk kan videresendast, og start tenaren først på nytt når du berre endrar lyttaren eller puljen. Stadfest uansett båe einingane etterpå, fordi ein mislukka omstart kan la den andre rolla køyre på utdatert tilstand.

Skriv ned stoppvilkåret før endringa: blokkerer tapet av tunnelen ovanfor gjestebrukarar, eller fell det tilbake på Pi-en sin eigen uplink? DNS og IPv6 treng også eit tydeleg svar, fordi ein dytta resolver ofte lever lenger enn ruta som gjorde han nyttig.

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

Godta endringa berre når tre ting gjeld samtidig: ei ny innkomande tilkopling blir fullført, ein videresend applikasjon når målet sitt gjennom den tiltenkte utgangen, og båe prosessane rapporterer framleis sin forventa peer. Viss éin av dei tre feilar, har du endra feil instans eller feil rute, og neste steg er å lese eininga på nytt i staden for å starte noko anna på nytt.