Кліент WireGuard не можа дасягнуць кліента OpenVPN?

Абодва тунэлі падключаюцца, кожны кліент дасягае шлюза, і ў той момант, калі адзін спрабуе адрас другога, пакеты знікаюць. Ні з адным з рукапацісканняў няма нічога не так, і колькасць перазапушчаных ключоў гэтага не зменіць. Шлюз трымае звычайныя незашыфраваныя IP-пакеты паміж двума сваімі інтэрфейсамі, таму пратаколам зусім не трэба разумець адно аднаго; ім патрэбныя тры рэчы, якіх не дае ніводнае рукапацісканне. Пакрыццё пункта прызначэння на кліенце-крыніцы, валоданне крыніцай на шлюзе і зваротны шлях на далёкім баку. Сімптом аднолькавы для ўсіх трох, таму іх дыягнастуюць разам.

Сімптому не хапае адной часткі за раз

Гэтая схема выкарыстоўвае пул WireGuard 10.71.0.0/24 на wg1 і пул OpenVPN 10.72.0.0/24 на tun1, прычым абодва завяршаюцца на адным шлюзе. Запыт у тэсце ідзе з 10.71.0.5 на HTTPS на 10.72.0.30. Кожны крок ніжэй датычыць гэтага аднаго патоку. Кожная праверка мае адметную прыкмету адмовы, хоць карыстальнік перажывае іх аднолькава, і звычайна адначасова не хапае толькі аднае з трох.

Пачніце з пацверджання, што абодва пулы сапраўды знаходзяцца на гэтым шлюзе і што пераадрасацыя ўключана ў прасторы імёнаў, дзе жывуць тунэлі. Шлюз, які завяршае абодва пратаколы ў розных прасторах імёнаў, нічога паміж імі не перасылае, і гэта варта выключыць, перш чым чытаць якую-небудзь канфігурацыю суседа.

Пашырце пакрыццё пункта прызначэння даччынага вузла

На кліенце WireGuard існуючы запіс суседа павінен выбраць шлюз для пункта прызначэння OpenVPN, гэта значыць прэфікс пункта прызначэння мусіць з’явіцца ў спісе дазволеных гэтага суседа. Яго даданне не стварае другі тунэль; яно змяняе, якога суседа выбірае кліент, калі шукае гэты адрас, і з wg-quick маршрут звычайна ідзе за спісам аўтаматычна.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

Захавайце валоданне крыніцай на шлюзе

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

AllowedIPs = 10.71.0.5/32

Чытайце гэты запіс як заяву аб валоданні, а не як зручнасць маршрутызацыі. Усё астатняе, да чаго кліенту трэба дасягнуць, належыць да спіса пунктаў прызначэння кліента, а не да ўяўлення шлюза пра тое, што гэтаму суседу дазволена дасылаць.

Дайце баку OpenVPN зваротны маршрут

Цэлі цяпер патрэбны маршрут назад да крыніцы WireGuard, і для кліентаў з пула ён звычайна прыходзіць як праштурханы маршрут ад сервера OpenVPN. Штурхайце яго толькі тым кліентам, якім ён сапраўды патрэбны, і пацвердзіце на кліенце, што ён прыняты, замест таго каб меркаваць, што дырэктыва прымянілася.

push "route 10.71.0.0 255.255.255.0"

Размеркаванне маршрутаў — гэта не аўтарызацыя. Калі пункт прызначэння знаходзіцца за іншым кліентам OpenVPN, а не ў пуле, уласнае валоданне LAN гэтага кліента і патрабаванні да пераадрасацыі далучаюцца да схемы, а праштурханы маршрут — гэта толькі першая палова. Перафармулюйце патрабаванне як граф, перш чым дадаваць дырэктывы: які вузел валодае якім прэфіксам і які вузел перасылае да яго.

Дазвольце толькі тую паслугу, якую вы мелі на ўвазе

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Гэта правілы пераадрасацыі, асобныя ад правілаў праслухоўвання шлюза для дзвюх службаў VPN. Адкрыццё знешніх портаў UDP не дае дазволу на ўнутраны запыт, а дазвол на ўнутраны запыт не патрабуе неабмежаванага SSH да шлюза ці дазволу па змаўчанні на пераадрасацыю. Уласны міжсеткавы экран цэлі і адрас праслухоўвання таксама павінны супадаць, бо служба, прывязаная да loopback, адхіляе нават самы акуратна маршрутызаваны пакет. Палітыка, якая ахоплівае толькі адзін кірунак размовы, звычайна правальваецца паспяховым запытам і маўклівым адказам, і гэта самы заблытаны з трох вынікаў.

Узаемныя маршруты звычайна азначаюць, што пераклад крыніцы не патрэбны, што захоўвае адрас WireGuard на цэлі і робіць журналы чытэльнымі. Не дадавайце суцэльны masquerading праз тое, што задзейнічаны два пратаколы, і не выдаляйце існуючае правіла перакладу, не ведаючы, што ад яго залежыць. Затым праверце адзін гэты паток ад пачатку да канца і праверце таксама адну забароненую крыніцу ці порт: працоўнае рукапацісканне з кожнага боку не даказвае ні скрыжаванага маршруту, ні ізаляцыі.