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