Адзін сервер 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 аднаго кліента не правярае нічога ў схеме для некалькіх кліентаў.

Прачытайце мост і рэжым сервера на працуючым хаспе, перш чым давяраць дыяграме. Важная канфігурацыя — тая, якую фактычна загрузілі ядро і дэман, і менавіта яе можа праверыць рэцэнзент.