Een aan het VPN-adres gebonden app gebruikt nog steeds de verkeerde route

Een applicatie bindt aan het adres van de VPN, en de verbinding verlaat het systeem toch via de gewone standaardroute. Aan de bind is niets mislukt; hij deed precies wat een bind doet. Een socket aan een lokaal adres binden kiest het bronadres dat de kernel in de header zet. Het installeert geen route en het maakt geen policyregel die pakketten met die bron in een bepaalde tunnel stuurt.

De rest van deze runbook is de controleorde die ik gebruik, met het commando dat elke observatie oplevert.

Wat een bind werkelijk bepaalt

Een bind wijst een lokaal adres toe aan de socket. Daarna voert de kernel dezelfde route-opzoeking uit die hij anders ook zou hebben uitgevoerd, tenzij een policyregel verandert welke tabel die opzoeking leest.

Daarom kan een pakket met een VPN-bronadres op een fysieke interface naar buiten gaan. Aan de andere kant komt het uit een privaat bereik dat het netwerk op dat pad nooit had verwacht, het retourverkeer heeft geen route terug, en de verbinding blijft hangen of wordt gereset.

De Linux-referentie voor IP-sockets documenteert de semantiek van bind. De routeringshelft woont in ip-rule en ip-route, en dat zijn om een reden aparte handleidingen.

Bevestig dat het adres bij deze namespace hoort

Een adres waaraan u kunt binden, moet bestaan op een interface binnen de netwerknamespace waarin de applicatie draait. Een peeradres, een gatewayadres of een adres dat alleen in een andere namespace bestaat, is niet bindbaar, en de aanroep mislukt met EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Voer die drie uit in dezelfde context als de applicatie: dezelfde namespace en, als u die kunt krijgen, dezelfde gebruiker. Een oud net30-diagram is geen bewijs van welk adres uw huidige topologie aan de client heeft toegewezen. Lees de interface die werkelijk actief is.

Lees de opzoeking voor die bron en bestemming

Eén commando beantwoordt de vraag die de bind niet beantwoordde:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

De eerste regel drukt de route af die een pakket van die bron naar die bestemming zou nemen, inclusief de uitgaande interface en de voorkeursbron. Als die de fysieke interface noemt, zijn bind en route het oneens, en het pakket gaat naar buiten met een bron waar het pad niet naar terug kan.

Daarna vertelt ip rule show of een regel een andere tabel zou hebben gekozen. Prioriteiten tellen hier, want de eerste overeenkomende regel wint, en een regel die alles boven de uwe vangt, maakt uw regel onzichtbaar.

Installeer alleen een policyregel als dat het ontwerp is

Routering op basis van bron is een bewust ontwerp, geen reparatie voor één applicatie. Wil de policy-eigenaar dat verkeer uit het tunnelsubnet de tunnel gebruikt, dan hoort de regel in diens configuratie en niet in een eenmalig commando op uw laptop.

Een werkbare vorm is een eigen tabel met een standaardroute door de tunnel, plus een regel die het VPN-bronbereik naar die tabel stuurt. Voeg de uitzonderingen toe die het ontwerp nodig heeft, want een tabel met alleen een tunnelstandaard vangt bestemmingen die lokaal moeten blijven of via het fysieke pad bereikbaar moeten zijn.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Draai het terug met ip rule del en ip route flush table 100. Alles wat zo wordt toegevoegd, verdwijnt bij een herstart tenzij een beheerder het schrijft, wat zowel een veiligheidseigenschap is als een reden om niet de enige kopie in uw shellgeschiedenis te bewaren.

Verifieer met drie observaties

Noteer de bron die de applicatie vroeg, de route die de opzoeking koos, en de bron die de server werkelijk zag.

Die drie kunnen het oneens zijn, en elk verschil wijst ergens anders heen. Een opname op de tunnelinterface bewijst dat het pakket met de juiste bron naar buiten ging. Een opname op de fysieke interface bewijst dat het de verkeerde weg nam. Alleen de weergave aan serverzijde bewijst het pad van begin tot eind.

Biedt de applicatie een bind-aan-apparaatoptie of een routeringsmodus per applicatie, behandel die dan als een ander mechanisme met andere beperkingen. Vergelijkbaar uitziende instellingen leiden niet allemaal tot dezelfde kernelbeslissing.