Адзін Pi, два асобнікі OpenVPN: што чытае кожны юніт
Два дэманы OpenVPN на адным Pi чытаюць розныя файлы канфігурацыі і выходзяць праз розныя хукі. Пабудуйце схему кожнага асобніка, затым асобна праверце шлях карыснай нагрузкі.
Падлічыце працэсы OpenVPN перш чым кранаць профіль. Pi, які прымае вандроўных карыстальнікаў і адначасова падключаецца да вышэйшага сэрвісу, запускае два дэманы, і кожны з іх чытае файл канфігурацыі, выбраны імем асобніка, якое вы ўвялі. Затым упакаваныя шаблоны даюць кожнаму дэману свой працоўны каталог, свой файл стану выканання і сваю прыладу тунеля. Калі памыліцца з гэтым падзелам, вы правядзяце вечар, змяняючы правільную наладу ў файле, які працуючы працэс ніколі не адкрывае.
Кожнае імя асобніка выбірае свой файл
У файлах юнітаў, якія пастаўляюцца з OpenVPN 2.6, аргументы запуску змяшчаюць запаўняльнік асобніка, які запоўніцца тэкстам пасля знака @. Шаблон сервера працуе з каталога канфігурацыі сервера і супастаўляе свой аргумент з %i.conf там, а шаблон кліента робіць тое ж самае з каталога кліента. Такім чынам, [email protected] чытае admits.conf у каталогу сервера, а [email protected] чытае uplink.conf у каталогу кліента, і ні адно з гэтых імёнаў не мае сэнсу ў іншым каталогу.
Праверце супастаўленне на машыне, замест таго каб меркаваць, што пакет захаваў стандартныя налады вышэйшага ўзроўню. Дапаўненне дыстрыбутыва можа цалкам замяніць працоўны каталог або аргумент канфігурацыі.
systemctl cat [email protected]
systemctl cat [email protected]Прачытайце радок WorkingDirectory і аргумент канфігурацыі ў гэтым вывадзе, бо толькі ўключаны юніт вырашае, які файл загрузіцца. Дапаўненне, якое дадае --config да ExecStart, перамагае шаблон нават тады, калі шлях шаблона выглядае правільным. Запытайце шляхі фрагмента і дапаўнення, калі хочаце ведаць, ці дзейнічае лакальнае пераазначэнне. Калі абедзве ролі вядуць да аднаго файла, у вас адзін працэс, які спрабуе быць і серверам, і кліентам, і позняя опцыя ў гэтым файле ціха перамагае.
Лакальны транспарт і перанакіраваная нагрузка трапляюць у розныя хукі
Шыфраванае злучэнне сервера з кожным вандроўным карыстальнікам ствараецца на самім Pi, таму яго знешнія адказы выходзяць праз лакальны хук вываду. Злучэнне кліента з яго вышэйшым партнёрам таксама з'яўляецца лакальна створаным вывадам, хоць і дасягае аддаленай сеткі. Перанакіраваная нагрузка — гэта трэцяя катэгорыя, і ядро супастаўляе яе толькі пасля таго, як ужо выбрала выходную прыладу для пакета.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Правіла, якое супастаўляе выходны інтэрфейс у ланцугу перанакіравання, можа дазволіць або адкінуць пакет, які маршрутызацыя ўжо прызначыла гэтаму інтэрфейсу, але яно ніколі не выбірае інтэрфейс. Калі адзін хост завяршае адзін тунель і пачынае іншы, палітыка, якая адпраўляе карыстальніцкую нагрузку ў вышэйшы тунель, і палітыка, якая абараняе ўласныя шыфраваныя адказы Pi, — гэта асобныя рашэнні. Яны выпадкова аказваюцца на адным фізічным сеткавым адаптары, таму іх і блытаюць.
Гэтае адрозненне тлумачыць звычайную палову-няўдачу. Карыстальнікі падключаюцца, рукапоціск завяршаецца, а іх трафік усё яшчэ выходзіць не тым шляхам, бо рукапоціск быў лакальным, а нагрузка — перанакіраванай, і правяралі толькі адно з двух.
Імпартаваны маршрут можа паглынуць адказы вашым карыстальнікам
Налада бяспекі профілю кліента вырашае, што вышэйшы ўзровень можа прапхнуць у табліцу маршрутызацыі Pi, і шырокае перанакіраванне — гэта опцыя, якая робіць працуючы хост з дзвюма ролямі зламаным. Калі прапхнуты маршрут ахоплівае публічныя адрасы вандроўных карыстальнікаў, адказы, якія сервер стварае для іх, могуць пайсці новым маршрутам у вышэйшы тунель замест выхаду праз базавы ўзровень. Людзі часта пацвярджаюць, што тунель да правайдэра ўсё яшчэ працуе, і спыняюцца на гэтым, бо гэты трафік — уласны транспарт тунеля, і ён працягвае ісці, пакуль усё астатняе працуе няправільна.
Палітыка на аснове крыніцы або пазнакі — гэта спосаб трымаць два патоку асобна. Linux-опцыя пазнакі у OpenVPN ставіць на ўласныя шыфраваныя пакеты дэмана пазнаку міжсеткавага экрана, якую правіла маршрутызацыі можа затым адправіць у асобную табліцу. Адрасы крыніцы працуюць гэтак жа добра, калі знешнія адказы сервера заўсёды выходзяць з аднаго адраса базавага ўзроўню. Любы падыход патрабуе сапраўдных маршрутаў у табліцы, якую ён выбірае, і выключэння для канчатковай кропкі правайдэра, інакш сам тунель перастане ўзнімацца.
Спытайце ядро пра шлях, які адказ фактычна пройдзе, перш чым пісаць любое правіла. Адрасы ніжэй — гэта запаўняльнікі для адраса базавага ўзроўню Pi і публічнага адраса аднаго вандроўнага карыстальніка.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Праверце падзел, затым спыняйце ролі па чарзе
Праверце тры патоку асобна, бо працуючы рукапоціск нічога не даказвае пра два іншыя. Прыміце новае ўваходнае злучэнне, адпраўце адну дазволеную праграму праз вышэйшы выхад і пераканайцеся, што абодва працэсы ўсё яшчэ дасягаюць сваіх партнёраў.
Затым спыніце ролю кліента і паглядзіце, што захоўвае роля сервера. Гэта самы танны спосаб знайсці правіла маршруту або пазнакі, якое прызначалася для аднаго асобніка і было прымянёна да абодвух.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerВы хочаце ўбачыць, што слухач усё яшчэ прывязаны, прылада тунеля ўсё яшчэ прысутнічае, а журнал свабодны ад новых памылак, пакуль роля кліента спынена. Калі спыненне кліента таксама пераразае адказы сервера існуючым карыстальнікам, абедзве ролі дзеляць нешта, што павінна было быць абмежавана адной з іх. Запішыце, якога асобніка, якога файла канфігурацыі і якога ўладальніка патоку датычылася кожная змена, бо наступны чалавек, які будзе адладжваць гэты хост, інакш паўторыць тое ж адкрыццё з нуля.