Праца OpenVPN праз TCP і UDP з аднаго хоста
Да 2.7 адзін працэс займае адзін транспарт. Параўнайце пару TAP з мостам, дзве падсеткі TUN і агульны пул, затым падбярыце профіль пад свайго слухача.
Сеткі, якія дазваляюць толькі TCP 443, існуюць побач з сеткамі, якія спакойна прапускаюць UDP, і адзін сервер павінен абслугоўваць абедзве. Профіль з proto udp адказвае другой групе і церпіць няўдачу на першай, а змяненне таго ж канфігу да proto tcp не стварае другога слухача. Дырэктыва выбірае адзін транспарт для аднаго працэса. Усё астатняе вынікае з гэтага абмежавання.
Альбо вы запускаеце больш за адзін працэс, альбо запускаеце версію, якая можа адразу прывязаць некалькі сокетаў.
Да 2.7 адзін працэс прывязвае адзін транспарт
Супольная версія OpenVPN прывязвае сокет, апісаны proto , і гэтая дырэктыва выбірае адзіны транспарт для асобніка. TCP і UDP — розныя стэкі, таму адзін і той жа нумар порта можа быць заняты абодвума адначасова, але не адным працэсам. Таму лінія 2.6 дае вам адзін транспарт на дэман. OpenVPN 2.7 зняў гэтае абмежаванне для сервераў, якія могуць прывязаць некалькі сокетаў праз некалькі --local у адным працэсе.
Праверце версію, перш чым праектаваць вакол любога з двух адказаў, бо лад 2.7 — гэта іншая аперацыйная мадэль з уласным сінтаксісам канфігурацыі. Кіраўніцтва, напісанае для 2.6, апісвае два працэсы, нават калі гэтага не гаворыць.
Тры спосабы запуску двух асобнікаў
З інтэрфейсамі TAP запускайце адзін асобнік на транспарт і злучыце дзве прылады tap мостам на хосце. Абодва наборы кліентаў апынаюцца ў адным шырокавяшчальным дамене, што дазваляе аднаму пулу адрасоў пакрываць іх і захоўвае працу пратаколаў, залежных ад шырокавяшчання. З TUN мост недаступны, таму найпрасцейшае размеркаванне дае кожнаму асобніку сваю падсетку і дазваляе маршрутызацыі трымаць два наборы кліентаў асобна. Трэці варыянт захоўвае адзін пул, прымушаючы кожны асобнік выклікаць скрыпт learn-address , які ўсталёўвае маршрут /32 для кліента праз прыладу гэтага асобніка.
Менавіта гэты трэці лад просяць людзі і менавіта ён патрабуе найбольшай асцярожнасці, бо скрыпт становіцца часткай шляху даных і павінен правільна апрацоўваць падзеі дадання, абнаўлення і выдалення.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Трымайце два асобнікі асобна
Кожнаму асобніку таксама патрэбны асобны порт або адрас, асобны файл стану і асобная прылада журнала. Два дэманы, якія дапісваюць у адзін файл стану, даюць вывад, які немагчыма прачытаць падчас інцыдэнту, а менавіта тады ён і патрэбны. Калі другі асобнік прывязвае пэўны адрас, гэты адрас павінен існаваць на хосце на момант запуску працэса; інакш ён завершыцца з памылкай прывязкі, перш чым сказаць што-небудзь пра ключы.
Называйце юніты і профілі так, каб транспарт быў відавочны з імя файла . Наступны аператар не павінен адкрываць канфіг, каб даведацца, які з іх TCP.
Падбярыце профіль пад слухача
Сервер, які запускае proto tcp , чакае кліенцкі профіль з proto tcp-client , а профіль, які ўсё яшчэ нясе proto udp супраць гэтага слухача церпіць тайм-аўт без памылкі, на якую карыстальнік можа адрэагаваць . Трымайце два профілі, калі разгортванне прапануе абодва транспарты, і пазначайце іх так, каб падтрымка бачыла, які з іх спрабавалі. Адзін нумар порта не апісвае транспарт.
Правілы фаервала ідуць па тым жа падзеле: правіла для UDP 1194 нічога не кажа пра TCP 1194, а правіла для адрасу не пакрывае іншага слухача.
Спачатку прачытайце погляд сервера
Пачніце з ss -lntup на серверы і пераканайцеся, што з'яўляюцца і TCP-, і UDP-слухач. Затым падключыце па аднаму кліенту кожнага віду і праверце вывад стану на наяўнасць двух запісаў з рознымі адрасамі. Калі сокеты ёсць, а кліент не прыходзіць, шлях або фаервал адхіляе пакеты раней, чым дэман іх убачыць.
Сокет, які ніколі не з'яўляецца, — гэта праблема канфігурацыі або прывязкі, а сокет, які з'яўляецца, але ніколі не запісвае злучэнне, — праблема фільтрацыі. З боку кліента яны выглядаюць аднолькава, таму погляд самога сервера ідзе першым. Памятайце, што TCP нясе блакаванне пачатку чаргі, таму яго прапанова — гэта захад дасягальнасці, а не паляпшэнне для кліентаў з чыстым шляхам UDP.