Kell-e két helyszínnek azonos VLAN ID egy helyszíni VPN-hez?

Azonos VLAN-számok két irodában úgy tűnik, mintha segíteniük kellene egy helyszínek közötti alagúton, és semmit nem változtatnak azon, amit az alagút szállít. A VLAN ID egy Ethernet-szórási tartományt jelöl egy épületen belül; az alagút IP-csomagokat továbbít az átjárók között. Két helyszín teljesen eltérő VLAN-számozást használhat, és mégis irányíthat egymás felé, és két helyszín azonos VLAN-számozást használhat, és mégis képtelen lehet elérni egymást. Az elérhetőséget eldöntő változó a címterv.

A mítosz: azonos VLAN ID-k mindkét végén

A hit észszerű helyről ered. Egy épületen belül két port ugyanabban a VLAN-ban tud beszélni, két port különböző VLAN-ban pedig nem, ezért a VLAN-szám tűnik annak, ami kapcsolatot ad. Egy irányított alagúton át nincs közös Ethernet-szegmens, amelyet a címke leírhatna, és az átjárók soha nem cserélnek VLAN-címkéket.

Amire az alagútnak szüksége van, az két nem átfedő címtartomány és egy szabályzat, amely engedélyezi a köztük lévő forgalmat. Változtassa meg a VLAN-t bármelyik irodában, és az alagút tovább működik, mert semmi nem hivatkozott rá az alagút konfigurációjában. Ez a teszt dönti el a vitát: számozza át a VLAN-t, hagyja érintetlenül a címeket, és figyelje, hogy az alagút talpon marad-e.

A fordított teszt ugyanolyan tanulságos. Adja mindkét irodának ugyanazt az alhálózatot, és semmilyen mennyiségű azonos VLAN-szám nem teszi egyértelművé a címet.

Mit szállít valójában az alagút

Az IPsec a címekben, protokollokban és portokban kifejezett szabályzat szerint védi az IP-csomagokat. Az IPsec-architektúra ezeket a szelektorokat az IP-rétegen írja le, amely több réteggel minden felett van, amit egy kapcsoló címkéje leír. Amikor egy csomag belép az alagútba, már elhagyta a VLAN-t; a címkét a helyi kapcsoló használta fel.

A szabályzat alapú és az útvonal alapú tervek abban különböznek, hogyan választják ki az alagutat, nem abban, mit tudnak szállítani. A szabályzat alapú partner egyezteti a forgalom szelektorokat, és a megfelelő csomagokat az alagútba küldi. Az útvonal alapú partner az alagút-interfészen irányítja a forgalmat, és a döntést az útválasztási táblára hagyja. Mindkettő továbbra is tárgyal egy védelmi hatókört, ezért az alagútra mutató útvonal nem szélesíti ki azt, amit a partnerek védelemre megállapodtak.

Ez a különbség magyarázza a gyakori félhibát: az útvonal létezik, a csomagok belépnek az alagútba, és a távoli oldal eldobja őket, mert a tárgyalt szelektorok soha nem tartalmazták azt az előtagot. A telepített szabályzatok olvasása megmutatja, melyik hatókör lépett ténylegesen életbe.

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

Az átfedés, amely valóban törik

Két különböző alhálózatú iroda tisztán irányít át egy alagúton, és VLAN-számaik irrelevánsak. Két azonos alhálózatú iroda nem, mert egy adott címre vonatkozó kérésnek két lehetséges jelentése van, és az útválasztási tábla csak egyet választhat. Egy helyszín átszámozása a tiszta megoldás, és rendszerint olcsóbb az alternatíváknál, ha a DNS- és tűzfalváltozásokat is beszámítjuk.

Amikor az átszámozás lehetetlen, egy szándékos fordítási terv különböző címnézeteket mutathat mindkét oldalnak. Ez egy-az-egyhez leképezést, egyező szelektorokat, a lefordított nézetet tükröző DNS-bejegyzéseket és az átírást túlélő visszairányítást jelent. Ez egy támogatott terv valódi üzemeltetési költséggel, és nem ez az, amit egy VLAN ID megváltoztatása tesz.

Az azonos VLAN-számok mindkét végén néha egy közös sablon véletlene, és ezt a véletlent egy működő alagút okának tekinteni rossz változtatáshoz vezet, amikor később valami elromlik.

Egy feladat rétegenként, leírva

A helyi kapcsoló dönti el, mely portok osztoznak egy szórási tartományon, és VLAN-számozása helyi nyilvántartás, amelyet egyetlen másik helyszínnek sem kell ismernie. Az átjáró hitelesíti a partnert, és érvényesíti a tárgyalt védelmi hatókört. Az útválasztási tábla dönti el, hová megy tovább a visszafejtett csomag, a hozzáférési szabályzat pedig azt, hogy egyáltalán engedélyezni kellett volna-e azt a csomagot.

E feladatok szétválasztása teszi biztonságossá a változtatásokat. Egy iroda VLAN-átszámozása a helyi kapcsolót, a DHCP-tartományt és esetleg egy tűzfalzónát érint, az alagutat nem. Egy előtagváltozás az alagút szelektorait, mindkét oldal útvonalait és a hozzáférési szabályzatot érinti, a kapcsoló címkéit nem.

A visszirányok, a privát DNS és az alkalmazásidentitás követelményei ismét külön feladatok, és egyik sem úgy érkezik, hogy átmásolunk egy VLAN-számot a másik helyszínről. Egy tervezési dokumentum, amely elérhető előtagokat és engedélyezett szolgáltatásokat sorol fel, túléli egy kapcsoló cseréjét; az, amely VLAN-számokat sorol fel, nem.

Erősítse meg a helyi képet a bridge-eszközökkel, mielőtt feltételezné, hogy egy címke eléri az alagutat.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Amikor a layer-2-kiterjesztés a valódi követelmény

Egyes tervek valóban Ethernet-viselkedést igényelnek a helyszínek között: egy örökölt alkalmazás, amely szórásos felderítésre támaszkodik, egy áttelepítés, amelynek meg kell tartania egy címet, miközben egy gép mozog, vagy egy protokoll, amely layer-2-feltevéseket tartalmaz. Ezek az esetek overlay-t vagy hidalt szolgáltatást igényelnek, amely a kereteket szállítja, és akkor a VLAN-tagság, a hurok megelőzése és a hibakezelés végponttól végpontig terjedő kérdésekké válnak.

Ez sokkal nagyobb hiba tartomány, és szándékos választásnak kell lennie, nem egy fájlmegosztás működésre bírására tett kísérlet véletlen eredményének. Egy közönséges fájlszerver, adatbázis vagy webalkalmazás engedélyezett IP-útvonalat igényel, és boldogabb lesz egy alatta kifeszített szórási tartomány nélkül.

Írja le a VPN-szerződést elérhető előtagokként és engedélyezett szolgáltatásokként, és a VLAN-címkét csak ott rögzítse, ahol a helyi műveleteknek szükségük van rá. Így minden iroda átszámozhatja a saját kapcsolását anélkül, hogy minden változtatást az alagút újratervezésévé tenne.