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

To OpenVPN-processer kører på en Pi, der både tager imod roamingbrugere og når en udbyder ovenover, og de deler næsten intet ud over hardwaren. Den ene lytter efter indgående tunneler, mens den anden ringer ud. Hver læser sin egen mappe, og hver har sin egen fejltilstand. At genstarte den forkerte er den mest almindelige måde, hvorpå en klientrettelse ender med at vælte lytteren i stedet.

Kobl enhedens navn til den mappe, den indlæser

Upstream 2.6 leverer to skabelonenheder, [email protected] og [email protected]. Server-skabelonen starter i /etc/openvpn/server og indlæser %i.conf derfra. Klient-skabelonen starter i /etc/openvpn/client. En instans med navnet roaming kan findes begge steder på én gang, som server og som klient, med to uafhængige konfigurationer og ingen forbindelse mellem dem ud over strengen.

Spørg systemd i stedet for filsystemet, fordi pakkemagere tilføjer ekstra filer, som kan ændre arbejdsmappen eller de argumenter, binæren modtager.

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

Den første kommando viser hver instansieret enhed, også dem der fejlede og blev hængende indlæst. Den anden udskriver enhedsfilen sammen med enhver tilsidesættelse. Den tredje er den hurtigste måde at se de to fakta, der afgør spørgsmålet: den mappe, processen starter i, og den konfigurationssti, den fik.

Afgør efter pakkeretning, ikke efter interface-navn

En serverinstans ejer en lyttende socket og accepterer forbindelser. Dens krypterede transport er lokal input og lokal output på Pi'en, mens den trafik, den videresender for brugere, følger videresendelsesstien og svarer til et andet regelsæt. En klientinstans har ingen lytter i den forstand: den ringer til en peer, så dens krypterede transport er lokal output mod underlaget.

Den forskel fortæller dig, hvor en regel hører til. En regel, der matcher et interface inde i en videresendelseskæde, tillader kun trafik, som routing allerede har valgt; den vælger aldrig ruten. Når en roamingbrugers pakker forlader gennem den forkerte vej, er den kæde, der skal undersøges, forward, ikke output.

Se på sockets, før du teoretiserer. En server bundet til udp/1194 viser en lyttende socket. Klienten viser en association til udbyderens adresse og intet, der lytter.

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

Én instans' standardrute kan opsnappe den andens svar

En redirect-gateway, der skubbes af klienten ovenover, installerer en standardrute, som konkurrerer med alt andet på maskinen, inklusive de svar, serveren sender til roamingbrugere. OpenVPN laver en undtagelse for sin egen peer-adresse, så tunnelen forbliver nåbar, men den undtagelse siger intet om en telefon på et hotelnetværk.

Symptomet er normalt asymmetrisk. Handshaket fuldføres, klienten rapporterer forbundet, og trafikken dør efter den første svarpakke. Kildebaseret policy-routing eller et pakkemærke sat på serverinstansen med --mark holder de to strømme adskilt; ingen af dem er et komplet regelsæt i sig selv, og begge har brug for gyldige ruter i den tabel, de vælger.

Test den lokale beslutning i stedet for tunnelens tilstand, fordi kernen vælger kilden og interfacet, før OpenVPN ser pakken.

ip route get 203.0.113.44
ip rule show

Genstart én rolle og bevis, at den anden overlevede

Rækkefølgen betyder noget, når begge roller afhænger af det samme underlag. Genstart klienten først, hvis ruten ovenover skal findes, før brugetrafik kan videresendes, og genstart serveren først, når du kun ændrer dens lytter eller dens pulje. Bekræft under alle omstændigheder begge enheder bagefter, fordi en mislykket genstart kan efterlade den anden rolle kørende på forældet tilstand.

Skriv stopbetingelsen ned før ændringen: blokerer tabet af tunnelen ovenover roamingbrugere, eller falder den tilbage til Pi'ens egen uplink? DNS og IPv6 kræver også et klart svar, fordi en skubbet resolver ofte overlever den rute, der gjorde den nyttig.

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

Accepter ændringen kun, når tre ting gælder samtidigt: en ny indgående forbindelse fuldføres, en videresendt applikation når sin destination gennem den tilsigtede udgang, og begge processer rapporterer stadig deres forventede peer. Hvis en af de tre fejler, har du ændret den forkerte instans eller den forkerte rute, og næste skridt er at læse enheden igen i stedet for at genstarte noget andet.