Hebben twee locaties dezelfde VLAN-ID's nodig voor een site-VPN?

Dezelfde VLAN-nummers op twee kantoren voelen alsof ze een tunnel tussen locaties zouden moeten helpen, en ze veranderen niets aan wat de tunnel vervoert. Een VLAN-ID labelt een Ethernet-broadcastdomein binnen één gebouw; de tunnel stuurt IP-pakketten tussen de gateways door. Twee locaties kunnen een volledig andere VLAN-nummering gebruiken en toch naar elkaar routeren, en twee locaties kunnen dezelfde VLAN-nummering gebruiken en elkaar toch niet bereiken. De variabele die de bereikbaarheid bepaalt, is het adresplan.

De mythe: dezelfde VLAN-ID's aan beide uiteinden

De overtuiging komt van een redelijke plek. Binnen één gebouw kunnen twee poorten in dezelfde VLAN met elkaar praten en twee poorten in verschillende VLAN's niet, dus het VLAN-nummer lijkt het ding dat verbinding geeft. Over een gerouteerde tunnel is er geen gedeeld Ethernet-segment dat de tag kan beschrijven, en de gateways wisselen nooit VLAN-labels uit.

Wat de tunnel nodig heeft, is een paar niet-overlappende adresbereiken en een beleid dat het verkeer daartussen toestaat. Wijzig de VLAN op een willekeurig kantoor en de tunnel blijft werken, omdat niets in de tunnelconfiguratie ernaar verwees. Dat is de test die de discussie beslecht: hernummer een VLAN, laat de adressen ongemoeid en kijk of de tunnel overeind blijft.

De omgekeerde test is even leerzaam. Geef beide kantoren hetzelfde subnet en geen enkele hoeveelheid overeenkomende VLAN-nummers zal een adres ondubbelzinnig maken.

Wat de tunnel werkelijk vervoert

IPsec beschermt IP-pakketten volgens een beleid dat in adressen, protocollen en poorten is uitgedrukt. De IPsec-architectuur beschrijft die selectors op de IP-laag, die verscheidene lagen boven alles ligt wat een switch-tag beschrijft. Wanneer een pakket de tunnel binnenkomt, heeft het de VLAN al verlaten; de tag is door de lokale switch verbruikt.

Beleidsgebaseerde en routegebaseerde ontwerpen verschillen in hoe ze de tunnel kiezen, niet in wat ze kunnen vervoeren. Een beleidsgebaseerde peer matcht verkeersselectors en stuurt overeenkomende pakketten de tunnel in. Een routegebaseerde peer routeert verkeer op een tunnelinterface en laat de routingtabel beslissen. Beide onderhandelen nog steeds een beschermingsbereik, dus een route die naar de tunnel wijst, verbreedt niet wat de peers zijn overeengekomen te beschermen.

Dat onderscheid verklaart een veelvoorkomende halve mislukking: de route bestaat, pakketten gaan de tunnel in, en de andere kant laat ze vallen omdat de onderhandelde selectors dat prefix nooit omvatten. Het lezen van de geïnstalleerde beleidsregels laat zien welk bereik werkelijk van kracht werd.

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

De overlap die werkelijk breekt

Twee kantoren met verschillende subnets routeren schoon door een tunnel, en hun VLAN-nummers zijn irrelevant. Twee kantoren met hetzelfde subnet niet, omdat een verzoek voor een bepaald adres twee mogelijke betekenissen heeft en de routingtabel er maar één kan kiezen. Eén locatie hernummeren is de schone oplossing, en het is meestal goedkoper dan de alternatieven als de DNS- en firewallwijzigingen worden meegeteld.

Wanneer hernummeren onmogelijk is, kan een bewust vertaalontwerp elke kant verschillende adresbeelden presenteren. Dat betekent een-op-een-mapping, overeenkomende selectors, DNS-vermeldingen die het vertaalde beeld weerspiegelen en retourroutering die de herschrijving overleeft. Het is een ondersteund ontwerp met echte operationele kosten, en het is niet wat het wijzigen van een VLAN-ID doet.

Dezelfde VLAN-nummers aan beide uiteinden zijn soms een toeval van een gedeelde sjabloon, en dat toeval als de oorzaak van een werkende tunnel behandelen leidt tot de verkeerde wijziging wanneer er later iets breekt.

Eén taak per laag, opgeschreven

De lokale switch bepaalt welke poorten een broadcastdomein delen, en de VLAN-nummering is lokale boekhouding die geen enkele andere locatie hoeft te kennen. De gateway authenticeert de peer en handhaaft het onderhandelde beschermingsbereik. De routingtabel bepaalt waar een ontsleuteld pakket daarna heen gaat, en het toegangsbeleid bepaalt of dat pakket überhaupt toegestaan had moeten worden.

Die taken gescheiden houden is wat wijzigingen veilig maakt. Een VLAN-hernummering op één kantoor raakt de lokale switch, het DHCP-bereik en mogelijk een firewallzone, en ze raakt de tunnel niet. Een prefixwijziging raakt de tunnelselectors, de routes aan beide kanten en het toegangsbeleid, en ze raakt de switch-tags niet.

Retourroutes, private DNS en eisen aan applicatie-identiteit zijn weer aparte taken, en geen ervan komt door een VLAN-nummer van de andere locatie te kopiëren. Een ontwerpdocument dat bereikbare prefixen en toegestane diensten opsomt, overleeft een switchvervanging; een dat VLAN-nummers opsomt niet.

Bevestig het lokale beeld met de bridge-tools voordat u aanneemt dat een tag de tunnel bereikt.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Wanneer layer-2-uitbreiding de echte eis is

Sommige ontwerpen hebben echt Ethernet-gedrag tussen locaties nodig: een legacy-applicatie die op broadcast-ontdekking leunt, een migratie die een adres moet behouden terwijl een machine verhuist, of een protocol dat layer-2-aannames insluit. Zulke gevallen vragen om een overlay of een overbrugde dienst die de frames draagt, en dan worden VLAN-lidmaatschap, luspreventie en foutafhandeling end-to-end-aangelegenheden.

Dat is een veel groter foutdomein, en het zou een bewuste keuze moeten zijn in plaats van het toevallige resultaat van een poging om bestandendeling aan de praat te krijgen. Een gewone fileserver, database of webapplicatie heeft een geautoriseerd IP-pad nodig, en is gelukkiger zonder een uitgerekt broadcastdomein eronder.

Schrijf het VPN-contract als bereikbare prefixen plus toegestane diensten, en leg de VLAN-tag alleen vast waar de lokale bedrijfsvoering hem nodig heeft. Elk kantoor kan dan zijn eigen switching hernummeren zonder elke wijziging in een tunnelherontwerp te veranderen.