Ĉu du ejoj bezonas samajn VLAN ID por eja VPN?

Samaj VLAN-numeroj en du oficejoj sentiĝas kvazaŭ ili helpus ejan tunelon, kaj ili ŝanĝas nenion pri tio, kion la tunelo portas. VLAN ID markas Ethernet-dissendan domajnon ene de unu konstruaĵo; la tunelo plusendas IP-paketojn inter la enirejoj. Du ejoj povas uzi tute malsaman VLAN-numeradon kaj tamen vojo al la alia, kaj du ejoj povas uzi identan VLAN-numeradon kaj tamen ne povi atingi unu la alian. La variablo, kiu decidas atingeblon, estas la adresa plano.

La mito: samaj VLAN ID ĉe ambaŭ finoj

La kredo venas de racia loko. Ene de unu konstruaĵo, du pordoj en la sama VLAN povas interparoli kaj du pordoj en malsamaj VLAN ne povas, do la VLAN-numero aspektas kiel tio, kio donas konektecon. Trans voja tunelo mankas komuna Ethernet-segmento por priskribi la etikedon, kaj la enirejoj neniam interŝanĝas VLAN-etikedojn.

Kion la tunelo bezonas, estas paro da adresaj areoj kiuj ne interkovriĝas kaj politiko kiu permesas la trafikon inter ili. Ŝanĝu la VLAN en ajna oficejo kaj la tunelo daŭre funkcias, ĉar nenio en la tunela agordo referencis ĝin. Tio estas la testo kiu solvas la disputon: renummerigu VLAN, lasu la adresojn netuŝitaj kaj observu ĉu la tunelo restas aktiva.

La inversa testo estas same informa. Donu al ambaŭ oficejoj la saman subreton kaj neniu kvanto da kongruaj VLAN-numeroj faros adreson senduba.

Kion la tunelo efektive portas

IPsec protektas IP-paketojn laŭ politiko esprimita per adresoj, protokoloj kaj pordoj. La IPsec-arkitekturo priskribas tiujn selektilojn ĉe la IP-tavolo, kiu estas pluraj tavoloj super io ajn, kion priskribas ŝaltila etikedo. Kiam paketo eniras la tunelon, ĝi jam forlasis la VLAN; la etikedon konsumis la loka ŝaltilo.

Politik-bazitaj kaj vojo-bazitaj dezajnoj diferencas en tio, kiel ili elektas la tunelon, ne en tio, kion ili povas porti. Politik-bazita samtavolano kongruigas trafik-selektilojn kaj sendas kongruajn paketojn en la tunelon. Vojo-bazita samtavolano vojigas trafikon ĉe tunela interfaco kaj lasas la vojigan tabelon decidi. Ambaŭ ankoraŭ intertraktas protektan amplekson, do vojo kiu montras al la tunelo ne larĝigas tion, pri kio la samtavolanoj konsentis protekti.

Tiu distingo klarigas oftan duonan malsukceson: la vojo ekzistas, paketoj eniras la tunelon, kaj la fora flanko forĵetas ilin ĉar la intertraktitaj selektiloj neniam inkludis tiun prefikson. Legi la instalitajn politikojn montras, kiu amplekso efektive validiĝis.

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

La interkovro kiu efektive rompas

Du oficejoj kun malsamaj subretoj vojigas pure tra tunelo, kaj iliaj VLAN-numeroj estas senrilataj. Du oficejoj kun la sama subreto ne, ĉar peto por donita adreso havas du eblajn signifojn kaj la vojiga tabelo povas elekti nur unu. Renumerigi unu ejon estas la pura solvo, kaj ĝi kutime estas pli malmultekosta ol la alternativoj post kiam la DNS- kaj fajroŝirmilaj ŝanĝoj estas kalkulitaj.

Kiam renumerigo estas neebla, intenca traduka dezajno povas prezenti apartajn adresajn vidojn al ĉiu flanko. Tio signifas unu-al-unu mapadon, kongruajn selektilojn, DNS-rikordojn kiuj spegulas la tradukitan vidon kaj revenan vojigon kiu postvivas la reeskribon. Ĝi estas subtenata dezajno kun reala operacia kosto, kaj ĝi ne estas tio, kion faras ŝanĝo de VLAN ID.

Samaj VLAN-numeroj ĉe ambaŭ finoj foje estas koincido de komuna ŝablono, kaj trakti tiun koincidon kiel la kaŭzon de funkcianta tunelo kondukas al la malĝusta ŝanĝo kiam io poste rompiĝas.

Unu tasko por tavolo, skribe

La loka ŝaltilo decidas, kiuj pordoj dividas dissendan domajnon, kaj ĝia VLAN-numerado estas loka librotenado, kiun neniu alia ejo bezonas scii. La enirejo aŭtentikigas la samtavolanon kaj plenumas la intertraktitan protektan amplekson. La vojiga tabelo decidas kien malĉifrita paketo iras poste, kaj la alirpolitiko decidas ĉu tiu paketo entute devus esti permesita.

Teni tiujn taskojn apartaj estas tio, kio faras ŝanĝojn sekuraj. VLAN-renumerigo en unu oficejo tuŝas la lokan ŝaltilon, la DHCP-amplekson kaj eble fajroŝirmilan zonon, kaj ĝi ne tuŝas la tunelon. Prefiksa ŝanĝo tuŝas la tunelajn selektilojn, la vojojn ĉe ambaŭ flankoj kaj la alirpolitikon, kaj ĝi ne tuŝas la ŝaltilajn etikedojn.

Revenaj vojoj, privata DNS kaj postuloj pri aplika identeco estas denove apartaj taskoj, kaj neniu el ili venas per kopiado de VLAN-numero de la alia ejo. Dezajna dokumento kiu listigas atingeblajn prefiksojn kaj permesitajn servojn postvivas ŝaltilan renovigon; unu kiu listigas VLAN-numerojn ne postvivas.

Konfirmu la lokan bildon per la pontaj iloj antaŭ ol supozi ke etikedo atingas la tunelon.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Kiam layer-2-etendiĝo estas la vera postulo

Kelkaj dezajnoj vere bezonas Ethernet-konduton trans ejoj: malnova aplikaĵo kiu dependas de dissenda malkovro, migrado kiu devas konservi adreson dum maŝino moviĝas, aŭ protokolo kiu enkorpigas layer-2-supozojn. Tiuj kazoj postulas supertavolon aŭ pontitan servon kiu portas la kadrojn, kaj tiam VLAN-membreco, buklopreventado kaj fiaskotraktado fariĝas aferoj de fino al fino.

Tio estas multe pli granda fiaska domajno, kaj ĝi devus esti intenca elekto anstataŭ la hazarda rezulto de provo funkciigi dosierdividon. Ordinara dosier-servilo, datumbazo aŭ reta aplikaĵo bezonas rajtigitan IP-vojon, kaj ĝi estos pli feliĉa sen etendita dissenda domajno sub ĝi.

Skribu la VPN-kontrakton kiel atingeblaj prefiksoj plus permesitaj servoj, kaj registru la VLAN-etikedon nur tie, kie lokaj operacioj bezonas ĝin. Ĉiu oficejo tiam povas renummerigi sian propran ŝaltadon sen transformi ĉiun ŝanĝon en tunelan redesegnon.