To netværksbroer, ét VPN: hvorfor OpenVPN vælger den forkerte forbindelse opad
Tunnelen er fin; socketten forlader netværket via den forkerte WAN. Læs den aktive peer-adresse, fastgør en værtsrute, og kontrollér først politikreglerne.
To forbindelser opad, en tunnel, og trafikken forlader via den, du ikke valgte. De private undernet er tilgængelige, loggen rapporterer en vellykket forbindelse, og det er den målbetalte linje, der bærer den. Intet i OpenVPN's output nævner en netværksbro, fordi klienten aldrig valgte en. Den åbnede en socket til en fjernadresse og lod kernen bestemme, hvordan den adresse nås.
Tunneladressen er ikke endepunktet
Der findes to forskellige veje i hver session. Den ydre vej bærer den krypterede transport til serverens offentlige adresse. Den indre vej bærer alt, hvad serveren skubber ind i tunnelen, og ruteregler for den ene har ingen virkning på den anden.
remote-posten i profilen angiver den ydre destination, så det er den adresse, der skal fastgøres. Det er også den værdi, der ændres, når et værtsnavn opløses anderledes, eller profilen lister flere remote.
Find den adresse, klienten faktisk ringede op til
Læs den levende socket i stedet for konfigurationsfilen. Sockettabellen viser den peer, processen faktisk oprettede forbindelse til, og det er den værdi, en undtagelse skal matche. En profil kan redigeres, efter sessionen er startet, og socketten er det eneste bevis på, hvad der blev ringet op til:
ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"
Loglinjen angiver peer-adressen og porten på forbindelsestidspunktet. Hvis den er uenig med profilen, omskriver noget foran klienten destinationen, før forbindelsen starter.
Kontrollér også adressefamilien. En dual-stack-profil kan forbinde over IPv6, mens din undtagelse kun dækker IPv4, og så følger trafikken en anden regel end den, du skrev. Det samme gælder en proxy, der svarer på vegne af endepunktet. Begge tilfælde giver en tunnel, der virker, mens din rute intet gør.
Fastgør endepunktet og læs politikrækkefølgen
En værtsrute er mere specifik end enhver standardrute. Derfor vinder en /32 for peer-adressen inde i den tabel, der indeholder den. Den sædvanlige form angiver netværksbroen og enheden eksplicit:
ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0
Den rute hjælper kun, hvis opslaget når den tabel. Politikregler evalueres i rækkefølge, og det første match afgør, så en regel, der sender alt til en anden tabel, omgår din værtsrute i main. Læs reglerne, før du antager, at ruten er autoritativ:
ip rule show
ip route get 203.0.113.40
Spørg det andet kommando med den samme kildeadresse eller markering, som klienten bruger, når politikken afhænger af dem. Den rapporterer den rute, kernen ville vælge, hvilket er bevis om opslaget og ikke bevis for, at den levende socket bruger den vej.
Når endepunktet flytter sig
Et værtsnavn, der opløses til flere adresser, ugyldiggør en permanent /32, så snart svaret ændres. En profil med flere remote-linjer har samme problem, fordi klienten kan lande på enhver af dem. Opdatér ruten fra klientens egne livscykluskroge i stedet for at tilføje den manuelt. Et up-script, der læser den forhandlede peer og installerer værtsruten, holder undtagelsen i overensstemmelse med virkeligheden, og et matchende down-script fjerner den.
Registrér opdateringen samme sted som resten af værtens rutekonfiguration. En rute, der kun findes indtil næste genstart, er en test, ikke en rettelse.
Hold den indre politik adskilt
At flytte den ydre vej giver ikke adgang til et nyt privat undernet og ændrer ikke, hvilke destinationer serveren skubber ind i tunnelen. Underlagsruten vælger ledningen; de skubbede ruter vælger, hvad der kommer ind i tunnelen. At holde de to beslutninger adskilt er det, der gør opdelingen forudsigelig.
Hvis målet kun er at holde den krypterede transport væk fra en målbelt linje, så lad standardruten være og tilføj den enkelte værtsundtagelse. At erstatte maskinens standardrute for at flytte én VPN-forbindelse ødelægger enhver anden applikation på værten.
Bekræft resultatet med to uafhængige observationer: socketens lokale adresse og enhed, og den rute, som den private destination opløses til. Når begge matcher din hensigt, er opdelingen reel. OpenVPN 2.6-manualen dækker remote- og lokale bindingindstillinger, som afgør, hvilken adresse klienten ringer op til.