Én Pi, to OpenVPN-instanser: hva hver enhet leser
To OpenVPN-demoner på én Pi leser ulike konfigurasjonsfiler og går ut gjennom ulike kroker. Kartlegg hver instans, og test deretter nyttelastbanen separat.
Tell OpenVPN-prosessene før du rører en profil. En Pi som tar imot gjestende brukere og samtidig ringer opp en oppstrømstjeneste, kjører to demoner, og hver av dem leser en konfigurasjonsfil som velges av instansnavnet du skrev inn. Pakkens maler gir deretter hver demon sin egen arbeidskatalog, sin egen kjøretidsstatusfil og sin egen tunnelenhet. Gjør du denne delingen feil, bruker du en kveld på å endre en riktig innstilling i en fil som den kjørende prosessen aldri åpner.
Hvert instansnavn velger sin egen fil
I enhetsfilene som følger med OpenVPN 2.6, bærer startargumentene en instansplassholder som fylles ut fra teksten etter @-tegnet. Servermalen kjører fra serverens konfigurasjonskatalog og løser argumentet sitt mot %i.conf der, mens klientmalen gjør det samme fra klientkatalogen. Så [email protected] leser admits.conf i serverkatalogen, og [email protected] leser uplink.conf i klientkatalogen, og ingen av disse navnene har noen betydning i den andre katalogen.
Bekreft tilordningen på maskinen i stedet for å anta at pakken har beholdt oppstrøms standardverdier. En drop-in fra distribusjonen kan erstatte arbeidskatalogen eller konfigurasjonsargumentet helt.
systemctl cat [email protected]
systemctl cat [email protected]Les WorkingDirectory-linjen og konfigurasjonsargumentet i den utdataen, fordi den aktiverte enheten er det eneste som avgjør hvilken fil som lastes. En drop-in som legger --config til ExecStart, vinner over malen selv når malstien ser riktig ut. Spør etter fragment- og drop-in-stiene når du vil vite om en lokal overstyring er i spill. Hvis begge rollene løses til én fil, har du én prosess som prøver å være både server og klient, og det senere alternativet i den filen vinner i stillhet.
Lokal transport og videresendt nyttelast treffer ulike kroker
Serverens krypterte forbindelse til hver gjestende bruker genereres på Pi-en selv, så de ytre svarene går ut gjennom den lokale utdatakroken. Klientens forbindelse til oppstrømspartneren er også lokalt generert utdata, selv om den når et eksternt nettverk. Videresendt nyttelast er den tredje kategorien, og kjernen matcher den først etter at den allerede har valgt en utgående enhet for 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 som matcher et utgående grensesnitt inne i en forward-kjede, kan tillate eller forkaste en pakke som rutingen allerede har tildelt det grensesnittet, men den velger aldri grensesnittet. Når én vert avslutter én tunnel og starter en annen, er politikken som sender brukernyttelast inn i oppstrømstunnelen, og politikken som beskytter Pi-ens egne krypterte svar, to separate beslutninger. De havner tilfeldigvis på samme fysiske NIC, og derfor blir de forvekslet.
Den forskjellen forklarer en vanlig halvfeil. Brukerne kobler til, håndtrykket fullføres, og trafikken deres går likevel ut feil vei, fordi håndtrykket var lokalt og nyttelasten var forward, og bare én av de to ble noen gang testet.
En importert rute kan svelge svarene til brukerne dine
Sikkerhetsinnstillingen i klientprofilen avgjør hva oppstrømmen kan dytte inn i Pi-ens rutetabell, og en bred omdirigering er alternativet som gjør en fungerende vert med to roller til en ødelagt en. Hvis den dyttede ruten dekker de offentlige adressene til gjestende brukere, kan svarene serveren genererer mot dem, følge den nye ruten inn i oppstrømstunnelen i stedet for å gå ut via underlaget. Folk bekrefter ofte at tunnelen til leverandøren fortsatt virker, og stopper der, fordi den trafikken er tunnelens egen transport og fortsetter å flyte mens alt annet oppfører seg feil.
Politikk basert på kilde eller mark er måten de to strømmene holdes fra hverandre på. OpenVPNs Linux-mark-alternativ stempler demonens egne krypterte pakker med en brannmurmark, som en ruteringsregel deretter kan sende til en egen tabell. Kildeadresser fungerer like godt når serverens ytre svar alltid går ut fra én underlagsadresse. Begge tilnærmingene trenger gyldige ruter i tabellen den velger, og et unntak for leverandørens endepunkt, ellers kommer ikke tunnelen selv opp.
Spør kjernen om banen et svar faktisk ville ta, før du skriver noen regel. Adressene nedenfor er plassholdere for en underlagsadresse på Pi-en og den offentlige adressen til én gjestende bruker.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Bekreft delingen, og stopp deretter én rolle om gangen
Test tre strømmer hver for seg, fordi et håndtrykk som virker ikke beviser noe om de to andre. Godta en ny innkommende tilkobling, send én tillatt applikasjon ut gjennom oppstrømsutgangen, og bekreft at begge prosessene fortsatt når sine egne partnere.
Stopp deretter klientrollen og se hva serverrollen beholder. Dette er den billigste måten å finne en rute- eller mark-regel som var ment for én instans og brukt 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 fortsatt er bundet, at tunnelenheten fortsatt finnes, og at loggen er fri for nye feil mens klientrollen er nede. Hvis det å stoppe klienten også kutter serverens svar til eksisterende brukere, deler de to rollene noe som burde vært begrenset til én av dem. Noter hvilken instans, hvilken konfigurasjonsfil og hvilken strømeier hver endring berørte, fordi den neste som feilsøker denne verten ellers gjentar den samme oppdagelsen fra null.