Клиентски 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 референцатаго дефинира однесувањето на комутаторот и контекстот за секој клиент, и тоа е најкраткиот пат да потврдите кој модел го извршувате.