Двойной 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

Перекрывающиеся приватные подсети — отдельная ловушка, которую никакое количество трансляции не исправит. Если ваша домашняя сеть и удалённая сеть используют один и тот же диапазон, конфликт маршрутов возникает независимо от того, сколько трансляторов между ними. Перенумерация одной стороны — единственный долговечный ответ.

Удалённый шлюз заслуживает такого же внимания, потому что его правила перенаправления и обратные маршруты могут быть недостающей частью. Туннель, который проходит аутентификацию, всё ещё может не иметь пригодного пути для приложений, и этот сбой со стороны клиента выглядит одинаково. Обзор заканчивается, когда вы можете сказать, какое направление не работает и какой слой за него отвечает.

Похожие статьи