Én Pi, to OpenVPN-instanser: hvad hver enhed læser
To OpenVPN-dæmoner på én Pi læser forskellige konfigurationsfiler og forlader gennem forskellige hooks. Kortlæg hver instans, og test derefter nyttelastens vej separat.
Tæl OpenVPN-processerne, før du rører en profil. En Pi, der optager roaming-brugere og også ringer op til en upstream-tjeneste, kører to dæmoner, og hver af dem læser en konfigurationsfil, som vælges af det instansnavn, du skrev. De pakkede skabeloner giver derefter hver dæmon sit eget arbejdsbibliotek, sin egen runtime-statusfil og sin egen tunneleenhed. Tager du fejl af denne opdeling, bruger du en aften på at ændre en korrekt indstilling i en fil, som den kørende proces aldrig åbner.
Hvert instansnavn vælger sin egen fil
I de enhedsfiler, der leveres med OpenVPN 2.6, bærer startargumenterne en instanspladsholder, som udfyldes fra teksten efter @-tegnet. Server-skabelonen kører fra serverens konfigurationsbibliotek og opløser sit argument mod %i.conf der, mens klient-skabelonen gør det samme fra klientbiblioteket. Så [email protected] læser admits.conf i serverbiblioteket, og [email protected] læser uplink.conf i klientbiblioteket, og ingen af navnene har nogen betydning i det andet bibliotek.
Bekræft tilknytningen på maskinen i stedet for at antage, at pakken har bevaret upstream-standarderne. Et distributionstillæg må gerne erstatte arbejdsbiblioteket eller konfigurationsargumentet helt.
systemctl cat [email protected]
systemctl cat [email protected]Læs linjen WorkingDirectory og konfigurationsargumentet i det output, fordi den aktiverede enhed er det eneste, der afgør, hvilken fil der indlæses. Et tillæg, der føjer --config til ExecStart, vinder over skabelonen, selv når skabelonens sti ser rigtig ud. Spørg efter fragment- og tillægsstierne, når du vil vide, om en lokal tilsidesættelse er i spil. Hvis begge roller opløses til én fil, har du én proces, der forsøger at være både server og klient, og den senere indstilling i den fil vinder i stilhed.
Lokal transport og videresendt nyttelast rammer forskellige hooks
Serverens krypterede forbindelse til hver roaming-bruger genereres på selve Pi'en, så dens ydre svar forlader gennem den lokale output-hook. Klientens forbindelse til sin upstream-peer er også lokalt genereret output, selv om den når et fjernnetværk. Videresendt nyttelast er en tredje kategori, og kernen matcher den først, efter at den allerede har valgt en udgående enhed til pakken.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
En regel, der matcher en udgående grænseflade inde i en videresendelseskæde, kan tillade eller kassere en pakke, som routing allerede har tildelt den grænseflade, men den vælger aldrig grænsefladen. Når én vært afslutter en tunnel og starter en anden, er politikken, der sender brugerens nyttelast ind i upstream-tunnelen, og politikken, der beskytter Pi'ens egne krypterede svar, separate beslutninger. De lander tilfældigvis på samme fysiske netkort, og derfor bliver de forvekslet.
Den skelnen forklarer en almindelig halvfejl. Brugerne forbinder, håndtrykket fuldføres, og deres trafik forlader stadig den forkerte vej, fordi håndtrykket var lokalt, og nyttelasten blev videresendt, og kun én af de to blev nogensinde testet.
En importeret rute kan sluge svarene til dine brugere
Klientprofilens sikkerhedsindstilling afgør, hvad upstream må skubbe ind i Pi'ens routingtabel, og en bred omdirigering er den indstilling, der gør en fungerende dobbeltrolle-vært til en ødelagt. Hvis den skubbede rute dækker roaming-brugernes offentlige adresser, kan de svar, serveren genererer mod dem, følge den nye rute ind i upstream-tunnelen i stedet for at forlade gennem underlaget. Folk bekræfter ofte, at tunnelen til udbyderen stadig virker, og stopper der, fordi den trafik er tunnelens egen transport, og den fortsætter med at flyde, mens alt andet opfører sig forkert.
Kilde- eller mærkebaseret politik er måden, hvorpå de to strømme holdes adskilt. OpenVPN's Linux-mærkeindstilling mærker en dæmons egne krypterede pakker med et firewallmærke, som en routingregel derefter kan sende til en dedikeret tabel. Kildeadresser fungerer lige så godt, når serverens ydre svar altid forlader fra én underlagsadresse. Begge tilgange kræver gyldige ruter i den tabel, den vælger, og en undtagelse for udbyderens endepunkt, ellers holder tunnelen selv op med at komme op.
Spørg kernen, hvilken vej et svar faktisk ville tage, før du skriver nogen regel. Adresserne nedenfor er pladsholdere for en underlagsadresse på Pi'en og én roaming-brugers offentlige adresse.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Bekræft opdelingen, og stop derefter én rolle ad gangen
Test tre strømme separat, fordi et fungerende håndtryk intet beviser om de to andre. Accepter en ny indgående forbindelse, send én tilladte applikation gennem upstream-udgangen, og bekræft, at begge processer stadig når deres egne peers.
Stop derefter klientrollen, og se, hvad serverrollen beholder. Det er den billigste måde at finde en rute- eller mærkeregel, der var ment til én instans og anvendt på begge.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerDet, du vil se, er, at lytteren stadig er bundet, tunneleenheden stadig er til stede, og loggen er fri for nye fejl, mens klientrollen er nede. Hvis stop af klienten også afskærer serverens svar til eksisterende brugere, deler de to roller noget, der burde have været begrænset til én af dem. Notér, hvilken instans, hvilken konfigurationsfil og hvilken strømejer hver ændring rørte, fordi den næste, der fejlretter denne vært, ellers gentager den samme opdagelse fra nul.