VLAN-gateway fyrst, deretter avgjerda om VPN-utgang

To VLAN treng ulike VPN-utgangar, og det første spørsmålet er ikkje kva politikk som skal skrivast, men kva eining som svarar på standardgatewayen. Viss ein switch rutar mellom VLAN-a, kan ei brannmurregel skildre ein veg pakkane aldri tek. Gå gjennom topologien før du rører utgangspolitikken.

Steg ein: finn gatewayen kvart VLAN brukar

Spør kvar klient om gatewayen, og spør switchen kva grensesnitt som eig VLAN-et. Standardgatewayen avgjer den første rutingsavgjerda for trafikk som forlèt subnettet, og avgjer difor òg kva eining som kan bruke ein politikk.

ip route show default
show ip interface brief

To samanhengande oppsett er vanlege. Anten eig brannmuren VLAN-grensesnitta og rutar mellom dei, eller fleirlags-switchen eig dei og rutar lokalt og sender berre eksterne mål til brannmuren. Begge fungerer, og dei plasserer politikken på ulike stader.

Vel eitt med vilje, fordi eit blanda oppsett er måten reglar hamnar på feil eining.

Steg to: avgjer kvar den lokale politikken bur

Viss switchen rutar mellom tilsette og laboratoriet, kan ei brannmurregel ikkje inspisere ei utveksling som aldri når brannmuren. Den lokale politikken må bu i switchen sine eigne tilgangskontrollar, eller trafikken må styrast med vilje gjennom eit inspeksjonspunkt.

Det motsette valet har òg ein kostnad. Å gjere brannmuren til gateway for kvart VLAN legg lokal ruta trafikk inn i kapasitets- og tilgjengeplanen til den eininga, slik at ein omstart av brannmuren blir eit avbrot mellom VLAN. Vurder den faktiske maskinvara i staden for å anta at switchar er tilstandslause eller at brannmurar er trege. Kapasitetsplanlegging er enklare når eininga du startar på nytt ikkje òg er vegen mellom to travle subnett.

Det som tel, er om den valde politikken ligg på vegen pakkane faktisk følgjer.

Steg tre: gi dei to einingane éin transit

Når switchen rutar, held eitt enkelt transittsubnett topologien lesbar, i staden for å henge begge boksane på kvart klient-VLAN som konkurrerande rutarar. Switchen eig klientsubnetta, og brannmuren eig utsida.

# 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 transitadressa til brannmuren, og brannmuren har returruter til begge klientprefiksa gjennom switchen. Hald administrasjonstilgang, DHCP-gatewayinnstillingar og VLAN-medlemskap intakte under migreringa, fordi dei tre er det som gjer ein rein overgang til ein ettermiddag med konsollkabel.

Eit transitdesign gjer òg neste brannmurbyte til ei rutingsendring i staden for eit omkoblingsprosjekt.

Steg fire: vel utgangen ut frå kjelda som kjem

Med vanleg ruting og inga kjeldeomsetjing imellom tek brannmuren imot den opphavlege tilsett- eller laboratorieadressa på transitgrensesnittet. Begge VLAN kjem over éi lenkje, og IP-identitetane deira overlever det.

Uttrykk VPN-valet med den kjeldadressa og dei tiltenkte måla på den faktiske inngangsvegen. OPNsense si regeldokumentasjon skil mellom ei standardgatewayinnstilling, som følgjer systemrutinga, og ein eksplisitt gateway, som kallar på politikkbasert ruting. Bruk den eksplisitte forma når valet avheng av kvar pakken kom frå. Ei vanleg standardrute har ingen grunn til å sjå på kjelda i det heile.

Hald lokale mål utanfor ein altfor brei utgangsregel, og kontroller den støtta gatewaymodellen for versjonen du køyrer.

Steg fem: bevis begge vegar

Skriv resultatet som to setningar: trafikken til dei tilsette til godkjende mål forlèt gjennom utgang A, og trafikken til laboratoriet til godkjende mål forlèt gjennom utgang B. Legg til returrutene, omsetjingsreglane og den tiltenkte åtferda når ein utgang er nede.

traceroute -n 198.51.100.10

Test deretter ein lokal teneste mellom VLAN separat, fordi ho øver på ei anna avgjerd i same design.

Ein fersk straum frå kvart VLAN, ein fungerande lokal teneste og ein dokumentert feilveg beviser saman designet; ein einaste vellukka ping beviser berre at det fanst éin veg i det augneblinken.