VLAN-gateway først, derefter beslutningen om VPN-udgang

To VLAN'er har brug for forskellige VPN-udgange, og det første spørgsmål er ikke, hvilken politik der skal skrives, men hvilken enhed der svarer på standardgatewayen. Hvis en switch router mellem VLAN'erne, kan en firewallregel beskrive en vej, som pakkerne aldrig tager. Gennemgå topologien, før du rører udgangspolitikken.

Trin et: find den gateway, hver VLAN bruger

Spørg hver klient om dens gateway, og spørg switchen, hvilket interface der ejer VLAN'et. Standardgatewayen bestemmer den første routingbeslutning for trafik, der forlader undernettet, så den bestemmer også, hvilken enhed der kan anvende en politik.

ip route show default
show ip interface brief

To sammenhængende layouts er almindelige. Enten ejer firewallen VLAN-interfacerne og router mellem dem, eller den flerlagsswitch ejer dem og router lokalt og sender kun eksterne destinationer til firewallen. Begge virker, og de placerer politikken forskellige steder.

Vælg én med vilje, fordi et blandet layout er måden, hvorpå regler ender på den forkerte enhed.

Trin to: beslut, hvor den lokale politik bor

Hvis switchen router mellem personalet og laboratoriet, kan en firewallregel ikke inspicere en udveksling, der aldrig når firewallen. Den lokale politik skal bo i switchens egne adgangskontroller, eller trafikken skal bevidst styres gennem et inspektionspunkt.

Det omvendte valg har også en pris. At gøre firewallen til gateway for hver VLAN lægger lokal routet trafik ind i den enheds kapacitets- og tilgængelighedsplan, så en genstart af firewallen bliver et afbrud mellem VLAN'er. Vurder den faktiske hardware i stedet for at antage, at switches er tilstandsløse, eller at firewalls er langsomme. Kapacitetsplanlægning er lettere, når den enhed, du genstarter, ikke også er vejen mellem to travle undernet.

Det afgørende er, om den valgte politik ligger på den vej, pakkerne faktisk følger.

Trin tre: giv de to enheder én transit

Når switchen router, holder et enkelt transit-undernet topologien læsbar i stedet for at hænge begge bokse på hver klient-VLAN som rivaliserende routere. Switchen ejer klientundernettene, og firewallen ejer ydersiden.

# 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 destinationer til firewallens transitadresse, og firewallen har returruter til begge klientpræfikser gennem switchen. Hold administrationsadgang, DHCP-gatewayindstillinger og VLAN-medlemskab intakte under migreringen, fordi de tre er det, der gør et rent skift til en eftermiddag med et konsolkabel.

Et transitdesign gør også den næste udskiftning af firewallen til en routingændring i stedet for et omkablingsprojekt.

Trin fire: vælg udgangen ud fra den kilde, der ankommer

Med almindelig routing og ingen kildeoversættelse imellem modtager firewallen den oprindelige personale- eller laboratorieadresse på transitinterfacet. Begge VLAN'er ankommer over ét link, og deres IP-identiteter overlever det.

Udtryk VPN-valget med den kildeadresse og de tilsigtede destinationer på den faktiske indgangsvej. OPNsense's regeldokumentation skelner mellem en standardgatewayindstilling, der følger systemrouting, og en eksplicit gateway, der aktiverer politikbaseret routing. Brug den eksplicitte form, når valget afhænger af, hvor pakken kom fra. En normal standardrute har ingen grund til at se på kilden.

Hold lokale destinationer uden for en alt for bred udgangsregel, og kontroller den understøttede gatewaymodel for den version, du kører.

Trin fem: bevis begge veje

Skriv resultatet som to sætninger: personalets trafik til godkendte destinationer forlader gennem udgang A, og laboratoriets trafik til godkendte destinationer forlader gennem udgang B. Tilføj returruterne, oversættelsesreglerne og den tilsigtede adfærd, når en udgang er nede.

traceroute -n 198.51.100.10

Test derefter en lokal tjeneste mellem VLAN'er separat, fordi den udøver en anden beslutning i samme design.

En frisk strøm fra hver VLAN, en fungerende lokal tjeneste og en dokumenteret fejlvej beviser tilsammen designet; en enkelt vellykket ping beviser kun, at én vej fandtes i det øjeblik.