Treng to lokasjonar same VLAN-ID for ein site-VPN?

Same VLAN-nummer på to kontor kjennest som noko som burde hjelpe ein tunnel mellom lokasjonar, og det endrar ingenting av det tunnelen transporterer. Ein VLAN-ID merkar eit Ethernet-kringkastingsdomene inne i éin bygning; tunnelen videresender IP-pakkar mellom gatewayane. To lokasjonar kan bruke heilt ulik VLAN-nummerering og likevel rute til kvarandre, og to lokasjonar kan bruke identisk VLAN-nummerering og likevel ikkje nå kvarandre. Variabelen som avgjer nåbarheita, er adresseplanen.

Myten: same VLAN-ID i begge endar

Overtydinga kjem frå ein rimeleg stad. Inne i éin bygning kan to portar i same VLAN snakke saman, og to portar i ulike VLAN kan ikkje, så VLAN-nummeret ser ut som det som gir tilkopling. Gjennom ein ruta tunnel finst det ingen delt Ethernet-segment som taggen kan skildre, og gatewayane byter aldri VLAN-etikettar.

Det tunnelen treng, er eit par adresseområde som ikkje overlappar, og ein policy som tillèt trafikken mellom dei. Endre VLAN på eit kva som helst kontor, og tunnelen held fram med å verke, fordi ingenting i tunnelkonfigurasjonen viste til det. Det er testen som avgjer diskusjonen: omnummerer ein VLAN, lat adressene vere og sjå om tunnelen held seg oppe.

Den omvende testen er like opplysande. Gi begge kontora same subnett, og inga mengd like VLAN-nummer vil gjere ein adresse eintydig.

Kva tunnelen faktisk transporterer

IPsec vernar IP-pakkar etter ein policy uttrykt i adresser, protokollar og portar. IPsec-arkitekturen skildrar desse selektorane på IP-laget, som ligg fleire lag over alt ein svitsj-tagg skildrar. Når ein pakke går inn i tunnelen, har han alt forlate VLAN-et; taggen er brukt opp av den lokale svitsjen.

Policybaserte og routebaserte design skil seg i korleis dei vel tunnelen, ikkje i kva dei kan transportere. Ein policybasert peer matchar trafikkselektorar og sender samsvarande pakkar inn i tunnelen. Ein routebasert peer ruter trafikk på eit tunnelgrensesnitt og lèt rutetabellen avgjere. Begge forhandlar framleis om eit vernomfang, så ei rute som peikar på tunnelen utvidar ikkje det partane vart samde om å verne.

Den skilnaden forklarer ein vanleg halvfeil: ruta finst, pakkane går inn i tunnelen, og den fjerne sida forkastar dei fordi dei forhandla selektorane aldri omfatta det prefikset. Å lese dei installerte policyane viser kva omfang som faktisk tok til å gjelde.

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

Overlappinga som faktisk bryt

To kontor med ulike subnett ruter reint gjennom ein tunnel, og VLAN-numra deira er irrelevante. To kontor med same subnett gjer det ikkje, fordi ein førespurnad om ei gitt adresse har to moglege tydingar, og rutetabellen kan berre velje éin. Omnummerering av éin lokasjon er den reine løysinga, og ho er vanlegvis billegare enn alternativa når DNS- og brannmur-endringane er rekna med.

Når omnummerering er umogeleg, kan eit medvite omsetjingsdesign presentere ulike adressevisingar for kvar side. Det tyder éin-til-éin-mapping, samsvarande selektorar, DNS-postar som speglar den omsette visinga og returrutar som overlever omskrivinga. Det er eit støtta design med reell driftskostnad, og det er ikkje det å endre ein VLAN-ID gjer.

Same VLAN-nummer i begge endar er stundom ein tilfeldigheit frå ein delt mal, og å handsame den tilfeldigheita som årsaka til ein fungerande tunnel fører til feil endring når noko bryt seinare.

Éi oppgåve per lag, skriven ned

Den lokale svitsjen avgjer kva portar som deler eit kringkastingsdomene, og VLAN-nummereringa er lokalt rekneskap som ingen annan lokasjon treng å kjenne. Gatewayen autentiserer peeren og handhevar det forhandla vernomfanget. Rutetabellen avgjer kvar ein dekryptert pakke går vidare, og tilgangspolicyen avgjer om den pakken i det heile burde vore tillaten.

Å halde desse oppgåvene åtskilde er det som gjer endringar trygge. Omnummerering av VLAN på eitt kontor rører den lokale svitsjen, DHCP-området og kanskje ei brannmursone, og ho rører ikkje tunnelen. Ei prefiksendring rører selektorane til tunnelen, rutene på begge sider og tilgangspolicyen, og ho rører ikkje svitsj-taggene.

Returrutar, privat DNS og krav til applikasjonsidentitet er igjen separate oppgåver, og ingen av dei kjem ved å kopiere eit VLAN-nummer frå den andre lokasjonen. Eit designdokument som listar nåbare prefiks og tillatne tenester, overlever ei svitsj-utskifting; eitt som listar VLAN-nummer, gjer det ikkje.

Stadfest det lokale bildet med bruverktya før du går ut frå at ein tagg når tunnelen.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

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

Nokre design treng verkeleg Ethernet-åtferd mellom lokasjonar: ein eldre applikasjon som er avhengig av kringkastingsfunna, ei migrering som må halde på ei adresse medan ein maskin flyttar, eller ein protokoll som byggjer inn layer-2-føresetnader. Slike tilfelle krev eit overlay eller ei brua teneste som ber rammene, og då vert VLAN-medlemskap, sløyfeførebygging og feilhandsaming ende-til-ende-saker.

Det er eit mykje større feildomene, og det bør vere eit medvite val snarare enn det tilfeldige resultatet av eit forsøk på å få fildeling til å verke. Ein vanleg filserver, database eller webapplikasjon treng ein autorisert IP-veg, og han vil vere lukkelegare utan eit utstrekt kringkastingsdomene under seg.

Skriv VPN-kontrakten som nåbare prefiks pluss tillatne tenester, og registrer VLAN-taggen berre der den lokale drifta treng han. Kvart kontor kan då omnummerere si eiga svitsjing utan å gjere kvar endring til eit tunnelsredesign.