Клиент на 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 заради това, че участват два протокола, и не премахвайте съществуващо правило за превод, без да знаете какво зависи от него. След това проверете единствения поток от край до край и тествайте също един забранен източник или порт: работещо ръкостискане от всяка страна не доказва нито кръстосания маршрут, нито изолацията.