Två nätverksportar, en VPN: varför OpenVPN väljer fel uppströmslänk

Två uppströmslänkar, en tunnel, och trafiken går ut via den du inte valde. De privata subnäten är nåbara, loggen rapporterar en lyckad anslutning, och det är den mätta länken som bär den. Inget i OpenVPN-utdata nämner en port, eftersom klienten aldrig valde någon. Den öppnade en socket mot en fjärradress och lät kärnan avgöra hur adressen nås.

Tunneladressen är inte slutpunkten

I varje session finns två olika vägar. Den yttre vägen bär den krypterade transporten till serverns publika adress. Den inre vägen bär allt servern skjuter in i tunneln, och rutteregler för den ena påverkar inte den andra.

remote-posten i profilen namnger den yttre destinationen, så det är adressen som ska fästas. Det är också värdet som ändras när ett värdnamn löses ut annorlunda eller profilen listar flera remote-poster.

Hitta adressen klienten faktiskt ringde

Läs den levande socketen i stället för konfigurationsfilen. Sockettabellen visar peeren som processen faktiskt anslöt till, och det är värdet som ett undantag måste träffa. En profil kan redigeras efter att sessionen börjat, och socketen är det enda beviset på vad som ringdes:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Loggrader anger peeradressen och porten vid anslutningstillfället. Om den inte stämmer med profilen skriver något framför klienten om destinationen innan anslutningen börjar.

Kontrollera även adressfamiljen. En dual-stack-profil kan ansluta via IPv6 medan ditt undantag bara täcker IPv4, och då följer trafiken en annan regel än den du skrev. Samma sak gäller en proxy som svarar åt slutpunkten. Båda fallen ger en tunnel som fungerar medan din rutt inte gör något.

Fäst slutpunkten och läs policyordningen

En värdrutt är mer specifik än vilken standardrutt som helst. Därför vinner en /32 för peeradressen i tabellen som innehåller den. Den vanliga formen namnger porten och enheten uttryckligen:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Den rutten hjälper bara om sökningen når den tabellen. Policyregler utvärderas i ordning och den första träffen avgör, så en regel som skickar allt till en andra tabell kringgår din värdrutt i main. Läs reglerna innan du antar att rutten är auktoritativ:

ip rule show
ip route get 203.0.113.40

Fråga det andra kommandot med samma källadress eller markering som klienten använder när policyn beror på dem. Det rapporterar rutten som kärnan skulle välja, vilket är bevis om sökningen och inte bevis för att den levande socketen använder den vägen.

När slutpunkten flyttar sig

Ett värdnamn som löses ut till flera adresser ogiltigförklarar en permanent /32 så snart svaret ändras. En profil med flera remote-rader har samma problem, eftersom klienten kan landa på vilken som helst av dem. Uppdatera rutten från klientens egna livscykelhooks i stället för att lägga till den manuellt. Ett up-skript som läser den förhandlade peeren och installerar värdrutten håller undantaget i linje med verkligheten, och ett matchande down-skript tar bort den.

Registrera uppdateringen på samma ställe som resten av värdens routingkonfiguration. En rutt som bara finns till nästa omstart är ett test, inte en rättelse.

Håll den inre policyn åtskild

Att flytta den yttre vägen ger inte åtkomst till ett nytt privat subnät, och det ändrar inte vilka destinationer servern skjuter in i tunneln. Rutten i det nedre lagret väljer ledningen; de skjutna rutterna väljer vad som kommer in i tunneln. Att hålla dessa två beslut åtskilda är det som gör delningen förutsägbar.

Om målet bara är att hålla den krypterade transporten borta från en mätt länk, låt standardrutten vara och lägg till det enda värdunndantaget. Att ersätta maskinens standardrutt för att flytta en enda VPN-anslutning förstör alla andra program på värden.

Bekräfta resultatet med två oberoende observationer: socketens lokala adress och enhet, och rutten som den privata destinationen löses ut till. När båda stämmer med din avsikt är delningen verklig. OpenVPN 2.6-handboken täcker alternativen för remote och lokal bindning som avgör vilken adress klienten ringer.