Behöver två platser samma VLAN-ID för ett plats-VPN?

Samma VLAN-nummer på två kontor känns som något som borde hjälpa en tunnel mellan platser, och det ändrar ingenting av det tunneln transporterar. Ett VLAN-ID märker en Ethernet-broadcastdomän inne i en byggnad; tunneln vidarebefordrar IP-paket mellan gatewayerna. Två platser kan använda helt olika VLAN-numrering och ändå routa till varandra, och två platser kan använda identisk VLAN-numrering och ändå inte nå varandra. Variabeln som avgör nåbarheten är adressplanen.

Myten: samma VLAN-ID i båda ändar

Övertygelsen kommer från en rimlig plats. Inne i en byggnad kan två portar i samma VLAN prata med varandra och två portar i olika VLAN inte, så VLAN-numret ser ut som det som ger anslutning. Genom en routad tunnel finns inget delat Ethernet-segment som taggen kan beskriva, och gatewayerna utbyter aldrig VLAN-etiketter.

Det tunneln behöver är ett par adressområden som inte överlappar och en policy som tillåter trafiken mellan dem. Ändra VLAN på vilket kontor som helst och tunneln fortsätter att fungera, eftersom ingenting i tunnelkonfigurationen refererade till det. Det är testet som avgör diskussionen: numrera om en VLAN, lämna adresserna och se om tunneln håller sig uppe.

Det omvända testet är lika upplysande. Ge båda kontoren samma subnät och ingen mängd likadana VLAN-nummer kommer att göra en adress entydig.

Vad tunneln faktiskt transporterar

IPsec skyddar IP-paket enligt en policy uttryckt i adresser, protokoll och portar. IPsec-arkitekturen beskriver dessa selektorer på IP-lagret, som ligger flera lager över allt en switch-tagg beskriver. När ett paket går in i tunneln har det redan lämnat VLAN:et; taggen har förbrukats av den lokala switchen.

Policybaserade och routebaserade designer skiljer sig i hur de väljer tunneln, inte i vad de kan transportera. En policybaserad peer matchar trafikselektorer och skickar matchande paket in i tunneln. En routebaserad peer routar trafik på ett tunnelgränssnitt och låter routingtabellen avgöra. Båda förhandlar fortfarande om en skyddsomfattning, så en route som pekar mot tunneln utökar inte det parterna kommit överens om att skydda.

Den skillnaden förklarar ett vanligt halvfel: routen finns, paketen går in i tunneln och den bortre sidan kastar dem eftersom de förhandlade selektorerna aldrig omfattade det prefixet. Att läsa de installerade policyerna visar vilken omfattning som faktiskt trädde i kraft.

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

Överlappningen som faktiskt bryter

Två kontor med olika subnät routar rent genom en tunnel, och deras VLAN-nummer är irrelevanta. Två kontor med samma subnät gör det inte, eftersom en begäran om en given adress har två möjliga betydelser och routingtabellen bara kan välja en. Omnumrering av en plats är den rena lösningen, och den är vanligtvis billigare än alternativen när DNS- och brandväggsändringarna räknas in.

När omnumrering är omöjlig kan en medveten översättningsdesign presentera olika adressvyer för varje sida. Det innebär en-till-en-mappning, matchande selektorer, DNS-poster som speglar den översatta vyn och returrouting som överlever omskrivningen. Det är en stödd design med verklig driftskostnad, och det är inte vad ändringen av ett VLAN-ID gör.

Samma VLAN-nummer i båda ändar är ibland en slump från en delad mall, och att behandla den slumpen som orsaken till en fungerande tunnel leder till fel ändring när något går sönder senare.

En uppgift per lager, nedskriven

Den lokala switchen avgör vilka portar som delar en broadcastdomän, och dess VLAN-numrering är lokal bokföring som ingen annan plats behöver känna till. Gatewayen autentiserar peeren och upprätthåller den förhandlade skyddsomfattningen. Routingtabellen avgör vart ett dekrypterat paket tar vägen härnäst, och åtkomstpolicyn avgör om det paketet alls borde ha tillåtits.

Att hålla dessa uppgifter åtskilda är det som gör ändringar säkra. En VLAN-omnumrering på ett kontor rör den lokala switchen, DHCP-området och möjligen en brandväggszon, och den rör inte tunneln. En prefixändring rör tunnelns selektorer, routrarna på båda sidor och åtkomstpolicyn, och den rör inte switch-taggarna.

Returrutter, privat DNS och krav på applikationsidentitet är återigen separata uppgifter, och ingen av dem kommer genom att kopiera ett VLAN-nummer från den andra platsen. Ett designdokument som listar nåbara prefix och tillåtna tjänster överlever ett switchbyte; ett som listar VLAN-nummer gör det inte.

Bekräfta den lokala bilden med bryggverktygen innan du antar att en tagg når tunneln.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

När layer-2-utökning är det verkliga kravet

Vissa designer behöver verkligen Ethernet-beteende mellan platser: en äldre applikation som är beroende av broadcast-upptäckt, en migrering som måste behålla en adress medan en maskin flyttar, eller ett protokoll som bäddar in layer-2-antaganden. Sådana fall kräver ett overlay eller en bryggad tjänst som bär ramarna, och då blir VLAN-medlemskap, slingförebyggande och felhantering frågor från ände till ände.

Det är en mycket större feldomän, och det bör vara ett medvetet val snarare än det slumpmässiga resultatet av ett försök att få fildelning att fungera. En vanlig filserver, databas eller webbapplikation behöver en auktoriserad IP-väg och är lyckligare utan en utsträckt broadcastdomän under sig.

Skriv VPN-kontraktet som nåbara prefix plus tillåtna tjänster, och registrera VLAN-taggen bara där den lokala driften behöver den. Varje kontor kan då numrera om sin egen switching utan att göra varje ändring till en tunnelomdesign.