Eerst de VLAN-gateway, dan de VPN-uitgangsbeslissing

Twee VLAN's hebben verschillende VPN-uitgangen nodig, en de eerste vraag is niet welk beleid je schrijft maar welk apparaat de standaardgateway beantwoordt. Als een switch tussen de VLAN's routeert, kan een firewallregel een pad beschrijven dat de pakketten nooit nemen. Loop de topologie door voordat je het uitgangsbeleid aanraakt.

Stap één: vind de gateway die elk VLAN gebruikt

Vraag elke client naar zijn gateway en vraag de switch welke interface het VLAN bezit. De standaardgateway bepaalt de eerste routingbeslissing voor verkeer dat het subnet verlaat, dus bepaalt ook welk apparaat beleid kan toepassen.

ip route show default
show ip interface brief

Twee samenhangende opstellingen komen veel voor. Ofwel de firewall bezit de VLAN-interfaces en routeert ertussen, ofwel de multilayer-switch bezit ze en routeert lokaal en stuurt alleen externe bestemmingen naar de firewall. Beide werken, en ze plaatsen het beleid op verschillende plekken.

Kies er bewust één, want een gemengde opstelling is hoe regels op het verkeerde apparaat belanden.

Stap twee: bepaal waar het lokale beleid woont

Als de switch tussen personeel en lab routeert, kan een firewallregel geen uitwisseling inspecteren die de firewall nooit bereikt. Het lokale beleid moet in de eigen toegangscontrole van de switch wonen, of het verkeer moet bewust via een inspectiepunt worden geleid.

De omgekeerde keuze heeft ook een prijs. De firewall de gateway maken voor elk VLAN zet lokaal gerouteerd verkeer in het capaciteits- en beschikbaarheidsplan van dat apparaat, zodat een herstart van de firewall een onderbreking tussen VLAN's wordt. Beoordeel de echte hardware in plaats van aan te nemen dat switches stateless zijn of firewalls traag. Capaciteitsplanning is eenvoudiger wanneer het apparaat dat je herstart niet ook het pad tussen twee drukke subnetten is.

Wat telt is of het gekozen beleid op het pad ligt dat de pakketten werkelijk volgen.

Stap drie: geef de twee apparaten één transit

Wanneer de switch routeert, houdt één transitsubnet de topologie leesbaar, in plaats van beide dozen als rivaliserende routers aan elk client-VLAN te hangen. De switch bezit de clientsubnetten en de firewall bezit de buitenkant.

# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1

De switch stuurt externe bestemmingen naar het transitadres van de firewall, en de firewall heeft retourroutes naar beide clientprefixen via de switch. Houd beheerstoegang, DHCP-gatewayinstellingen en VLAN-lidmaatschap intact tijdens de migratie, want die drie zijn wat een schone overstap in een middag met een consolekabel verandert.

Een transitontwerp maakt ook de volgende firewallvervanging een routingwijziging in plaats van een herbedradingsproject.

Stap vier: kies de uitgang op basis van de bron die aankomt

Met gewone routing en zonder brontranslatie ertussen ontvangt de firewall het oorspronkelijke personeels- of labadres op de transitinterface. Beide VLAN's komen over één link binnen, en hun IP-identiteiten overleven dat.

Druk de VPN-keuze uit met dat bronadres en de bedoelde bestemmingen op het werkelijke ingangspad. De regeldocumentatie van OPNsense onderscheidt een standaardgatewayinstelling, die systeemrouting volgt, van een expliciete gateway, die beleidsgebaseerde routing aanroept. Gebruik de expliciete vorm wanneer de keuze afhangt van waar het pakket vandaan kwam. Een normale standaardroute heeft geen enkele reden om naar de bron te kijken.

Houd lokale bestemmingen buiten een te brede uitgangsregel, en controleer het ondersteunde gatewaymodel voor de release die je draait.

Stap vijf: bewijs beide paden

Schrijf het resultaat als twee zinnen: personeelsverkeer naar goedgekeurde bestemmingen verlaat via uitgang A, en labverkeer naar goedgekeurde bestemmingen verlaat via uitgang B. Voeg de retourroutes, de translatieregels en het bedoelde gedrag toe wanneer een uitgang uitvalt.

traceroute -n 198.51.100.10

Test daarna een lokale dienst tussen VLAN's apart, want die oefent een andere beslissing in hetzelfde ontwerp.

Een verse stroom van elk VLAN, een werkende lokale dienst en een gedocumenteerd uitvalspad bewijzen samen het ontwerp; één geslaagde ping bewijst alleen dat er op dat moment één pad bestond.