Het twee terreine dieselfde VLAN-ID's nodig vir 'n site-VPN?

Dieselfde VLAN-nommers by twee kantore laat dit voel of dit 'n site-tot-site-tonnel moet help, en dit verander niks aan wat die tonnel vervoer nie. 'n VLAN-ID merk 'n Ethernet-uitsaaidomein binne een gebou; die tonnel vervoer IP-pakkette tussen die deurgange. Twee kantore kan heeltemal verskillende VLAN-nommering gebruik en steeds na mekaar toe roeteer, en twee kantore kan identiese VLAN-nommering gebruik en steeds nie mekaar bereik nie. Die veranderlike wat bereikbaarheid bepaal, is die adresplan.

Die mite: dieselfde VLAN-ID's aan beide kante

Die oortuiging kom van 'n redelike plek. Binne een gebou kan twee poorte in dieselfde VLAN met mekaar praat en twee poorte in verskillende VLAN's nie, so die VLAN-nommer lyk soos die ding wat konnektiwiteit verleen. Oor 'n gerouteerde tonnel is daar geen gedeelde Ethernet-segment wat die etiket kan beskryf nie, en die deurgange ruil nooit VLAN-etikette uit nie.

Wat die tonnel nodig het, is 'n paar adresreekse wat nie oorvleuel nie en 'n beleid wat die verkeer tussen hulle toelaat. Verander die VLAN by enige kantoor en die tonnel bly werk, want niks in die tonnelkonfigurasie het daarna verwys nie. Dit is die toets wat die argument besleg: hernommer 'n VLAN, laat die adresse ongemoeid en kyk of die tonnel op bly.

Die omgekeerde toets is ewe insiggewend. Gee albei kantore dieselfde subnet en geen hoeveelheid ooreenstemmende VLAN-nommers sal 'n adres ondubbelsinnig maak nie.

Wat die tonnel werklik vervoer

IPsec beskerm IP-pakkette volgens 'n beleid wat in adresse, protokolle en poorte uitgedruk word. Die IPsec-argitektuur beskryf daardie selektore op die IP-laag, wat verskeie lae bo enigiets is wat 'n switch-etiket beskryf. Wanneer 'n pakket die tonnel binnegaan, het dit reeds die VLAN verlaat; die etiket is deur die plaaslike switch verteer.

Beleidgebaseerde en roetegebaseerde ontwerpe verskil in hoe hulle die tonnel kies, nie in wat hulle kan vervoer nie. 'n Beleidgebaseerde eweknie pas verkeersselektore en stuur passende pakkette in die tonnel in. 'n Roetegebaseerde eweknie roeteer verkeer by 'n tonnelkoppelvlak en laat die roetetabel besluit. Albei onderhandel steeds 'n beskermingsomvang, so 'n roete wat na die tonnel wys, verbreed nie wat die eweknieë ooreengekom het om te beskerm nie.

Daardie onderskeid verduidelik 'n algemene halfmislukking: die roete bestaan, pakkette gaan die tonnel binne, en die ander kant laat val hulle omdat die onderhandelde selektore nooit daardie voorvoegsel ingesluit het nie. Om die geïnstalleerde beleide te lees, wys watter omvang werklik in werking getree het.

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

Die oorvleueling wat werklik breek

Twee kantore met verskillende subnette roeteer skoon deur 'n tonnel, en hulle VLAN-nommers is irrelevant. Twee kantore met dieselfde subnet nie, want 'n versoek vir 'n gegewe adres het twee moontlike betekenisse en die roetetabel kan net een kies. Om een werf te hernommer is die skoon oplossing, en dit is gewoonlik goedkoper as die alternatiewe sodra die DNS- en firewallveranderinge getel word.

Wanneer hernommering onmoontlik is, kan 'n doelbewuste vertaalontwerp verskillende adresbeelde aan elke kant bied. Dit beteken een-tot-een-kartering, ooreenstemmende selektore, DNS-inskrywings wat die vertaalde beeld weerspieël en terugroetering wat die herskrywing oorleef. Dit is 'n ondersteunde ontwerp met werklike bedryfskoste, en dit is nie wat die verandering van 'n VLAN-ID doen nie.

Dieselfde VLAN-nommers aan beide kante is soms 'n toevalligheid van 'n gedeelde sjabloon, en om daardie toevalligheid as die oorsaak van 'n werkende tonnel te behandel, lei tot die verkeerde verandering wanneer iets later breek.

Een taak per laag, op skrif

Die plaaslike switch besluit watter poorte 'n uitsaaidomein deel, en sy VLAN-nommering is plaaslike boekhouding wat geen ander werf hoef te ken nie. Die deurgang verifieer die eweknie en handhaaf die onderhandelde beskermingsomvang. Die roetetabel besluit waar 'n ontsyferde pakket volgende gaan, en die toegangsbeleid besluit of daardie pakket hoegenaamd toegelaat moes word.

Om daardie take geskei te hou, is wat veranderinge veilig maak. 'n VLAN-hernommering by een kantoor raak die plaaslike switch, die DHCP-omvang en moontlik 'n firewall-sone, en dit raak nie die tonnel nie. 'n Voorvoegselverandering raak die tonnelselektore, die roetes aan beide kante en die toegangsbeleid, en dit raak nie die switch-etikette nie.

Terugroetes, private DNS en vereistes vir toepassingsidentiteit is weer aparte take, en nie een daarvan kom deur 'n VLAN-nommer van die ander werf te kopieer nie. 'n Ontwerpdokument wat bereikbare voorvoegsels en toegelate dienste lys, oorleef 'n switch-verfrissing; een wat VLAN-nommers lys, nie.

Bevestig die plaaslike prentjie met die brug-gereedskap voordat jy aanneem dat 'n etiket die tonnel bereik.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Wanneer layer-2-uitbreiding die werklike vereiste is

Sommige ontwerpe het werklik Ethernet-gedrag oor werwe nodig: 'n ou toepassing wat op uitsaaiontdekking staatmaak, 'n migrasie wat 'n adres moet behou terwyl 'n masjien beweeg, of 'n protokol wat layer-2-aannames insluit. Daardie gevalle vra vir 'n oorlegsel of 'n oorbrugde diens wat die rame dra, en dan word VLAN-lidmaatskap, lusvoorkoming en fouthantering end-tot-end-kwessies.

Dit is 'n veel groter foutdomein, en dit behoort 'n doelbewuste keuse te wees eerder as die toevallige gevolg van 'n poging om 'n lêerdeling te laat werk. 'n Gewone lêerbediener, databasis of webtoepassing het 'n gemagtigde IP-pad nodig, en dit sal gelukkiger wees sonder 'n uitgestrekte uitsaaidomein daaronder.

Skryf die VPN-kontrak as bereikbare voorvoegsels plus toegelate dienste, en teken die VLAN-etiket slegs aan waar plaaslike bedrywighede dit nodig het. Elke kantoor kan dan sy eie skakeling hernommer sonder om elke verandering in 'n tonnelherontwerp te omskep.