Trenger to lokasjoner samme VLAN-ID for en site-VPN?

Like VLAN-numre på to kontorer føles som noe som burde hjelpe en tunnel mellom lokasjoner, og det endrer ingenting av det tunnelen transporterer. En VLAN-ID merker et Ethernet-broadcastdomene inne i én bygning; tunnelen videresender IP-pakker mellom gatewayene. To lokasjoner kan bruke helt forskjellig VLAN-nummerering og likevel rute til hverandre, og to lokasjoner kan bruke identisk VLAN-nummerering og likevel ikke nå hverandre. Variabelen som avgjør nåbarhet, er adresseplanen.

Myten: like VLAN-ID-er i begge ender

Overbevisningen kommer fra et rimelig sted. Inne i én bygning kan to porter i samme VLAN snakke sammen, og to porter i ulike VLAN kan ikke, så VLAN-nummeret ser ut som det som gir tilkobling. Gjennom en rutet tunnel finnes det ingen delt Ethernet-segment som taggen kan beskrive, og gatewayene utveksler aldri VLAN-etiketter.

Det tunnelen trenger, er et par adresseområder som ikke overlapper, og en policy som tillater trafikken mellom dem. Endre VLAN på et hvilket som helst kontor, og tunnelen fortsetter å virke, fordi ingenting i tunnelkonfigurasjonen refererte til det. Det er testen som avgjør diskusjonen: omnummerer en VLAN, la adressene være og se om tunnelen holder seg oppe.

Den omvendte testen er like opplysende. Gi begge kontorene samme subnett, og ingen mengde like VLAN-numre vil gjøre en adresse entydig.

Hva tunnelen faktisk transporterer

IPsec beskytter IP-pakker etter en policy uttrykt i adresser, protokoller og porter. IPsec-arkitekturen beskriver disse selektorene på IP-laget, som ligger flere lag over alt et svitsj-tagg beskriver. Når en pakke går inn i tunnelen, har den allerede forlatt VLAN-et; taggen er brukt opp av den lokale svitsjen.

Policybaserte og routebaserte design skiller seg i hvordan de velger tunnelen, ikke i hva de kan transportere. En policybasert peer matcher trafikkselektorer og sender samsvarende pakker inn i tunnelen. En routebasert peer ruter trafikk på et tunnelgrensesnitt og lar rutetabellen avgjøre. Begge forhandler fortsatt om et beskyttelsesomfang, så en rute som peker på tunnelen utvider ikke det partene ble enige om å beskytte.

Den forskjellen forklarer en vanlig halvfeil: ruten finnes, pakkene går inn i tunnelen, og den fjerne siden forkaster dem fordi de forhandlede selektorene aldri omfattet det prefikset. Å lese de installerte policyene viser hvilket omfang som faktisk trådte i kraft.

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

Overlappingen som faktisk bryter

To kontorer med ulike subnett ruter rent gjennom en tunnel, og VLAN-numrene deres er irrelevante. To kontorer med samme subnett gjør det ikke, fordi en forespørsel om en gitt adresse har to mulige betydninger, og rutetabellen kan bare velge én. Omnummerering av én lokasjon er den rene løsningen, og den er vanligvis billigere enn alternativene når DNS- og brannmur-endringene regnes med.

Når omnummerering er umulig, kan et bevisst oversettelsesdesign presentere ulike adressevisninger for hver side. Det betyr én-til-én-mapping, samsvarende selektorer, DNS-poster som gjenspeiler den oversatte visningen og returrutinger som overlever omskrivingen. Det er et støttet design med reell driftskostnad, og det er ikke det å endre en VLAN-ID gjør.

Like VLAN-numre i begge ender er noen ganger en tilfeldighet fra en delt mal, og å behandle den tilfeldigheten som årsaken til en fungerende tunnel fører til feil endring når noe bryter senere.

Én oppgave per lag, skrevet ned

Den lokale svitsjen avgjør hvilke porter som deler et broadcastdomene, og VLAN-nummereringen er lokalt regnskap som ingen annen lokasjon trenger å kjenne. Gatewayen autentiserer peeren og håndhever det forhandlede beskyttelsesomfanget. Rutetabellen avgjør hvor en dekryptert pakke går videre, og tilgangspolicyen avgjør om den pakken i det hele tatt burde vært tillatt.

Å holde disse oppgavene atskilt er det som gjør endringer trygge. Omnummerering av VLAN på ett kontor berører den lokale svitsjen, DHCP-området og kanskje en brannmursone, og den berører ikke tunnelen. En prefiksendring berører tunnelens selektorer, rutene på begge sider og tilgangspolicyen, og den berører ikke svitsj-taggene.

Returruter, privat DNS og krav til applikasjonsidentitet er igjen separate oppgaver, og ingen av dem kommer ved å kopiere et VLAN-nummer fra den andre lokasjonen. Et designdokument som lister nåbare prefikser og tillatte tjenester, overlever en svitsj-utskifting; ett som lister VLAN-numre, gjør det ikke.

Bekreft det lokale bildet med broverktøyene før du antar at en tagg når tunnelen.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Når layer-2-utvidelse er det reelle kravet

Noen design trenger virkelig Ethernet-atferd mellom lokasjoner: en eldre applikasjon som er avhengig av broadcast-oppdagelse, en migrering som må beholde en adresse mens en maskin flytter, eller en protokoll som bygger inn layer-2-antakelser. Slike tilfeller krever et overlay eller en broet tjeneste som bærer rammene, og da blir VLAN-medlemskap, sløyfeforebygging og feilhåndtering ende-til-ende-anliggender.

Det er et mye større feildomene, og det bør være et bevisst valg snarere enn det tilfeldige resultatet av et forsøk på å få fildeling til å virke. En vanlig filserver, database eller webapplikasjon trenger en autorisert IP-vei, og den vil være lykkeligere uten et utstrakt broadcastdomene under seg.

Skriv VPN-kontrakten som nåbare prefikser pluss tillatte tjenester, og registrer VLAN-taggen bare der den lokale driften trenger den. Hvert kontor kan da omnummerere sin egen svitsjing uten å gjøre hver endring til et tunnelsredesign.