Skal to lokaliteter have samme VLAN-ID'er til en site-VPN?

Ens VLAN-numre på to kontorer føles som noget, der burde hjælpe en tunnel mellem lokaliteter, og det ændrer intet ved det, tunnelen transporterer. Et VLAN-ID mærker et Ethernet-broadcastdomæne inde i en bygning; tunnelen videresender IP-pakker mellem gateways. To lokaliteter kan bruge helt forskellig VLAN-nummerering og alligevel route til hinanden, og to lokaliteter kan bruge identisk VLAN-nummerering og alligevel ikke kunne nå hinanden. Variablen, der afgør nåbarhed, er adresseplanen.

Myten: samme VLAN-ID'er i begge ender

Overbevisningen kommer fra et rimeligt sted. Inde i en bygning kan to porte i samme VLAN tale sammen, og to porte i forskellige VLAN kan ikke, så VLAN-nummeret ser ud som det, der giver forbindelse. Hen over en routet tunnel er der ingen delt Ethernet-segment, som tagget kan beskrive, og gatewayene udveksler aldrig VLAN-etiketter.

Det, tunnelen har brug for, er et par adresseområder, der ikke overlapper, og en politik, der tillader trafikken mellem dem. Skift VLAN på et vilkårligt kontor, og tunnelen virker stadig, fordi intet i tunnelkonfigurationen henviste til det. Det er testen, der afgør diskussionen: omnummerér et VLAN, lad adresserne være og se, om tunnelen bliver oppe.

Den omvendte test er lige så oplysende. Giv begge kontorer samme subnet, og ingen mængde af ens VLAN-numre vil gøre en adresse entydig.

Hvad tunnelen faktisk transporterer

IPsec beskytter IP-pakker efter en politik udtrykt i adresser, protokoller og porte. IPsec-arkitekturen beskriver disse selectors på IP-laget, som ligger flere lag over alt, hvad et switch-tag beskriver. Når en pakke går ind i tunnelen, har den allerede forladt VLAN'et; tagget er brugt af den lokale switch.

Politikbaserede og routebaserede design adskiller sig i, hvordan de vælger tunnelen, ikke i hvad de kan transportere. En politikbaseret peer matcher trafik-selectors og sender matchende pakker ind i tunnelen. En routebaseret peer router trafik på en tunnelinterface og lader routingtabellen beslutte. Begge forhandler stadig et beskyttelsesomfang, så en rute, der peger på tunnelen, udvider ikke det, parterne blev enige om at beskytte.

Den forskel forklarer en almindelig halvfejl: ruten findes, pakkerne går ind i tunnelen, og den fjerne side kasserer dem, fordi de forhandlede selectors aldrig omfattede det præfiks. Læsning af de installerede politikker viser, hvilket omfang der faktisk trådte i kraft.

ip xfrm policy
ip route show
swanctl --list-sas

Det overlap, der faktisk bryder

To kontorer med forskellige subnets router rent gennem en tunnel, og deres VLAN-numre er irrelevante. To kontorer med samme subnet gør ikke, fordi en anmodning om en given adresse har to mulige betydninger, og routingtabellen kan kun vælge én. Omnummerering af et lokalitet er den rene løsning, og den er normalt billigere end alternativerne, når DNS- og firewallændringerne tælles med.

Når omnummerering er umulig, kan et bevidst oversættelsesdesign præsentere forskellige adressebilleder for hver side. Det betyder en-til-en-mapping, matchende selectors, DNS-poster, der afspejler det oversatte billede, og returrouting, der overlever omskrivningen. Det er et understøttet design med reel driftsomkostning, og det er ikke det, en ændring af et VLAN-ID gør.

Ens VLAN-numre i begge ender er nogle gange en tilfældighed fra en delt skabelon, og at behandle den tilfældighed som årsagen til en fungerende tunnel fører til den forkerte ændring, når noget senere bryder.

Én opgave pr. lag, skrevet ned

Den lokale switch afgør, hvilke porte der deler et broadcastdomæne, og dens VLAN-nummerering er lokalt bogholderi, som ingen anden lokalitet behøver at kende. Gatewayen autentificerer peeren og håndhæver det forhandlede beskyttelsesomfang. Routingtabellen afgør, hvor en dekrypteret pakke går hen næste gang, og adgangspolitikken afgør, om den pakke overhovedet burde have været tilladt.

At holde de opgaver adskilt er det, der gør ændringer sikre. En VLAN-omnummerering på et kontor rører den lokale switch, DHCP-området og muligvis en firewallzone, og den rører ikke tunnelen. En præfiksændring rører tunnelens selectors, ruterne på begge sider og adgangspolitikken, og den rører ikke switch-taggene.

Returruter, privat DNS og krav til applikationsidentitet er igen separate opgaver, og ingen af dem kommer ved at kopiere et VLAN-nummer fra den anden lokalitet. Et designdokument, der lister nåbare præfikser og tilladte tjenester, overlever en switch-udskiftning; et, der lister VLAN-numre, gør ikke.

Bekræft det lokale billede med bridge-værktøjerne, før du antager, at et tag når tunnelen.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Når layer-2-udvidelse er det reelle krav

Nogle design har genuint brug for Ethernet-adfærd mellem lokaliteter: en ældre applikation, der er afhængig af broadcast-opdagelse, en migrering, der skal bevare en adresse, mens en maskine flytter, eller en protokol, der indlejrer layer-2-antagelser. De tilfælde kræver et overlay eller en broet tjeneste, der bærer rammerne, og så bliver VLAN-medlemskab, loopforebyggelse og fejlhåndtering end-to-end-anliggender.

Det er et meget større fejldomæne, og det bør være et bevidst valg snarere end det tilfældige resultat af at prøve at få en fildeling til at virke. En almindelig filserver, database eller webapplikation har brug for en autoriseret IP-vej og vil være gladere uden et udstrakt broadcastdomæne under sig.

Skriv VPN-kontrakten som nåbare præfikser plus tilladte tjenester, og registrér VLAN-tagget kun, hvor den lokale drift har brug for det. Hvert kontor kan så omnummerere sin egen switching uden at gøre hver ændring til et tunnelsredesign.