Server of client: welke OpenVPN-unit op een Pi met dubbele rol

Op één Pi draaien twee OpenVPN-processen die tegelijk roamende gebruikers aannemen en een upstream-provider bereiken, en ze delen bijna niets buiten de hardware. De ene luistert naar inkomende tunnels terwijl de andere naar buiten belt. Elk leest zijn eigen map, en elk heeft zijn eigen faalmodus. De verkeerde herstarten is de meest voorkomende manier waarop een clientfix juist de luisteraar van zijn stuk brengt.

Koppel de unitnaam aan de map die hij laadt

Upstream 2.6 levert twee template-units, [email protected] en [email protected]. Het servertemplate start in /etc/openvpn/server en laadt daaruit %i.conf. Het clienttemplate start in /etc/openvpn/client. Een instantie met de naam roaming kan op beide plaatsen tegelijk bestaan, als server en als client, met twee onafhankelijke configuraties en geen andere verbinding tussen beide dan de tekenreeks.

Vraag het systemd in plaats van het bestandssysteem, want pakketbouwers voegen drop-ins toe die de werkmap of de argumenten kunnen wijzigen die het binaire bestand ontvangt.

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

De eerste opdracht somt elke geïnstantieerde unit op, ook degene die faalden en geladen bleven. De tweede drukt het unitbestand af samen met elke override. De derde is de snelste manier om de twee feiten te zien die de vraag beslechten: de map waarin het proces start, en het configuratiepad dat het kreeg.

Beslis op pakketrichting, niet op interfacenaam

Een serverinstantie bezit een luisterende socket en aanvaardt verbindingen. Het versleutelde transport is lokale invoer en lokale uitvoer op de Pi, terwijl het verkeer dat zij voor gebruikers doorstuurt het doorstuuppad volgt en aan een andere regelset voldoet. Een clientinstantie heeft in die zin geen luisteraar: zij belt een peer, dus haar versleutelde transport is lokale uitvoer richting de onderlaag.

Dat verschil vertelt u waar een regel thuishoort. Een regel die overeenkomt met een interface binnen een doorstuuketen staat alleen verkeer toe dat de routering al heeft gekozen; hij kiest nooit de route. Wanneer de pakketten van een roamende gebruiker via de verkeerde weg naar buiten gaan, is de keten die u moet onderzoeken forward, niet output.

Kijk naar sockets voordat u theoretiseert. Een server die aan udp/1194 is gebonden, toont een luisterende socket. De client toont een associatie met het adres van de provider en niets dat luistert.

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

De standaardroute van de ene instantie kan de antwoorden van de andere opvangen

Een redirect-gateway die de upstream-client duwt, installeert een standaardroute die met al het andere op de machine concurreert, inclusief de antwoorden die de server naar roamende gebruikers stuurt. OpenVPN maakt een uitzondering voor zijn eigen peeradres zodat de tunnel bereikbaar blijft, maar die uitzondering zegt niets over een telefoon op een hotelnetwerk.

Het symptoom is meestal asymmetrisch. De handshake voltooit, de client meldt verbonden, en het verkeer sterft na het eerste antwoordpakket. Bron-gebaseerde policy-routing, of een pakketmarkering die met --mark op de serverinstantie wordt gezet, houdt de twee stromen gescheiden; geen van beide is op zichzelf een volledige regelset, en beide hebben geldige routes nodig in de tabel die ze kiezen.

Test de lokale beslissing in plaats van de toestand van de tunnel, want de kernel kiest de bron en de interface voordat OpenVPN het pakket ziet.

ip route get 203.0.113.44
ip rule show

Herstart één rol en bewijs dat de andere het overleefde

De volgorde is belangrijk wanneer beide rollen van dezelfde onderlaag afhangen. Herstart de client eerst als de upstream-route moet bestaan voordat gebruikersverkeer kan worden doorgestuurd, en herstart de server eerst wanneer u alleen zijn luisteraar of zijn pool wijzigt. Bevestig daarna hoe dan ook beide units, want een mislukte herstart kan de andere rol op verouderde toestand laten doorlopen.

Schrijf de stopvoorwaarde op vóór de wijziging: blokkeert het verlies van de upstream-tunnel de roamende gebruikers, of valt het terug op de eigen uplink van de Pi? DNS en IPv6 hebben ook een expliciet antwoord nodig, want een geduwde resolver overleeft vaak de route die hem nuttig maakte.

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

Accepteer de wijziging alleen wanneer drie dingen tegelijk gelden: een nieuwe inkomende verbinding voltooit, een doorgestuurde toepassing bereikt haar bestemming via de bedoelde uitgang, en beide processen melden nog steeds hun verwachte peer. Als een van de drie faalt, hebt u de verkeerde instantie of de verkeerde route gewijzigd, en de volgende stap is de unit opnieuw lezen in plaats van iets anders te herstarten.