Клиент на 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 до портата или стандардна дозвола при препраќање. И сопствениот firewall на одредиштето и адресата за слушање мора да се совпаѓаат, бидејќи услуга врзана за loopback го одбива и највнимателно насочениот пакет. Политика што покрива само една насока од разговорот обично пропаѓа со успешно барање и тивок одговор, што е најзбунувачкиот од трите исходи.

Взаемните рути обично значат дека не е потребен превод на изворот, што ја зачувува адресата WireGuard кај одредиштето и ги прави логовите читливи. Не додавајте сеопфатно masquerading затоа што се вклучени два протокола, и не отстранувајте постоечко правило за превод без да знаете што зависи од него. Потоа проверете го единечниот тек од почеток до крај и тестирајте и еден забранет извор или порта: ракување што работи на секоја страна не докажува ниту вкрстена рута, ниту изолација.