To nettverksporter, én VPN: hvorfor OpenVPN velger feil oppstrømsforbindelse

To oppstrømsforbindelser, én tunnel, og trafikken går ut gjennom den du ikke valgte. De private subnettene er tilgjengelige, loggen rapporterer en vellykket tilkobling, og det er den målte linjen som bærer den. Ingenting i OpenVPN-utdata nevner en port, fordi klienten aldri valgte en. Den åpnet en sockel mot en ekstern adresse og lot kjernen bestemme hvordan adressen nås.

Tunneladressen er ikke endepunktet

Det finnes to forskjellige veier i hver økt. Den ytre veien bærer den krypterte transporten til serverens offentlige adresse. Den indre veien bærer alt serveren skyver inn i tunnelen, og ruterregler for den ene påvirker ikke den andre.

remote-oppføringen i profilen navngir den ytre destinasjonen, så det er adressen som må festes. Det er også verdien som endres når et vertsnavn løses ut annerledes, eller profilen lister flere remote-oppføringer.

Finn adressen klienten faktisk ringte

Les den levende sockelen i stedet for konfigurasjonsfilen. Sockeltabellen viser peeren prosessen faktisk koblet til, og det er verdien en unntaksregel må treffe. En profil kan redigeres etter at økten har startet, og sockelen er det eneste beviset på hva som ble ringt:

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

Logglinjen navngir peer-adressen og porten på tilkoblingstidspunktet. Hvis den er uenig med profilen, skriver noe foran klienten om destinasjonen før tilkoblingen starter.

Sjekk adressefamilien også. En dual-stack-profil kan koble til over IPv6 mens unntaket ditt bare dekker IPv4, og da følger trafikken en annen regel enn den du skrev. Det samme gjelder en proxy som svarer på vegne av endepunktet. Begge tilfellene gir en tunnel som virker mens ruten din ikke gjør noe.

Fest endepunktet og les policyrekkefølgen

En vertsrute er mer spesifikk enn enhver standardrute. Derfor vinner en /32 for peer-adressen inne i tabellen som inneholder den. Den vanlige formen navngir porten og enheten eksplisitt:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Den ruten hjelper bare hvis oppslaget når den tabellen. Policyregler vurderes i rekkefølge, og den første treffet avgjør, så en regel som sender alt til en andre tabell, omgår vertsruten din i main. Les reglene før du antar at ruten er autoritativ:

ip rule show
ip route get 203.0.113.40

Spør det andre kommandoen med samme kildeadresse eller merke som klienten bruker når policyen avhenger av dem. Det rapporterer ruten kjernen ville valgt, noe som er bevis om oppslaget og ikke bevis for at den levende sockelen bruker den veien.

Når endepunktet flytter seg

Et vertsnavn som løses ut til flere adresser ugyldiggjør en permanent /32 så snart svaret endres. En profil med flere remote-linjer har samme problem, fordi klienten kan lande på hvilken som helst av dem. Oppdater ruten fra klientens egne livssykluskroker i stedet for å legge den til manuelt. Et up-skript som leser den forhandlede peeren og installerer vertsruten, holder unntaket i samsvar med virkeligheten, og et samsvarende down-skript fjerner den.

Registrer oppdateringen på samme sted som resten av vertens ruteringskonfigurasjon. En rute som bare finnes til neste omstart, er en test, ikke en rettelse.

Hold den indre policyen atskilt

Å flytte den ytre veien gir ikke tilgang til et nytt privat subnett, og det endrer ikke hvilke destinasjoner serveren skyver inn i tunnelen. Ruten på det nedre laget velger ledningen; de skyvede rutene velger hva som kommer inn i tunnelen. Å holde disse to beslutningene atskilt er det som gjør delingen forutsigbar.

Hvis målet bare er å holde den krypterte transporten unna en målt linje, la standardruten være og legg til det ene vertsunntaket. Å erstatte maskinens standardrute for å flytte én VPN-tilkobling ødelegger alle andre programmer på verten.

Bekreft resultatet med to uavhengige observasjoner: sockelens lokale adresse og enhet, og ruten den private destinasjonen løses ut til. Når begge stemmer med intensjonen din, er delingen reell. OpenVPN 2.6-håndboken dekker remote- og lokal bindingsalternativer som avgjør hvilken adresse klienten ringer.