LAN-klienter ignorerar routerns VPN tills policy-routing aktiveras

Routern når internet via sin tunnel medan en bärbar dator bakom den fortfarande rapporterar ISP-adressen. Att lägga till accept-regler hjälper inte, och det misslyckandet är upplysande: filtrering svarar på om ett paket får passera, inte vart det tar vägen. Gränssnittsvalet har redan gjorts av en routinguppslagning som inte vet något om din klientlista. Rätta uppslagningen och brandväggen är inte längre den misstänkta.

En filterregel kan inte välja ett gränssnitt

Paketflödet på en Linux-router kör routingbeslutet först och forward-kroken efteråt. När en regel matchar den utgående tunnelenheten har kärnan redan beslutat att tunneln är vägen ut. Om huvudtabellen fortfarande föredrar WAN-standardrutten är paketet på väg till ISP:n, och accept-regeln du just skrev ser det aldrig. Det enda ordningsfaktumet förklarar varför en sida nya brandväggsregler inte ändrar något.

Exemplet nedan använder ett LAN på 192.168.8.0/24 på br-lan, en tunnelenhet tun0 och en set-top-box på 192.168.8.23 som bör använda tunneln.

Läs uppslagningen innan du redigerar regler

Be kärnan lösa upp en rutt för den klientens räkning. Svaret innehåller den utgående enheten och källadressen som skulle väljas, och det är allt du behöver för att bekräfta diagnosen. Om svaret namnger WAN-enheten hade paketet aldrig en chans att nå din regel.

ip -4 route get 198.51.100.7 from 192.168.8.23

Upprepa frågan för en klient som bör stanna på den vanliga vägen. När båda svaren namnger samma enhet finns ingen källbaserad policy på plats ännu, och rättelsen hör till routing snarare än filtrering.

Knyt en tabell till de klienter du vill täcka

Policy-routing infogar en regeluppslagning före huvudtabellen. Bygg en tabell vars standardrutt är tunneln och knyt sedan tabellen till en väljare: ett ingångsgränssnitt, en källadress eller en brandväggsmarkering. Prioriteterna avgör ordningen, och huvudtabellen ligger långt ner i listan på 32766, så en regel med lågt nummer konsulteras först. Gränssnittsväljare täcker varje klient på bryggan; adressväljare täcker en maskin.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Firmware-gränssnitt visar oftast samma objekt som en sida för policy-routing eller VPN-policy. En enhetslista där är lättare att underhålla än handskrivna regler och överlever oftast uppgraderingar som ändrar reglernas syntax.

Välj väljaren med avsikt. En gränssnittsregel är kort och framtidssäker men fångar också routerns egen administrationstrafik som anländer på den bryggan. En källregel är exakt och kräver redigering varje gång enhetslistan ändras. Skriv ner valet, för nästa person som frågar varför en enhet beter sig annorlunda kommer att behöva det.

Håll lokala mål utanför tunneln

En ny tabell känner bara till de rutter du lägger i den. LAN-prefixet saknas, så skrivar- och NAS-trafik skulle följa tunnelns standardrutt och försvinna. En throw-rutt avslutar uppslagningen i den här tabellen och ger beslutet tillbaka till huvudtabellen.

ip -4 route add throw 192.168.8.0/24 table 200

Hoppar du över den rutten bryts lokala delningar, och routerns egen administrationssession kan försvinna om väljaren är bredare än avsett. Lös sedan källfrågan: tunnelpaket som fortfarande bär LAN-adresser behöver att andra sidan känner till en returväg, medan masquerading på tunneln tar bort det kravet och även tar bort den klientidentitet som andra sidan skulle se.

Regler och rutter som läggs till under drift försvinner efter en omstart eller en firmwareuppdatering. Lägg dem i routerns uppstartsmekanism, starta om en gång och testa igen från klienten: dess offentliga adress, en andra klient som bör stanna på WAN och tunnelns räknare under en ny anslutning.