Да ли 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 зато што су укључена два протокола, и не уклањајте постојеће правило превода без знања шта од њега зависи. Затим проверите једини ток од почетка до краја и тестирајте и један забрањени извор или порт: руковање које ради на свакој страни не доказује ни укрштену путању ни изолацију.