VLAN-gatewayen først, så valget av VPN-utgang
Enheten som har standardgatewayen bestemmer hvor utgangspolicyen kan gjelde. Send begge VLAN gjennom én transit og velg utgang etter kilde.
To VLAN trenger forskjellige VPN-utganger, og det første spørsmålet er ikke hvilken policy som skal skrives, men hvilken enhet som svarer på standardgatewayen. Dersom en switch ruter mellom VLANene, kan en brannmurregel beskrive en vei pakkene aldri tar. Gå gjennom topologien før du tar i utgangspolicyen.
Steg én: finn gatewayen som hvert VLAN bruker
Spør hver klient om gatewayen sin, og spør switchen hvilket grensesnitt som eier VLANet. Standardgatewayen bestemmer den første rutingsbeslutningen for trafikk som forlater subnettet, og bestemmer dermed også hvilken enhet som kan bruke en policy.
ip route show default
show ip interface brief
To sammenhengende oppsett er vanlige. Enten eier brannmuren VLAN-grensesnittene og ruter mellom dem, eller flernivåswitchen eier dem og ruter lokalt og sender bare eksterne mål til brannmuren. Begge virker, og de plasserer policyen på forskjellige steder.
Velg ett med vilje, fordi et blandet oppsett er måten regler havner på feil enhet.
Steg to: bestem hvor den lokale policyen bor
Hvis switchen ruter mellom ansatte og laboratoriet, kan en brannmurregel ikke inspisere en utveksling som aldri når brannmuren. Den lokale policyen må bo i switchens egne tilgangskontroller, eller trafikken må styres bevisst gjennom et inspeksjonspunkt.
Det motsatte valget har også en kostnad. Å gjøre brannmuren til gateway for hvert VLAN legger lokalt rutet trafikk inn i kapasitets- og tilgjengelighetsplanen til den enheten, slik at en omstart av brannmuren blir et avbrudd mellom VLAN. Vurder den faktiske maskinvaren i stedet for å anta at svitsjer er tilstandsløse eller at brannmurer er trege. Kapasitetsplanlegging er enklere når enheten du starter på nytt ikke også er veien mellom to travle subnett.
Det som betyr noe, er om den valgte policyen ligger på veien pakkene faktisk følger.
Steg tre: gi de to enhetene én transit
Når switchen ruter, holder ett enkelt transittsubnett topologien lesbar, i stedet for å henge begge boksene på hvert klient-VLAN som konkurrerende rutere. Switchen eier klientsubnettene, og brannmuren eier utsiden.
# 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
Switchen sender eksterne mål til transitadressen til brannmuren, og brannmuren har returruter til begge klientprefiksene gjennom switchen. Hold administrasjonstilgang, DHCP-gatewayinnstillinger og VLAN-medlemskap intakte under migreringen, fordi de tre er det som gjør en ren overgang til en ettermiddag med konsollkabel.
Et transitdesign gjør også neste brannmurbytte til en rutingsendring i stedet for et omkoblingsprosjekt.
Steg fire: velg utgangen ut fra kilden som kommer
Med vanlig ruting og ingen kildeoversettelse imellom mottar brannmuren den opprinnelige ansatt- eller laboratorieadressen på transitgrensesnittet. Begge VLAN kommer over én lenke, og IP-identitetene deres overlever det.
Uttrykk VPN-valget med den kildeadressen og de tiltenkte målene på den faktiske inngangsveien. OPNsense sin regeldokumentasjon skiller mellom en standardgatewayinnstilling, som følger systemrutingen, og en eksplisitt gateway, som påkaller policybasert ruting. Bruk den eksplisitte formen når valget avhenger av hvor pakken kom fra. En vanlig standardrute har ingen grunn til å se på kilden i det hele tatt.
Hold lokale mål utenfor en altfor bred utgangsregel, og kontroller den støttede gatewaymodellen for versjonen du kjører.
Steg fem: bevis begge veier
Skriv resultatet som to setninger: ansattes trafikk til godkjente mål forlater gjennom utgang A, og laboratoriets trafikk til godkjente mål forlater gjennom utgang B. Legg til returrutene, oversettelsesreglene og den tiltenkte oppførselen når en utgang er nede.
traceroute -n 198.51.100.10
Test deretter en lokal tjeneste mellom VLAN separat, fordi den øver på en annen beslutning i samme design.
En fersk strøm fra hvert VLAN, en fungerende lokal tjeneste og en dokumentert feilvei beviser sammen designet; én enkelt vellykket ping beviser bare at én vei fantes i det øyeblikket.