Twee SSID's, twee uitgangen: welk beleid wint waar?

Twee SSID's op één gateway lijken op twee netwerken en zijn dat niet, tot de gateway ze zo behandelt. De radio levert beide aan dezelfde bridge, tenzij het toegangspunt elk SSID aan zijn eigen VLAN koppelt. En zelfs met gescheiden interfaces volgt het verkeer de route en het firewallbeleid dat de gateway op die ingang toepast. Het SSID is een label; het beleid is wat u opschrijft.

Het SSID is niet het beleid

Noem de twee netwerken en schrijf hun beoogde uitgangen op voordat u de router aanraakt. Thuis gaat naar de gewone WAN, Werk gaat naar de VPN-interface, en geen van beide erft het pad van de andere. Als beide SSID's op één ongesegmenteerde bridge belanden, hebben de namen niets gecreëerd. Die platte bridge is de meest voorkomende manier waarop dit ontwerp stil faalt.

Het toegangspunt moet ze als afzonderlijke interfaces presenteren, getagd of apart gebrugd. Dat is een voorwaarde, geen detail. Schrijf de koppeling op vóór de eerste regel.

Classificeer op ingangsinterface

Classificeer op het punt waar het pakket de gateway binnenkomt. De ingangsinterface-selector in een beleidsregel staat los van een bronprefix, en dat is de eerlijke manier om te zeggen dat dit verkeer van Werk kwam. Alleen op het bronadres matchen laat een client op Werk een Thuis-adres opeisen en het pad van Thuis nemen.

ip rule show

Valideer de bron ook tegen de ingang, zodat de twee tests overeenkomen in plaats van elkaar tegen te spreken. Een regel die er maar één van controleert, is half beleid.

Houd de eigen tunnel van de gateway erbuiten

Houd de eigen buitenste VPN-verbinding van de gateway op de onderlaag die werkt. Een regel die voor doorgestuurde Werk-clients is geschreven, moet de tunnel die hen draagt niet recursief vangen, want dat is de klassieke manier om een lus te bouwen die alleen onder belasting verschijnt. Stel het lokale uitvoerpad vrij of beperk de regel tot doorgestuurd verkeer. Test het lusgeval met een grote overdracht, niet met één ping.

Vertaling vraagt dezelfde zorg. Als de VPN-uitgang het tunneladres van de gateway als bron vereist, pas dat dan alleen toe op Werk-bronnen die de VPN-interface verlaten. De gewone WAN-vertaling van Thuis is een ander bereik, en één onvoorwaardelijke masquerade-regel kan beide niet uitdrukken.

Schrijf beide regels naast elkaar, zodat het paar zichtbaar is als ontwerp en niet als twee losse regels. Een commentaar dat de bron en de beoogde uitgang noemt, is genoeg.

Bepaal de faaltoestand met opzet

Bepaal wat er gebeurt als de VPN-route verdwijnt. Voor een werknetwerk is het eerlijke antwoord meestal weigeren: geen terugval naar de gewone WAN, omdat het punt van het aparte SSID is dat het verkeer niet via het verkeerde pad naar buiten gaat. Automatisch opnieuw verbinden is een gemak, niet het blokkeerbeleid. Een weigeringsregel die nooit logt, is niet te onderscheiden van een kapot netwerk.

ip route show table work

Test een verse verbinding vanaf elk SSID, verwijder dan de tunnel en test opnieuw. Thuis zou zijn gewone pad moeten houden terwijl Werk gesloten faalt. Controleer IPv6 apart, want twee IPv4-subnetten zeggen daar niets over, en de beleidsregel-referentie documenteert de selectors die hierboven zijn gebruikt.