Клиентски VLAN или маркиран trunk: изберете правилния режим на OpenVPN

Две заявки пристигат с почти еднаква формулировка: поставете всеки VPN клиент в избран VLAN или пренесете съществуващ VLAN trunk през VPN. Това са различни продукти. Вграденият режим на OpenVPN с поддръжка на VLAN е модел на комутатор за първата заявка и не е синоним на прозрачно пренасяне на тагове. Грешният избор създава дизайн, който изглежда конфигуриран и тихо изхвърля кадрите, които са ви важни.

Какво всъщност изгражда режимът с поддръжка на VLAN

Когато vlan-tagging е включен при TAP внедряване само за сървър, демонът моделира своето TAP устройство и всеки свързан клиент като портове на вътрешен комутатор. Клиентските портове са без таг, а връзката им с VLAN се задава на сървъра чрез контекста vlan-pvid за всеки клиент, а не чрез нещо, което клиентът изпраща. Това е целият смисъл на модела: членството е решение от страна на сървъра за удостоверен партньор. Нищо в профила на клиента не трябва да знае към кой VLAN принадлежи.

Страната TAP на сървъра получава своя политика за приемане на маркирани или немаркирани кадри чрез vlan-accept. Препредаването в този комутатор се случва само между съвпадащи VID, включително когато е зададен client-to-client, така че два клиента в различни VLAN не могат да се достигнат през сървъра, въпреки че и двата са свързани към него.

Този модел е модел на порт за достъп. Кадрите, напускащи клиента, са без таг, а връзката се налага от сървъра въз основа на идентичност. Да поискате от лаптопа сам да маркира трафика си означава да поискате друг дизайн.

Присвояванията трябва да следват удостоверената идентичност на клиента, а не стойност, която клиентът предлага за себе си. Пропуснато присвояване също не е състояние на карантина: клиентът попада на PVID по подразбиране, така че липсващият запис в ccd е тихо политическо решение, а не неутрално.

Какво вместо това изисква прозрачен trunk

Пренасянето на вече маркирани кадри от край до край започва с изключване на обработката с поддръжка на VLAN. Моделът на комутатор и запазването на тагове са алтернативи и включването на двете иска една функция да върши работата на другата.

Изключването е само началото. Мостът във всяка крайна точка и физическите портове на комутатора трябва да се съгласуват кои VLAN са разрешени, кой таг е нативен и как се обработват немаркираните кадри. Разширяването на неограничен trunk излага много повече широкомовни домейни от двата, които сте искали да свържете.

Размерът на кадъра се нуждае от собствен бюджет. Маркиран Ethernet кадър плюс инкапсулация е по-голям от числото за полезен товар, което хората копират от ръководство, а MTU, който е бил добър за маршрутизиран тунел, не е доказателство, че пътят на trunk работи.

Три условия, които решават отговора

Първо, поддържа ли клиентската платформа TAP изобщо? Android и iOS не поддържат, а поддръжката на macOS е ограничена, така че парк от мобилни потребители изключва всеки дизайн с TAP, независимо как са подредени VLAN. Маршрутизираната TUN сесия пренася IP пакети, а не Ethernet кадри, и никаква конфигурация на VLAN от страна на сървъра не променя това. Проверете парка, преди да проектирате топологията, защото това условие е единственото, което не може да бъде заобиколено. То е и условието, което най-често се открива след приключване на работата по комутатора.

Второ, кой присвоява VLAN? Ако отговорът е «сървърът, въз основа на това кой се е удостоверил», моделът на комутатор е подходящ. Ако отговорът е «съществуващата инфраструктура от комутатори, с тагове, които вече съществуват», ви трябва дизайн с trunk.

Трето, каква част от мрежата трябва да бъде достъпна? Моделът на комутатор по конструкция държи всеки клиент в един VLAN. Дизайнът с trunk е мост, а неправилно конфигуриран мост съединява широкомовни домейни, които е трябвало да останат разделени.

Тестване на направения избор

Свържете един клиент, който трябва да е в разрешения VLAN, и един, който не трябва, след което тествайте от реалната крайна точка, а не от самия сървър. Достъпността от страна на сървъра доказва, че мостът или комутаторът съществува; тя не доказва в кой VLAN е попаднал клиентът.

ip -d link show tap0
bridge vlan show

На сървъра втората команда показва членството в VLAN за всеки порт на моста, включително дали портът е маркиран или не. Сравнете това с присвояването, което сте имали предвид, преди да отстранявате проблеми на каквото и да е над второ ниво.

Запишете кой от двата дизайна използва внедряването. Бележка «с поддръжка на VLAN» е двусмислена и следващият инженер ще приеме онзи вариант, който е научил първи. Справката на OpenVPN за VLANописва поведението на комутатора и контекста за всеки клиент и е най-краткият път да потвърдите кой модел използвате.