Klientské VLAN, nebo tagovaný trunk: vyberte správný režim OpenVPN

Přicházejí dva požadavky s téměř stejnou formulací: umístit každého klienta VPN do zvolené VLAN, nebo přenést existující VLAN trunk přes VPN. To jsou různé produkty. Vestavěný režim OpenVPN s podporou VLAN je model přepínače pro první požadavek a není synonymem transparentního přenosu značek. Špatná volba vytvoří návrh, který vypadá nakonfigurovaně a tiše zahazuje rámce, na kterých vám záleží.

Co režim s podporou VLAN skutečně staví

Když je vlan-tagging zapnuté v nasazení TAP pouze pro server, démon modeluje své zařízení TAP a každého připojeného klienta jako porty interního přepínače. Klientské porty jsou neznačkované a jejich přiřazení k VLAN se nastavuje na serveru přes kontext vlan-pvid pro každého klienta, nikoli tím, co klient posílá. V tom je celý smysl modelu: členství je rozhodnutí na straně serveru o autentizovaném protějšku. Nic v klientském profilu nemusí vědět, do které VLAN patří.

Strana TAP serveru dostává vlastní politiku přijímání značkovaných nebo neznačkovaných rámců přes vlan-accept. Předávání uvnitř tohoto přepínače probíhá jen mezi shodnými VID, a to i když je nastaveno client-to-client, takže dva klienti v různých VLAN se přes server nedostanou k sobě, i když jsou k němu oba připojeni.

Tento model je model přístupového portu. Rámce opouštějící klienta jsou neznačkované a přiřazení vynucuje server na základě identity. Žádat notebook, aby si svůj provoz značkoval sám, znamená žádat jiný návrh.

Přiřazení musí sledovat autentizovanou identitu klienta, ne hodnotu, kterou klient nabízí o sobě. Vynechané přiřazení také není stav karantény: klient skončí na výchozím PVID, takže chybějící záznam ccd je tiché rozhodnutí politiky, ne neutrální.

Co místo toho vyžaduje transparentní trunk

Přenos už označkovaných rámců od konce ke konci začíná vypnutím zpracování s podporou VLAN. Model přepínače a zachování značek jsou alternativy a zapnutí obou žádá, aby jedna funkce dělala práci druhé.

Vypnutí je jen začátek. Most v každém koncovém bodě a fyzické porty přepínače se musí shodnout, které VLAN jsou povolené, která značka je nativní a jak se zachází s neznačkovanými rámci. Rozšíření neomezeného trunku vystaví mnohem více broadcastových domén, než ty dvě, které jste chtěli propojit.

Velikost rámce potřebuje vlastní rozpočet. Značkovaný ethernetový rámec plus zapouzdření je větší než číslo užitečné zátěže, které lidé kopírují z návodu, a MTU, které stačilo pro routovaný tunel, není důkazem, že cesta trunku funguje.

Tři podmínky, které rozhodují odpověď

Za prvé, podporuje klientská platforma TAP vůbec? Android a iOS ne a podpora macOS je omezená, takže flotila mobilních uživatelů vylučuje kterýkoli návrh s TAP bez ohledu na uspořádání VLAN. Routovaná relace TUN přenáší IP pakety, ne ethernetové rámce, a žádná konfigurace VLAN na serveru to nezmění. Zkontrolujte flotilu dřív, než navrhnete topologii, protože tato podmínka je ta, kterou nelze obejít. Je to také podmínka, která se nejčastěji odhalí po dokončení práce na přepínači.

Za druhé, kdo přiřazuje VLAN? Pokud je odpověď „server, podle toho, kdo se autentizoval“, model přepínače sedí. Pokud je odpověď „stávající infrastruktura přepínačů se značkami, které už existují“, potřebujete návrh s trunkem.

Za třetí, jak velká část sítě má být dostupná? Model přepínače udržuje každého klienta konstrukčně v jedné VLAN. Návrh s trunkem je most a špatně nakonfigurovaný most spojuje broadcastové domény, které měly zůstat oddělené.

Ověření vaší volby

Připojte jednoho klienta, který má být v povolené VLAN, a jednoho, který nemá, a pak testujte z reálného koncového bodu, ne ze serveru samotného. Dostupnost ze strany serveru dokazuje, že most nebo přepínač existuje; nedokazuje, do které VLAN klient přistál.

ip -d link show tap0
bridge vlan show

Na serveru druhý příkaz ukazuje členství v VLAN u každého portu mostu, včetně toho, zda je port značkovaný. Porovnejte to se zamýšleným přiřazením, než začnete ladit cokoli nad druhou vrstvou.

Zaznamenejte, který ze dvou návrhů nasazení používá. Poznámka „s podporou VLAN“ je nejednoznačná a další inženýr bude předpokládat tu variantu, kterou se naučil první. Referenční příručka OpenVPN k VLANdefinuje chování přepínače a kontext pro jednotlivé klienty a je nejkratší cestou k ověření, který model provozujete.