Server eller klient: vilken OpenVPN-enhet på en Pi med dubbelroll

Två OpenVPN-processer kör på en Pi som både tar emot roaminganvändare och når en leverantör ovanför, och de delar nästan ingenting utöver hårdvaran. Den ena lyssnar efter inkommande tunnlar medan den andra ringer ut. Var och en läser sin egen katalog, och var och en har sitt eget felläge. Att starta om den felaktiga är det vanligaste sättet som en klientfix i stället välter lyssnaren.

Koppla enhetens namn till katalogen den laddar

Upstream 2.6 levererar två mall-enheter, [email protected] och [email protected]. Servermallen startar i /etc/openvpn/server och laddar %i.conf därifrån. Klientmallen startar i /etc/openvpn/client. En instans som heter roaming kan finnas på båda ställena samtidigt, som server och som klient, med två oberoende konfigurationer och ingen koppling mellan dem utöver strängen.

Fråga systemd i stället för filsystemet, eftersom paketbyggare lägger till extra filer som kan ändra arbetskatalogen eller de argument som binären tar emot.

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

Det första kommandot listar varje instansierad enhet, även de som misslyckades och blev kvar laddade. Det andra skriver ut enhetsfilen tillsammans med varje åsidosättning. Det tredje är det snabbaste sättet att se de två fakta som avgör frågan: katalogen som processen startar i, och konfigurationssökvägen den fick.

Avgör efter paketets riktning, inte efter gränssnittets namn

En serverinstans äger en lyssnande socket och accepterar anslutningar. Dess krypterade transport är lokal inmatning och lokal utmatning på Pi:n, medan trafiken den vidarebefordrar för användare följer vidarebefordringsvägen och svarar mot en annan regeluppsättning. En klientinstans har ingen lyssnare i den meningen: den ringer en peer, så dess krypterade transport är lokal utmatning mot underlaget.

Den skillnaden säger dig var en regel hör hemma. En regel som matchar ett gränssnitt inne i en vidarebefordringskedja tillåter bara trafik som routingen redan valt; den väljer aldrig vägen. När en roaminganvändares paket går ut genom fel väg är kedjan som ska undersökas forward, inte output.

Titta på sockets innan du teoretiserar. En server bunden till udp/1194 visar en lyssnande socket. Klienten visar en associering till leverantörens adress och ingenting som lyssnar.

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

Den ena instansens standardväg kan fånga den andras svar

En redirect-gateway som skjuts av klienten ovanför installerar en standardväg som konkurrerar med allt annat på maskinen, inklusive svaren som servern skickar till roaminganvändare. OpenVPN gör ett undantag för sin egen peer-adress så att tunneln förblir nåbar, men det undantaget säger ingenting om en telefon på ett hotellnätverk.

Symtomet är oftast asymmetriskt. Handskakningen slutförs, klienten rapporterar ansluten, och trafiken dör efter det första svarspaketet. Källbaserad policy-routing, eller ett paketmärke satt på serverinstansen med --mark, håller de två flödena åtskilda; ingen av dem är en fullständig regeluppsättning i sig, och båda behöver giltiga vägar i tabellen de väljer.

Testa det lokala beslutet i stället för tunnelns tillstånd, eftersom kärnan väljer källan och gränssnittet innan OpenVPN ser paketet.

ip route get 203.0.113.44
ip rule show

Starta om en roll och bevisa att den andra överlevde

Ordningen spelar roll när båda rollerna beror av samma underlag. Starta om klienten först om vägen ovanför måste finnas innan användartrafik kan vidarebefordras, och starta om servern först när du bara ändrar dess lyssnare eller dess pool. Bekräfta hur som helst båda enheterna efteråt, eftersom en misslyckad omstart kan lämna den andra rollen körande på inaktuellt tillstånd.

Skriv ner stoppvillkoret före ändringen: blockerar förlusten av tunneln ovanför roaminganvändare, eller faller den tillbaka på Pi:ns egen upplänk? DNS och IPv6 behöver också ett tydligt svar, eftersom en påskjuten resolver ofta lever längre än vägen som gjorde den användbar.

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

Acceptera ändringen bara när tre saker gäller samtidigt: en ny inkommande anslutning slutförs, en vidarebefordrad applikation når sitt mål genom den avsedda utgången, och båda processerna rapporterar fortfarande sin förväntade peer. Om en av de tre misslyckas har du ändrat fel instans eller fel väg, och nästa steg är att läsa enheten igen i stället för att starta om något annat.