Един сървър TAP или няколко? OpenVPN клиенти върху мост

Няколко TAP клиента не изискват по един сървърен процес, един UDP порт и едно TAP устройство на хоста за всеки. Един OpenVPN сървър в режим Ethernet може да приеме много удостоверени клиенти и да ги свърже към един мост, а това е документираният начин за разширяване на сегмент от 2-ро ниво. Дизайнът с един процес е този, който ръководството документира, и обикновено е правилната настройка по подразбиране.

Истинският въпрос е дали тези клиенти трябва да споделят този сегмент. Броят на процесите не отговаря на него, защото свойствата на изолация идват от топологията, а не от това колко демона работят. Останалото от това сравнение е за двете топологии и какво улеснява всяка от тях.

Две архитектури, а не две настройки

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

Мостовото внедряване с TAP прави клиентите членове на един Ethernet сегмент. Те виждат пакетите за широко излъчване, могат да се намират един друг чрез ARP и зависят от политиката на моста и защитната стена, а не от маршрутизацията, за да останат разделени. Това е полезно, когато клиентите трябва да изглеждат все едно са включени в същия комутатор.

Следователно сравнението е за това до какво трябва да достигат клиентите, а не за производителност. Изберете първо нивото, после решете колко процеса да го обслужват.

Какво прави помощникът server-bridge

Помощникът server-bridge конфигурира режима Ethernet за много клиенти. Неговата форма с адресен пул приема шлюза, мрежовата маска и отделен диапазон в рамките на мостовата подмрежа, например шлюз 192.168.50.1 с пул от 192.168.50.160 до 192.168.50.199.

Резервирайте този диапазон извън всяко друго DHCP или статично назначаване. Помощникът разпределя адреси от него, но не се координира с друг разпределител в същия сегмент, а два припокриващи се пула дават дублирани адреси, които изглеждат като случайни проблеми със свързаността. Запишете резервирания диапазон в адресния план на обекта, за да не го използва отново следващият човек. Коментар в конфигурацията на сървъра е лоша замяна на такъв запис.

Съществува форма с DHCP прокси за внедрявания, при които външен сървър раздава адреси. Тя има свои предварителни условия и смесването на двете форми създава точно конфликта, за който предупреждава документацията. Изберете един разпределител за мостовата подмрежа.

Изолацията не идва от броя процеси

Осем OpenVPN процеса, свързани към един и същ неограничен мост, все още споделят един домейн за широко излъчване. Клиентите могат да изпращат ARP един към друг през моста и броят на слушателите не промени нищо в това.

Ако изискването е групи клиенти да не се виждат на 2-ро ниво, дизайнът се нуждае от отделни мостове или VLAN връзки заедно с правилата за достъп, които вървят с тях. Това е решение за мрежов дизайн и е същото решение независимо дали участва един сървърен процес, или осем. Филтрирането на моста може да ограничи част от трафика, но не създава отделни домейни за широко излъчване. Третирайте го като допълнение към сегментирането, а не като негова замяна.

Ако изискването е само клиентите да достигат определени IP услуги, маршрутизираният TUN дизайн обикновено е по-прост от мостове плюс филтриране. Всеки клиент получава своя връзка и политиката живее в правилата за маршрутизация и защитна стена, а не във вътрешностите на моста.

Кога няколко процеса все пак са правилни

Отделните процеси могат да бъдат оправдани от оперативни нужди: различни системи за удостоверяване, различни сертифициращи органи, отделни цикли на обновяване или несъвместими набори от опции. Това са реални причини и те не зависят от броя клиенти.

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

След това проверете дизайна с няколко клиента едновременно. Проверете дали адресите са уникални, дали желаният трафик между клиенти работи и дали двойка, която не трябва да комуникира, наистина не може. Успешният ping от един клиент не проверява нищо от дизайна за много клиенти.

Прочетете моста и режима на сървъра от работещия хост, преди да се доверите на диаграмата. Конфигурацията, която има значение, е тази, която ядрото и демонът действително са заредили, и тя е също тази, която рецензентът може да провери.