Server eller klient: hvilken OpenVPN-enhet på en Pi med dobbeltrolle

To OpenVPN-prosesser kjører på en Pi som både tar imot gjestebrukere og når en leverandør ovenfor, og de deler nesten ingenting utover maskinvaren. Én lytter etter innkommende tunneler mens den andre ringer ut. Hver leser sin egen katalog, og hver har sin egen feilmodus. Å starte den gale på nytt er den vanligste måten en klientretting ender med å velte lytteren i stedet.

Koble enhetsnavnet til katalogen den laster

Upstream 2.6 leverer to malenheter, [email protected] og [email protected]. Servermalen starter i /etc/openvpn/server og laster %i.conf derfra. Klientmalen starter i /etc/openvpn/client. En instans som heter roaming kan finnes begge steder samtidig, som server og som klient, med to uavhengige konfigurasjoner og ingen forbindelse mellom dem utover strengen.

Spør systemd i stedet for filsystemet, fordi pakkebyggere legger til ekstra filer som kan endre arbeidskatalogen eller argumentene binæren mottar.

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

Den første kommandoen viser hver instansierte enhet, også de som feilet og ble liggende lastet. Den andre skriver ut enhetsfilen sammen med enhver overstyring. Den tredje er den raskeste måten å se de to fakta som avgjør spørsmålet: katalogen prosessen starter i, og konfigurasjonsstien den fikk.

Avgjør etter pakkeretning, ikke etter grensesnittnavn

En serverinstans eier en lyttende socket og godtar tilkoblinger. Den krypterte transporten er lokal inngang og lokal utgang på Pi-en, mens trafikken den videresender for brukere følger videresendingsstien og svarer til et annet regelsett. En klientinstans har ingen lytter i den forstanden: den ringer en peer, så den krypterte transporten er lokal utgang mot underlaget.

Den forskjellen forteller deg hvor en regel hører hjemme. En regel som samsvarer med et grensesnitt inne i en videresendingskjede tillater bare trafikk som rutingen allerede har valgt; den velger aldri ruten. Når pakkene til en gjestebruker går ut gjennom feil vei, er kjeden som skal undersøkes forward, ikke output.

Se på sockets før du teoretiserer. En server bundet til udp/1194 viser en lyttende socket. Klienten viser en assosiasjon til leverandørens adresse og ingenting som lytter.

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

Standardruten til én instans kan fange svarene til den andre

En redirect-gateway som dyttes av klienten ovenfor installerer en standardrute som konkurrerer med alt annet på maskinen, inkludert svarene serveren sender til gjestebrukere. OpenVPN gjør et unntak for sin egen peer-adresse slik at tunnelen forblir nåbar, men det unntaket sier ingenting om en telefon på et hotellnettverk.

Symptomet er vanligvis asymmetrisk. Håndtrykket fullføres, klienten rapporterer tilkoblet, og trafikken dør etter den første svarpakken. Kildebasert policy-ruting, eller et pakkemerke satt på serverinstansen med --mark, holder de to strømmene fra hverandre; ingen av dem er et fullstendig regelsett alene, og begge trenger gyldige ruter i tabellen de velger.

Test den lokale beslutningen i stedet for tilstanden til tunnelen, fordi kjernen velger kilden og grensesnittet før OpenVPN ser pakken.

ip route get 203.0.113.44
ip rule show

Start én rolle på nytt og bevis at den andre overlevde

Rekkefølgen betyr noe når begge rollene avhenger av det samme underlaget. Start klienten først på nytt hvis ruten ovenfor må finnes før brukertrafikk kan videresendes, og start serveren først på nytt når du bare endrer lytteren eller puljen. Bekreft uansett begge enhetene etterpå, fordi en mislykket omstart kan la den andre rollen kjøre på utdatert tilstand.

Skriv ned stoppbetingelsen før endringen: blokkerer tapet av tunnelen ovenfor gjestebrukere, eller faller det tilbake på Pi-ens egen uplink? DNS og IPv6 trenger også et tydelig svar, fordi en dyttet resolver ofte lever lenger enn ruten som gjorde den nyttig.

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

Godta endringen bare når tre ting gjelder samtidig: en ny innkommende tilkobling fullføres, en videresendt applikasjon når målet sitt gjennom den tiltenkte utgangen, og begge prosessene rapporterer fortsatt sin forventede peer. Hvis én av de tre feiler, har du endret feil instans eller feil rute, og neste steg er å lese enheten på nytt i stedet for å starte noe annet på nytt.