Домашній VPN-сервер недоступний: пройдіть ланцюг NAT

Сервер відповідає в локальній мережі, правило пробросу порту виглядає правильним, а зовнішній клієнт усе одно не підключається. Проходити по одній межі за раз швидше, ніж учетверте правити правило, бо кожна межа залишає свій доказ: сторінка WAN маршрутизатора, трансляція провайдера і слухач на хості. Почніть зі сторінки адміністрування, яка вже відкрита, і закінчте тестом із мережі, якою ви не керуєте. Записуйте кожен результат по дорозі, бо послідовність і є діагностика, а запам'ятоване число не доказ. Якщо вам потрібен лише вихідний тунель, трансляція не ваша проблема: блокується тільки небажаний вхідний трафік.

Почніть зі сторінки WAN маршрутизатора

Увійдіть у маршрутизатор і читайте сторінку стану, а не список пробросу портів. Запишіть адресу WAN, інтерфейс, до якого вона належить, і тип з'єднання DHCP, PPPoE чи щось інше, що надає провайдер. Потім порівняйте цю адресу з тим, що повідомляє зовнішній сервіс, використовуючи телефон на мобільних даних, щоб спостереження не йшло назад через той самий маршрутизатор. Два числа відповідають на різні питання, і їх порівняння увесь сенс цього кроку.

Адреса WAN, відмінна від спостережуваної публічної адреси, означає, що над маршрутизатором стоїть принаймні один транслятор. Це ще не несправність, бо багато провайдерів транслюють за проєктом, і сервіс при цьому працює. Якщо обидва збігаються, адреса, найімовірніше, належить маршрутизатору, і проблема перемістилася всередину вашої мережі. У будь-якому разі запишіть пару з датою, бо провайдери перерозподіляють адреси, і порівняння з торішніми нотатками нічого не варте.

Підніміться на один хоп вище

Запустіть traceroute з самого маршрутизатора і прочитайте перші хопи. Повторювані публічні адреси, перший хоп, що відповідає приватною адресою, або адреса в межах спільного діапазону 100.64.0.0/10 усе це вказує на транслятор вище. RFC 6598 визначає цей діапазон саме для такого розгортання, тому бачити його в полі WAN сильний сигнал, а не цікавинка. Два транслятори на шляху роблять слід менш очевидним, тож читайте закономірність, а не один рядок.

Деякі провайдери показують видану адресу лише в клієнтському порталі, тож зазирніть туди, перш ніж робити висновок, що маршрутизатор бреше. Адреса в порталі, що збігається з вашим зовнішнім спостереженням, тоді як маршрутизатор повідомляє інше, найясніший доказ транслятора вище. Збережіть обидві сторінки в журналі змін, бо суперечка про те, кому належить яка межа, іде значно швидше з двома датованими знімками.

Підтвердьте слухач і проброс

Тест у локальній мережі доводить, що сервіс працює локально, і нічого не доводить про доступність ззовні. Багато маршрутизаторів відповідають на власне правило пробросу зсередини, тому тест петлі проходить, поки зовнішній шлях ще закритий. Підтвердьте, що демон прив'язаний до тієї адреси й порту, які ви припускаєте, а потім перевірте ззовні. Усе нижче лише для читання.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Якщо зовнішній тест показує, що жоден пакет не доходить до маршрутизатора, відкидання сталося вище, і жодне локальне правило це не виправить. Якщо пакети надходять, а ніщо не відповідає, наступна межа слухач або міжмережевий екран хоста. Перехоплення пакетів на хості вирішує, на що з двох ви дивитеся, і займає менше часу, ніж ще одне коло здогадів про правила. Тримайте слухач і його транспорт незмінними, поки порівнюєте, інакше наступний тест відповість на інше питання.

Змініть топологію, а не те саме правило

Коли транслятор належить провайдеру, виправлення це інший шлях, а не ще один проброс. Невеликий VPS із публічною адресою, з'єднаний вихідним тунелем з боку дому, ставить перед сервісом досяжну точку. Публічна адреса від провайдера простіша там, де вона є, і зазвичай дешевша за утримання машини. IPv6 повністю прибирає трансляцію, за умови що мережа клієнта, записи DNS і політика міжмережевого екрана це підтримують.

Динамічний DNS оновлює лише ім'я; він не створює доступності, а спрямування на спільну адресу відправляє клієнтів до шлюзу провайдера, яким користуються й інші абоненти. Така відмова виглядає точно як мертвий сервер, тому запис із попередніх кроків важливий. Запишіть, на яку адресу розв'язалося ім'я, коли тест не вдався, і тримайте відповідь разом із результатом тесту.

Перепишіть план навколо межі, якою ви керуєте: слухач, тунель і маршрути. Залишайте старий проброс на місці лише доти, доки він ще описує щось правдиве, бо правило, яке вже не відповідає топології, гірше за відсутність правила. Запишіть, який рівень насправді блокував і який доказ це показав. Інакше наступна людина, яка відкриє сторінку адміністрування, повторить кожен крок цього шляху від початку.