Подвійний NAT і ваш VPN: клієнт працює, сервер — ні
Два маршрутизатори, що перекладають адреси, рідко зупиняють вихідний VPN-клієнт. Розмістити сервер за ними складніше, особливо коли зовнішній шар — NAT операторського рівня.
Ваш маршрутизатор стоїть за іншим маршрутизатором, адреса WAN приватна, а VPN-клієнт усе одно підключається. Ця комбінація дивує тих, хто чекає, що подвійний NAT зламає тунелі, але саме вихідні з'єднання переклад обробляє найкраще. Розміщення VPN-сервера за тими самими двома шарами — це випадок, який зазвичай не працює. Намалюйте напрямок з'єднання, перш ніж щось змінювати.
Спочатку намалюйте напрямок з'єднання
Відкрийте сторінку стану внутрішнього маршрутизатора і запишіть його адресу WAN, потім порівняйте її з адресою, яку повідомляє вам якась публічна служба. Якщо вони різняться, між вашим маршрутизатором та інтернетом стоїть принаймні один перекладач. Якщо адреса WAN потрапляє в 100.64.0.0/10, зовнішній перекладач, найімовірніше, належить вашому провайдеру, і ви ним не керуєте. Ці два факти визначають, який із подальших кроків узагалі може спрацювати.
curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1
Подвійний NAT — це не подвійний VPN. Переклад переписує адреси й порти; він не додає другого зашифрованого тунелю і нічого не шифрує. Розділяти ці дві ідеї важливо, бо рішення зовсім різні, і одне з них вимагає розмови з провайдером, а не сторінки налаштувань.
Вихідний напрямок: клієнт питає, перекладачі зіставляють
Вихідний тунель починається з пакета від вашої машини, тож кожен перекладач може створити зіставлення і впустити відповідь назад. Протокол, порт і таймери простою визначають, чи проживе це зіставлення достатньо довго, щоб бути корисним. Більшість споживчих маршрутизаторів дають раду без будь-якого налаштування.
Збої, які справді з'являються, зазвичай стосуються тайм-аутів і підтримки протоколів, а не кількості маршрутизаторів. Тунель, що падає після кількох хвилин тиші, — це зіставлення, яке спливає, а keepalive є стандартною відповіддю. IPsec має стандартні розширення NAT-traversal, тож твердження, що він не може пройти крізь переклад, просто хибне. Якщо тунель узагалі не встановлюється, подивіться на кінцеву точку й облікові дані, перш ніж звинувачувати топологію.
wg show
ping -c3 10.8.0.1
Зупиніться, якщо вихідний тунель працює з однієї мережі й не працює з іншої. Це порівняння про мережі, а не про кількість маршрутизаторів.
Вхідний напрямок: переспрямування охоплює лише ваше власне обладнання
Розміщення сервера — це зворотний напрямок: нове з'єднання надходить з інтернету й має дістатися вашої машини крізь кожен шар. Правило переспрямування порту на внутрішньому маршрутизаторі допомагає лише тоді, коли зовнішній перекладач теж доставляє цей трафік вам. Повторення локального правила не дає контролю над обладнанням провайдера.
nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'
Порівняйте адресу WAN внутрішнього маршрутизатора з публічною адресою, яку ви спостерігали, і занотуйте, звідки взялося кожне значення. Якщо адреса WAN приватна або в спільному діапазоні, зовнішній шар виконує переклад, який ви не можете налаштувати. Запитайте провайдера, яку вхідну доступність він підтримує, перш ніж витратити цілий вечір на правила, що не можуть набути чинності. Видалення маршрутизатора або широке вимкнення брандмауера — це не діагноз і поганий обмін за один відкритий порт.
Зупиніться, якщо зовнішній шар належить провайдеру і він не переспрямовує. Тоді підтримувані відповіді — інший спосіб доступу або ретранслятор, а не ще одне правило з вашого боку.
Перевіряйте по одній змінній за раз
Змінюйте по одній речі за тест і записуйте результат, бо шлях із подвійним NAT має більше змінних, ніж шлях з одним маршрутизатором. Тримайте профіль і пристрій незмінними, потім порівняйте іншу мережу доступу. Зверніть увагу, чи зриваються переговори, чи падає сесія після простою або чи не працюють лише приватні призначення. Ці три спостереження вказують на три різні шари.
journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40
Перекривні приватні підмережі — це окрема пастка, яку не виправить жодна кількість перекладу. Якщо ваша домашня мережа й віддалена мережа використовують той самий діапазон, конфлікт маршрутів виникає незалежно від того, скільки перекладачів між ними. Перенумерування однієї сторони — єдина тривала відповідь.
Віддалений шлюз заслуговує на таку саму увагу, бо його правила переспрямування й зворотні маршрути можуть бути відсутньою частиною. Тунель, який проходить автентифікацію, все ще може не мати придатного шляху для програм, і цей збій з боку клієнта виглядає однаково. Огляд закінчується, коли ви можете сказати, який напрямок не працює і який шар за нього відповідає.