Tar VPN-klienten bort din tillagda rutt? Använd en policytabell

En /24 för en laboratorioskrivare försvinner mellan två ip route show-anrop, och klientloggen säger bara att nätverket ändrades. Det var inget fel på kommandot, prefixet eller dina behörigheter. En företagsklient som äger värdens routingmodell befäster den modellen varje gång någon annan redigerar den, så posten du lade till tas bort som inkräktare. Att kämpa mot den i samma tabell är en förlorad position. Lösningen är att helt sluta tävla om den tabellen och lägga undantaget där övervakaren aldrig tittar.

Övervakaren förklarar den saknade rutten

Visa det innan du redesignar något: läs tabellen, lägg till prefixet, vänta några sekunder, läs igen. Om posten saknas och du inte skrev något för att ta bort den, är någon agent vakt. Hitta processen som äger det beteendet och läs dess journal kring ögonblicket då rutten försvinner, eftersom samma tjänst vanligtvis underhåller tunneln, paketfiltren och resolverkonfigurationen. Att döda den för att rutten ska stanna är ett byte du kommer att ångra vid nästa återanslutning.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

Prefixet och gränssnittet ovan är platshållare. Att kopiera ett gränssnittsnamn från ett fungerande exempel på en annan maskin är den vanligaste orsaken till att den här demonstrationen inte ger något alls.

En andra tabell är osynlig för övervakaren

Agenten bygger bara om tabellen den äger. Ge undantaget en egen tabell plus en regel som skickar matchande destinationer dit, och huvudtabellen ändras aldrig, så agenten har inget att rätta. Det är hela idén: ett namnrum med rutter som någon annan underhåller, och ett som bara du rör.

Bytet är underhåll. Två objekt kan glida isär, och regelns placering i listan betyder lika mycket som rutten i tabellen den väljer.

Bygg undantaget och låt det sedan vinna

Skapa tabellen, installera rutten och lägg till en regel som väljer tabellen för den destinationen. Prioriten avgör om din regel konsulteras före eller efter dem klienten lade in, och en regel som sorteras senare nås aldrig, så numret är en del av designen och inte dekoration. Fråga sedan kärnan vad den faktiskt skulle göra, vilket är en annan fråga än vad du konfigurerade.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get löser upp rutten som kärnan skulle använda, inklusive enheten och källadressen. Den skriver inte ut tabellidentifieraren, så para den med ip rule show när du behöver bekräfta vilken tabell som vann. Tillsammans svarar de på den enda frågan som betyder något: lämnar trafiken till den adressen där du tänkte?

Andra former av samma idé

Mönstret generaliseras när du slutar tänka i destinationer. Ett lokalt subnät kan förbli nåbart medan tunneln behåller standardrutten. Svar från en LAN-ansluten SSH-server kan gå ut via gränssnittet de kom in på i stället för att försvinna i tunneln. Och en gränssnittsbaserad regel kan knuffa in allt som kommer på ett trådlöst gränssnitt i tunneln, medan trafik som värden själv genererar stannar på Ethernet:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Det sista fallet matchar det inkommande gränssnittet i stället för destinationen, vilket är en annan regeltyp och en annan tankemodell. Vidarebefordrad trafik behöver också net.ipv4.ip_forward aktiverat, och den bortre änden måste routa källområdet tillbaka eller översätta det; en regel på en maskin skapar aldrig den andra halvan av vägen.

Behandla regeln som engångs

Regler och tabellrutter lever i minnet. Efter en återanslutning kan tunneleenheten byta namn, den tilldelade adressen kan flytta sig, och en regel med det gamla värdet slutar tyst att matcha. Tillämpa hela ändringen igen från ett enda skript som äger den, och kontrollera sedan ip rule show, aktuellt enhetsnamn och en färsk ip route get mot en verklig destination innan du litar på undantaget.

Två gränser överlever all omsorg. Klienten kontrollerar fortfarande sina egna filterregler och resolverkonfigurationen, och ett routingundantag åsidosätter ingen av dem. Om klienten också tar bort din policyregel är de stödda vägarna dess egen split-tunnelpolicy eller en klient som låter dig hantera rutter, som OpenConnect; att patcha en leverantörsbinär för att tysta dess övervakare är ett underhållsåtagande med en integritetskontroll bifogad.

Skriv tabellnumret, prioriteten och destinationen i en anteckning bredvid skriptet. Annars hittar nästa person en regel som övertrumfar tunneln och har inget sätt att veta varför.