LAN-clients negeren de router-VPN totdat policy-routing actief is

De router bereikt het internet via zijn tunnel, terwijl een laptop erachter nog steeds het ISP-adres meldt. Accept-regels toevoegen helpt niet, en die fout is leerzaam: filtering beantwoordt of een pakket mag passeren, niet waar het heen gaat. De interfacekeuze is al gemaakt door een routing-opzoeking die niets van je clientlijst weet. Repareer de opzoeking en de firewall is niet langer de verdachte.

Een filterregel kan geen interface kiezen

De pakketstroom op een Linux-router voert eerst de routingbeslissing uit en daarna de forward-hook. Tegen de tijd dat een regel overeenkomt met het uitgaande tunnelapparaat, heeft de kernel al besloten dat de tunnel de uitweg is. Als de hoofdtabel nog steeds de WAN-standaardroute verkiest, is het pakket op weg naar de ISP en ziet de accept-regel die je net schreef het nooit. Dat ene ordeningsfeit verklaart waarom een pagina vol nieuwe firewallregels niets verandert.

Het voorbeeld hieronder gebruikt een LAN van 192.168.8.0/24 op br-lan, een tunnelapparaat tun0 en een set-topbox op 192.168.8.23 die de tunnel moet gebruiken.

Lees de opzoeking voordat je regels bewerkt

Vraag de kernel een route te resolven namens die client. Het antwoord bevat het uitgaande apparaat en het bronadres dat gekozen zou worden, en dat is alles wat je nodig hebt om de diagnose te bevestigen. Als het antwoord het WAN-apparaat noemt, had het pakket nooit een kans je regel te bereiken.

ip -4 route get 198.51.100.7 from 192.168.8.23

Herhaal de query voor een client die op het gewone pad moet blijven. Wanneer beide antwoorden hetzelfde apparaat noemen, is er nog geen beleid per bron in het spel, en hoort de oplossing bij routing in plaats van filtering.

Koppel een tabel aan de clients die je wilt dekken

Policy-routing voegt een regelopzoeking in voor de hoofdtabel. Bouw een tabel waarvan de standaardroute de tunnel is en koppel die tabel dan aan een selector: een ingangsinterface, een bronadres of een firewallmarkering. Prioriteiten bepalen de volgorde, en de hoofdtabel staat ver onderaan de lijst op 32766, dus een regel met een laag nummer wordt eerst geraadpleegd. Interfaceselectors dekken elke client op de bridge; adresselectors dekken een machine.

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

Firmware-interfaces tonen meestal dezelfde objecten als een pagina voor policy-routing of VPN-beleid. Een apparaatlijst daar is eenvoudiger te onderhouden dan handgeschreven regels en overleeft meestal upgrades die de regelsyntaxis wijzigen.

Kies de selector bewust. Een interfaceregel is kort en toekomstvast, maar vangt ook het eigen beheerverkeer van de router dat op die bridge aankomt. Een bronregel is exact en moet worden bewerkt telkens als de apparaatlijst verandert. Schrijf de keuze op, want de volgende persoon die vraagt waarom een apparaat zich anders gedraagt, heeft die nodig.

Houd lokale bestemmingen buiten de tunnel

Een nieuwe tabel kent alleen de routes die je erin zet. Het LAN-prefix ontbreekt, dus printer- en NAS-verkeer zou de standaardroute van de tunnel volgen en verdwijnen. Een throw-route beëindigt de opzoeking in deze tabel en geeft de beslissing terug aan de hoofdtabel.

ip -4 route add throw 192.168.8.0/24 table 200

Sla die route over en lokale shares breken, en de beheersessie van de router zelf kan verdwijnen als de selector breder is dan bedoeld. Regel daarna de bronvraag: tunnelpakketten die nog LAN-adressen dragen hebben een andere kant nodig die een terugweg kent, terwijl masquerading op de tunnel die eis wegvalt en ook de clientidentiteit wegneemt die de andere kant zou zien.

Regels en routes die tijdens runtime worden toegevoegd, zijn weg na een herstart of firmware-update. Voeg ze toe aan het opstartmechanisme van de router, herstart een keer en test opnieuw vanaf de client: zijn publieke adres, een tweede client die op de WAN moet blijven en de tunneltellers tijdens een nieuwe verbinding.