Kliens VLAN-ok vagy címkézett trunk: válassza a megfelelő OpenVPN módot

Két kérés érkezik szinte azonos megfogalmazással: tegyen minden VPN-klienst egy kiválasztott VLAN-ba, vagy vigyen át egy meglévő VLAN trunkot a VPN-en. Ezek különböző termékek. Az OpenVPN beépített VLAN-tudatos módja kapcsolómodell az első kéréshez, és nem az átlátszó címketovábbítás szinonimája. A rossz választás olyan tervet ad, amely konfiguráltnak látszik, és csendben eldobja azokat a kereteket, amelyek fontosak voltak.

Mit épít valójában a VLAN-tudatos mód

Ha a vlan-tagging be van kapcsolva egy csak kiszolgálós TAP-telepítésben, a démon a TAP-eszközét és minden csatlakozott klienst egy belső kapcsoló portjaiként modellezi. A kliensportok címkézetlenek, és VLAN-hozzárendelésük a kiszolgálón, a kliensenkénti vlan-pvid kontextuson keresztül történik, nem az alapján, amit a kliens küld. Ez a modell egész lényege: a tagság kiszolgálóoldali döntés egy hitelesített partnerről. A kliensprofilban semminek nem kell tudnia, melyik VLAN-ba tartozik.

A kiszolgáló TAP-oldala a vlan-accept segítségével saját címkézett vagy címkézetlen elfogadási szabályt kap. A továbbítás ezen a kapcsolón belül csak egyező VID-ek között történik, akkor is, ha a client-to-client be van állítva, így két különböző VLAN-ban lévő kliens nem érheti el egymást a kiszolgálón keresztül, pedig mindkettő csatlakozik hozzá.

Ez a modell hozzáférési port modell. A klienst elhagyó keretek címkézetlenek, és a hozzárendelést a kiszolgáló kényszeríti ki az identitás alapján. Ha a laptopot arra kéri, hogy maga címkézze a forgalmát, az más tervet kér.

A hozzárendeléseknek a hitelesített kliensidentitást kell követniük, nem azt az értéket, amelyet a kliens magáról kínál. Egy kihagyott hozzárendelés sem karanténállapot: a kliens az alapértelmezett PVID-re kerül, így a hiányzó ccd-bejegyzés csendes házirend-döntés, nem semleges.

Mit követel helyette az átlátszó trunk

A már címkézett keretek végponttól végpontig történő átvitele a VLAN-tudatos feldolgozás kikapcsolásával kezdődik. A kapcsolómodell és a címkék megőrzése alternatívák, és mindkettő engedélyezése azt kéri egy szolgáltatástól, hogy a másik munkáját végezze.

A kikapcsolás csak a kezdet. Minden végpont hídjának és a fizikai kapcsolóportoknak meg kell egyezniük abban, mely VLAN-ok engedélyezettek, melyik címke natív, és hogyan kezelik a címkézetlen kereteket. Egy korlátlan trunk kiterjesztése sokkal több üzenetszóró tartományt tesz ki, mint a kettő, amelyet össze akart kötni.

A keretméretnek saját keret kell. A címkézett Ethernet-keret plusz beágyazás nagyobb, mint az az adatterhelés-szám, amelyet az emberek egy útmutatóból másolnak, és az útvonalválasztott alagúthoz elég MTU nem bizonyítja, hogy egy trunk-útvonal működik.

Három feltétel, amely eldönti a választ

Először, támogatja-e a kliensplatform egyáltalán a TAP-ot? Az Android és az iOS nem, a macOS támogatása pedig korlátozott, így a mobil felhasználók állománya kizárja mindkét TAP-tervet, függetlenül attól, hogyan rendezik a VLAN-okat. Az útvonalválasztott TUN-munkamenet IP-csomagokat továbbít, nem Ethernet-kereteket, és ezen semmilyen kiszolgálóoldali VLAN-konfiguráció nem változtat. A topológia tervezése előtt ellenőrizze az állományt, mert ez a feltétel az, amelyet nem lehet megkerülni. Ez az a feltétel is, amelyre leggyakrabban a kapcsolómunkálatok befejezése után derül fény.

Másodszor, ki osztja ki a VLAN-t? Ha a válasz «a kiszolgáló, aszerint, ki hitelesítette magát», a kapcsolómodell illik. Ha a válasz «a meglévő kapcsolóinfrastruktúra, már létező címkékkel», a trunk-terv kell.

Harmadszor, a hálózat mekkora része legyen elérhető? A kapcsolómodell szerkezetileg egy VLAN-ban tartja az egyes klienseket. A trunk-terv híd, és a rosszul konfigurált híd olyan üzenetszóró tartományokat köt össze, amelyeknek külön kellett volna maradniuk.

A választott megoldás próbája

Csatlakoztasson egy klienst, amelynek az engedélyezett VLAN-ban kell lennie, és egyet, amelynek nem, majd a valódi végponttól teszteljen, ne magától a kiszolgálótól. A kiszolgálóoldali elérhetőség bizonyítja, hogy a híd vagy a kapcsoló létezik; azt nem bizonyítja, melyik VLAN-ba került a kliens.

ip -d link show tap0
bridge vlan show

A kiszolgálón a második parancs minden hídport VLAN-tagságát mutatja, beleértve azt is, hogy a port címkézett-e. Hasonlítsa ezt a szándékolt hozzárendeléshez, mielőtt bármit is hibakeresne a második réteg felett.

Jegyezze fel, melyik tervet használja a telepítés. A «VLAN-tudatos» megjegyzés kétértelmű, és a következő mérnök azt fogja feltételezni, amelyiket először tanulta. Az OpenVPN VLAN-referenciameghatározza a kapcsoló viselkedését és a kliensenkénti kontextust, és ez a legrövidebb út annak megerősítéséhez, melyik modellt futtatja.