En Pi, två OpenVPN-instanser: vad varje enhet läser
Två OpenVPN-demoner på en Pi läser olika konfigurationsfiler och går ut genom olika krokar. Kartlägg varje instans och testa sedan nyttolastvägen separat.
Räkna OpenVPN-processerna innan du rör en profil. En Pi som tar emot roaminganvändare och samtidigt ringer upp en uppströmstjänst kör två demoner, och var och en läser en konfigurationsfil som väljs av instansnamnet du skrev in. Paketets mallar ger sedan varje demon sin egen arbetskatalog, sin egen körtidsstatusfil och sin egen tunnelenhet. Gör du den här delningen fel kommer du att tillbringa en kväll med att ändra en korrekt inställning i en fil som den körande processen aldrig öppnar.
Varje instansnamn väljer sin egen fil
I de enhetsfiler som följer med OpenVPN 2.6 bär startargumenten en instansplatshållare som fylls i från texten efter @-tecknet. Servermallen körs från serverns konfigurationskatalog och löser sitt argument mot %i.conf där, medan klientmallen gör samma sak från klientkatalogen. Så [email protected] läser admits.conf i serverkatalogen och [email protected] läser uplink.conf i klientkatalogen, och inget av namnen har någon betydelse i den andra katalogen.
Bekräfta mappningen på maskinen i stället för att anta att paketet har behållit uppströms standardvärden. En drop-in från distributionen får ersätta arbetskatalogen eller konfigurationsargumentet helt.
systemctl cat [email protected]
systemctl cat [email protected]Läs WorkingDirectory-raden och konfigurationsargumentet i den utdatan, eftersom den aktiverade enheten är det enda som avgör vilken fil som laddas. En drop-in som lägger till --config i ExecStart vinner över mallen även när mallens sökväg ser rätt ut. Fråga efter fragment- och drop-in-sökvägarna när du vill veta om ett lokalt åsidosättande är i spel. Om båda rollerna löses till en enda fil har du en enda process som försöker vara både server och klient, och det senare alternativet i den filen vinner i tysthet.
Lokal transport och vidarebefordrad nyttolast träffar olika krokar
Serverns krypterade anslutning till varje roaminganvändare genereras på Pi:n själv, så de yttre svaren går ut genom den lokala utdatakroken. Klientens anslutning till sin uppströmspartner är också lokalt genererad utdata, även om den når ett avlägset nätverk. Vidarebefordrad nyttolast är den tredje kategorin, och kärnan matchar den först efter att den redan har valt en utgående enhet för paketet.
| 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 matchar ett utgående gränssnitt inne i en forward-kedja kan tillåta eller kasta ett paket som routingen redan har tilldelat det gränssnittet, men den väljer aldrig gränssnittet. När en värd avslutar en tunnel och startar en annan är policyn som skickar användarnas nyttolast in i uppströmstunneln och policyn som skyddar Pi:ns egna krypterade svar två separata beslut. De hamnar slumpmässigt på samma fysiska NIC, vilket är varför de blandas ihop.
Den skillnaden förklarar ett vanligt halvfel. Användarna ansluter, handskakningen slutförs och deras trafik går ändå ut fel väg, eftersom handskakningen var lokal och nyttolasten var forward och bara en av de två någonsin testades.
En importerad rutt kan svälja svaren till dina användare
Klientprofilens säkerhetsinställning avgör vad uppströmmen får trycka in i Pi:ns routingtabell, och en bred omdirigering är alternativet som förvandlar en fungerande värd med dubbel roll till en trasig. Om den intryckta rutten täcker roaminganvändarnas offentliga adresser kan svaren som servern genererar mot dem följa den nya rutten in i uppströmstunneln i stället för att gå ut via underlaget. Folk bekräftar ofta att tunneln till leverantören fortfarande fungerar och stannar där, eftersom den trafiken är tunnelns egen transport och fortsätter att flöda medan allt annat beter sig fel.
Policy baserad på källa eller mark är sättet att hålla de två strömmarna åtskilda. OpenVPN:s Linux-mark-alternativ stämplar demonens egna krypterade paket med en brandväggsmark, som en routingregel sedan kan skicka till en dedikerad tabell. Källadresser fungerar lika bra när serverns yttre svar alltid går ut från en enda underlagsadress. Båda angreppssätten kräver giltiga rutter i tabellen den väljer och ett undantag för leverantörens endpoint, annars kommer inte själva tunneln upp.
Fråga kärnan vilken väg ett svar faktiskt skulle ta innan du skriver någon regel. Adresserna nedan är platshållare för en underlagsadress på Pi:n och den offentliga adressen för en roaminganvändare.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Verifiera delningen och stoppa sedan en roll i taget
Testa tre strömmar var för sig, eftersom en fungerande handskakning inte bevisar något om de andra två. Acceptera en ny inkommande anslutning, skicka en tillåten applikation via uppströmsutgången och bekräfta att båda processerna fortfarande når sina egna partners.
Stoppa sedan klientrollen och se vad serverrollen behåller. Det är det billigaste sättet att hitta en rutt- eller markregel som var avsedd för en instans och tillämpades på båda.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerDet du vill se är att lyssnaren fortfarande är bunden, att tunnelenheten fortfarande finns och att loggen är fri från nya fel medan klientrollen är nere. Om stoppandet av klienten också bryter serverns svar till befintliga användare delar de två rollerna något som borde ha begränsats till en av dem. Anteckna vilken instans, vilken konfigurationsfil och vilken strömägare varje ändring rörde, för annars upprepar nästa person som felsöker den här värden samma upptäckt från noll.