Настройка интернет-доступа через сервер, VPN и DNS: схемы, маршрутизация и диагностика

Рабочий доступ клиентов в интернет через Linux-сервер или VPN-шлюз строится из пяти частей: корректной IP-конфигурации, маршрута по умолчанию, IPv4 forwarding, NAT и разрешающих правил firewall. DNS дополняет эту цепочку, разрешая доменное имя в IP-адрес, но не исправляет ошибку маршрутизации, NAT или фильтрации.

Проверяйте путь трафика последовательно: интерфейс и адрес клиента, доступность локального шлюза, маршрут до внешнего IP, пересылку и NAT на сервере, DNS, затем VPN, прокси и HTTPS. Такой порядок быстро локализует сбой и исключает ситуацию, когда одновременно меняются DHCP, firewall и маршруты.

Примеры ниже рассчитаны на Linux-шлюз с IPv4, подсетью LAN 192.168.10.0/24, интерфейсами lan0 и wan0, nftables и systemd-resolved либо обычным resolv.conf. Замените адреса, имена интерфейсов и DNS-серверы на параметры своей схемы.

Настройка интернет-доступа через сервер: что проверить в первую очередь

Перед настройкой определите, какой узел служит default gateway для клиентов. Если им выступает маршрутизатор провайдера, сервер может работать только как DNS-сервис, прокси, мониторинг или хост приложений. Если шлюзом выступает Linux-сервер, клиенты должны отправлять на него трафик по умолчанию, а сервер должен иметь рабочий маршрут в WAN, включенную пересылку пакетов, NAT и разрешение транзитного трафика.

Не меняйте настройки по нескольким направлениям одновременно. Сначала подтвердите факт прохождения пакета до следующего узла, затем переходите к следующему уровню. Сохраните исходные ip route, правила nftables и конфигурацию VPN перед изменениями, особенно на удаленном сервере.

Минимальная цепочка прохождения трафика

При схеме с Linux-шлюзом путь запроса выглядит так:

Клиент 192.168.10.50
  -> default gateway 192.168.10.1, интерфейс lan0
  -> Linux-сервер: маршрут через wan0
  -> NAT masquerade: исходный адрес меняется на WAN-адрес сервера
  -> шлюз провайдера
  -> внешний ресурс

Ответ возвращается на WAN-адрес сервера. Таблица conntrack сопоставляет его с исходным соединением, NAT восстанавливает адрес клиента, после чего сервер отправляет пакет в LAN. Если разрешен только трафик LAN в WAN, а обратный established,related заблокирован, соединение не завершится.

DNS работает раньше HTTP-запроса: клиент спрашивает имя, например example.com, получает IP-адрес и только затем строит соединение. Успешный dig не подтверждает, что маршрут и NAT работают. Успешный ping 1.1.1.1 при неработающих именах, напротив, сужает проблему до DNS.

Базовый порядок проверки

Проверьте линк, SSID, VLAN и состояние интерфейса.
Сверьте IP-адрес, маску, default gateway и DNS на клиенте.
Проверьте доступность локального шлюза.
Проверьте маршрут к внешнему IP и доступ к нему.
На шлюзе проверьте forwarding, NAT, правила FORWARD и счетчики.
Выполните DNS-запрос через назначенный резолвер.
Проверьте HTTPS через curl -v.
Сравните результат с выключенными VPN и прокси в согласованном тестовом окне.

ip link
ip addr
ip route
ping -c 3 192.168.10.1
ping -c 3 1.1.1.1
dig example.com
curl -v https://example.com

Адрес из диапазона 169.254.x.x обычно означает, что клиент не получил корректную аренду DHCP или не видит DHCP-сервер из-за VLAN, bridge, кабеля, Wi-Fi-аутентификации либо локальной фильтрации.

Схемы подключения клиентов к интернету через сервер и VPN-шлюз

Выбор схемы зависит от точки контроля трафика. Обычный маршрутизатор требует меньше сопровождения. Отдельный Linux-шлюз дает точный контроль NAT, firewall, журналов и политик. VPN-шлюз нужен, когда удаленный клиент должен получать доступ к корпоративным ресурсам или выходить в интернет через центральную площадку.

Маршрутизатор как основной шлюз локальной сети

В простой офисной или домашней сети маршрутизатор выдает параметры DHCP, выполняет NAT и служит default gateway. Клиент получает, например, адрес 192.168.10.50/24, шлюз 192.168.10.1 и адреса DNS. Сервер в этой сети не обязан пересылать весь трафик клиентов.

На клиенте проверьте четыре параметра: IP-адрес, маску подсети, шлюз и DNS. Неправильный шлюз часто дает локальный доступ к соседним устройствам без выхода в интернет. Неверный DNS оставляет доступ по IP, но блокирует работу по доменным именам.

Linux-сервер как NAT-шлюз

У сервера два интерфейса: lan0 с адресом 192.168.10.1/24 и wan0, подключенный к провайдеру или внешнему маршрутизатору. Клиенты используют 192.168.10.1 как default gateway. На сервере требуется один корректный маршрут по умолчанию через WAN, включенный IPv4 forwarding, правило masquerade и разрешение пересылки в цепочке FORWARD.

Подсети LAN и WAN не должны пересекаться. Если LAN использует 192.168.10.0/24, не назначайте этот же диапазон на WAN или удаленной площадке VPN. Пересечение адресов создает неоднозначный маршрут и часто выглядит как случайная недоступность части ресурсов.

Для развертывания тестового или рабочего шлюза в облаке подойдет облачная инфраструктура Timeweb Cloud, где можно выделить отдельный VDS, подключить приватную сеть и проверить правила до переноса схемы в основную среду.

Интернет через VPN-шлюз

VPN меняет путь трафика между клиентом и шлюзом. В режиме full-tunnel весь клиентский IPv4-трафик направляется в туннель. В split-tunnel через туннель идут только корпоративные подсети, отдельные хосты или сервисные сети.

Для full-tunnel нужны маршрут 0.0.0.0/0 через VPN, рабочая пересылка и NAT на выходном VPN-шлюзе, разрешенный обратный трафик и доступный DNS. Для split-tunnel достаточно маршрутов только к нужным подсетям, например 10.20.0.0/16. Подробный разбор выбора маршрутов приведен в материале о направлении нужного трафика через VPN-туннель.

Прокси вместо маршрутизации всего трафика

Прокси обслуживает приложения и протоколы, которые умеют с ним работать. IP-маршрутизация и NAT пересылают пакеты для всех разрешенных протоколов. Ошибка прокси не исправляется добавлением masquerade, а отсутствие NAT не исправляется настройкой HTTP_PROXY.

Типичный признак проблемы с прокси: ping 1.1.1.1 и прямой curl --noproxy '*' https://example.com работают, браузер или пакетный менеджер выдает ошибку подключения. Проверьте HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, системные сервисы и настройки приложения.

IP-адресация, DHCP и маршрутизация между локальной сетью и интернетом

До NAT настройте адресный план. Для примера используйте LAN 192.168.10.0/24, адрес шлюза 192.168.10.1, DHCP-пул 192.168.10.100-192.168.10.200. Адреса серверов, принтеров, точек доступа и сетевого оборудования вынесите за границы пула или закрепите через DHCP reservation.

Конфликт IP, два DHCP-сервера в одном VLAN и пересекающиеся подсети дают симптомы, которые сложно отличить от ошибок firewall. Сначала устраните противоречия адресного плана, затем диагностируйте маршрутизацию.

Проверка сетевых интерфейсов и адресов

ip link show
ip addr show
ip route show
ip route get 1.1.1.1

Интерфейс должен иметь состояние UP и рабочий линк. На Linux-шлюзе проверьте адрес LAN, адрес WAN и default route. Пример ожидаемого результата для LAN:

192.168.10.1/24 dev lan0 scope global

Проверьте отсутствие двух равнозначных default route, если не используете policy routing. Несколько маршрутов по умолчанию без продуманной метрики могут отправлять ответы не через тот интерфейс, через который пришел запрос.

DHCP: автоматическая выдача параметров клиентам

DHCP выдает клиенту IP-адрес, маску, шлюз, DNS и время аренды. Для большинства локальных сетей автоматическая настройка снижает число ошибок на рабочих станциях. Статический IP и ручной DNS назначайте только при понятной причине: серверу, сетевому оборудованию, специальной политике или диагностическому сценарию.

Если клиент получил 169.254.x.x или не получил адрес, проверьте DHCP-сервис, правильность VLAN, bridge, кабель, Wi-Fi-аутентификацию и фильтрацию DHCP-пакетов. Сравните его параметры с другим устройством в том же сегменте. Если второй клиент получает корректную аренду, проблема вероятнее всего находится на первом устройстве, его порту или учетной политике.

Статическая адресация и default gateway

Адрес LAN-интерфейса шлюза должен принадлежать локальной подсети и не пересекаться с DHCP-пулом. В примере это 192.168.10.1/24. Клиенты получают или используют вручную шлюз 192.168.10.1.

На WAN обычно нужен один маршрут по умолчанию через провайдерский шлюз. Проверьте его командой:

ip route get 1.1.1.1

Вывод должен показать интерфейс WAN и ожидаемый next hop. Если пакет уже на сервере выбирает LAN-интерфейс или отсутствует маршрут, NAT не поможет.

Маршрутизация между локальной сетью и интернетом

Клиент должен знать маршрут до LAN-шлюза, сервер - маршрут до WAN-шлюза. В схеме без NAT вышестоящий маршрутизатор обязан иметь обратный маршрут к LAN-подсети через Linux-сервер. Без обратного маршрута внешняя сеть не сможет вернуть ответ клиенту с частным или внутренним адресом.

tracepath 1.1.1.1
traceroute -n 1.1.1.1
ip route get 1.1.1.1 from 192.168.10.50

Для сложных сред с несколькими интерфейсами, таблицами маршрутов и привязкой по источнику используйте отдельные правила ip rule. Практические команды собраны в шпаргалке по ip route и policy routing в Linux.

Как настроить NAT на сервере и проверить пересылку трафика

NAT позволяет клиентам с частными адресами LAN выходить через внешний адрес сервера. Он не заменяет маршрут, DHCP, DNS и правила firewall. Рабочая схема требует всех компонентов одновременно.

Включение IPv4 forwarding

Проверьте текущее состояние:

sysctl net.ipv4.ip_forward

Если вывод содержит net.ipv4.ip_forward = 0, временно включите пересылку:

sysctl -w net.ipv4.ip_forward=1

Для сохранения после перезагрузки создайте параметр в конфигурации sysctl:

net.ipv4.ip_forward = 1

После применения проверьте трафик на обоих интерфейсах. Пакет, видимый на lan0 и отсутствующий на wan0, указывает на проблему forwarding или firewall.

NAT masquerade в nftables

Ниже приведен пример для LAN 192.168.10.0/24, интерфейса LAN lan0 и динамического WAN-адреса на wan0. Имена интерфейсов замените перед применением.

table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "lan0" oifname "wan0" ip saddr 192.168.10.0/24 accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat;
    oifname "wan0" ip saddr 192.168.10.0/24 masquerade
  }
}

Правило masquerade удобно при динамическом внешнем адресе. При постоянном WAN-адресе можно использовать SNAT с явным адресом. Развернутые примеры MASQUERADE, SNAT, счетчиков и conntrack есть в статье о настройке NAT на Linux-сервере через nftables.

Проверка NAT и обратного трафика

nft list ruleset
conntrack -L
sudo tcpdump -ni lan0 host 1.1.1.1
sudo tcpdump -ni wan0 host 1.1.1.1

Запустите на клиенте ping -c 3 1.1.1.1 или curl -4 -v https://example.com. Если запрос виден на LAN, но не появляется на WAN, проверьте net.ipv4.ip_forward и цепочку FORWARD. Если запрос уходит в WAN, но ответа нет, проверьте default route сервера, доступность провайдера и внешнюю фильтрацию. Если ответ виден на WAN, но не возвращается в LAN, проверьте ct state established,related accept и conntrack.

Маршрутизируемая схема без NAT

Без NAT источником пакетов остаются реальные адреса LAN. Вышестоящий маршрутизатор должен содержать маршрут к 192.168.10.0/24 через WAN-адрес Linux-сервера. Такой вариант упрощает аудит исходных адресов и подходит для управляемых корпоративных сетей, но требует контроля обратных маршрутов на всех соседних узлах.

Не смешивайте masquerade с заявленной прозрачной маршрутизацией без ясной причины. Сначала определите, должен ли внешний сегмент видеть адреса клиентов или только адрес шлюза.

Настройка VPN-шлюза: full-tunnel, split-tunnel и безопасные маршруты

VPN-соединение проходит три независимые стадии: туннель поднимается, клиент получает маршрут, трафик проходит через шлюз. Успешный handshake подтверждает только первую стадию. Он не доказывает наличие NAT, DNS и доступа к интернету.

WireGuard: адреса, peer и AllowedIPs

Минимальная конфигурация WireGuard содержит адрес интерфейса, закрытый ключ, порт прослушивания, открытый ключ peer и список AllowedIPs. Для split-tunnel на клиенте укажите только внутренние сети, например 10.20.0.0/16. Для full-tunnel добавьте 0.0.0.0/0.

[Interface]
Address = 10.66.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 10.66.0.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = VPN_SERVER_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

При full-tunnel сохраните маршрут к публичному endpoint VPN вне туннеля. Иначе клиент может направить пакет к самому VPN-серверу внутрь еще неработающего туннеля. Проверьте состояние и маршрут:

wg show
ip route get VPN_SERVER_IP
ip route get 1.1.1.1

OpenVPN и маршруты до удаленных сетей

В OpenVPN сервер может передать маршруты через push route, направить default route через redirect-gateway и назначить DNS через push dhcp-option DNS. После подключения изучите таблицу маршрутов и фактический DNS клиента. Подключение к OpenVPN-серверу и доступ в интернет через него требуют разных настроек на сервере.

Для выхода клиентов в интернет OpenVPN-шлюзу нужны forwarding, NAT на WAN и разрешающий FORWARD, как и WireGuard-шлюзу. Если требуется связь двух LAN через туннель, настройте обратные маршруты и ограничьте доступ между сегментами по портам и назначениям.

Почему VPN подключен, но интернет не работает

Симптом	Проверка	Вероятная причина
Есть handshake, нет внешнего IP	`ip route get 1.1.1.1`	Нет маршрута `0.0.0.0/0` или нужной подсети
Маршрут через VPN есть, ответов нет	`sysctl net.ipv4.ip_forward`, `nft list ruleset`	Отключен forwarding или заблокирован FORWARD
Внешний IP доступен, домены не открываются	`dig example.com`	Недоступен VPN DNS или назначен неверный резолвер
Часть сайтов зависает	`ping -M do -s 1360 1.1.1.1`	Проблема MTU или MSS
Внутренний ресурс недоступен	`ip route get INTERNAL_IP`	Конфликт адресных диапазонов или отсутствует обратный маршрут

Сравните внешний IP до и после подключения. Если full-tunnel настроен корректно, внешний адрес должен меняться на адрес выхода VPN-шлюза. Затем проверьте DNS и HTTPS по имени.

Ограничение доступа в VPN

Выдавайте каждому peer минимально нужные маршруты. Пользовательскому VPN-клиенту редко нужен доступ ко всем RFC1918-сетям. Разделите пользовательские, серверные и административные сегменты, разрешите конкретные подсети и порты, запретите доступ к панелям управления и сервисам администрирования по умолчанию.

AllowedIPs задает маршрут и допустимые адреса peer, но не заменяет firewall. Контролируйте фактический доступ правилами nftables: например, разрешите VPN-подсети доступ к 10.20.10.0/24 на TCP 443, а соединения к административной сети 10.20.99.0/24 блокируйте.

DNS, прокси и разрешение имен при подключении через VPN

Сначала подтвердите доступность DNS-сервера по IP, затем отправьте прямой DNS-запрос, после чего проверяйте HTTPS по имени. Такой порядок отличает отказ резолвера от ошибки маршрута, TLS, прокси или фильтрации.

Проверка DNS через dig и resolvectl

resolvectl status
resolvectl query example.com
dig example.com
dig example.com @10.66.0.1
ip route get 10.66.0.1

resolvectl status показывает DNS-серверы и доменные маршруты для каждого интерфейса. Сравните ответ корпоративного DNS, DNS через VPN и публичного резолвера, если его использование разрешено политикой сети. Проверьте доступность UDP и TCP 53: часть DNS-ответов и зональных операций переходит на TCP.

Split DNS для локальных и внешних доменов

Split DNS направляет запросы к внутренней зоне, например internal.example, на DNS-сервер через VPN. Публичные имена разрешаются через обычный или централизованный внешний резолвер. Такая схема уменьшает утечки внутренних имен и не отправляет весь DNS-трафик в туннель без необходимости.

Split DNS не создает маршрут к внутреннему сервису. После успешного ответа DNS клиент все равно должен иметь IP-маршрут до адреса сервиса, а firewall должен разрешать нужный порт. Контролируйте обе части отдельно.

Прокси и переменные окружения

env | grep -i proxy
curl -v --noproxy '*' https://example.com
curl -v -x http://PROXY_HOST:PORT https://example.com

Проверьте прокси в shell, systemd unit-файлах, Docker-конфигурации, браузере, пакетном менеджере и настройках CI. Значение NO_PROXY должно включать внутренние домены, localhost и нужные подсети, если обращения к ним не должны проходить через прокси.

Ручные DNS, IP и прокси, заданные в конкретном Wi-Fi-профиле, обычно работают только для этой сети и не меняют настройки мобильного подключения. Поэтому одинаковая ошибка через Wi-Fi и мобильную сеть требует отдельной проверки VPN, приложения и системного прокси.

Диагностика сетевого доступа: от клиента до внешнего ресурса

Используйте runbook ниже без пропусков. На каждом шаге фиксируйте команду, результат и узел, на котором пакет перестал проходить. Это упрощает передачу инцидента между сетевой командой, системными администраторами и владельцами приложений.

Проверка физического и беспроводного соединения

ip link show
ethtool lan0
ip -s link show lan0

Проверьте состояние линка, согласованную скорость, ошибки приема и передачи, выбранный SSID и VLAN. При Wi-Fi-сбое после принятия пароля проверьте WPA/WPA3, корпоративный сертификат, фильтрацию MAC-адресов, лимиты точки доступа и соответствие VLAN учетной политике.

Проверка IP-адреса, шлюза и DHCP

ip addr show
ip route show
networkctl status
journalctl -u systemd-networkd --since '15 min ago'

Клиент должен иметь адрес из ожидаемой подсети, маску, маршрут по умолчанию и DNS. При адресе 169.254.x.x вернитесь к DHCP, VLAN и канальному подключению. Сравните выдачу параметров с исправным устройством в том же сегменте.

Проверка доступности шлюза и внешнего IP

ping -c 3 192.168.10.1
ping -c 3 1.1.1.1
ip route get 1.1.1.1
tracepath 1.1.1.1

Недоступный шлюз указывает на проблему LAN, VLAN, адресации или локального firewall. Доступный шлюз при недоступном внешнем IP направляет диагностику к WAN-маршруту, forwarding, NAT, фильтрации или провайдеру. Не используйте один только ICMP как окончательный тест: часть сетей фильтрует ping, хотя TCP 443 работает.

Проверка DNS и HTTPS-доступа

dig example.com
curl -4 -v https://example.com
curl -4 -I --connect-timeout 10 https://example.com

Рабочий DNS при неудачном HTTPS-запросе указывает на фильтрацию TCP 443, ошибочный прокси, TLS, неправильное время системы, MTU или политику внешнего ресурса. Проверьте время через системную службу синхронизации, сертификат в выводе curl -v и размер пакетов при подозрении на MTU.

Проверка VPN, прокси и фильтрации

wg show
ip route show
resolvectl status
nft list ruleset
env | grep -i proxy

Временно отключите VPN и прокси только для диагностического теста, если это не нарушает политику безопасности. Сравните маршрут, DNS и результат curl до и после изменения. Проверьте handshake, AllowedIPs, kill switch, правила firewall и корпоративную фильтрацию, которая может блокировать отдельный ресурс при корректной IP-конфигурации.

Наблюдение за пакетами через tcpdump

sudo tcpdump -ni lan0 host 1.1.1.1
sudo tcpdump -ni wan0 host 1.1.1.1
sudo tcpdump -ni wg0 host 1.1.1.1
sudo tcpdump -ni lan0 port 53

SYN без SYN-ACK показывает отсутствие ответа или блокировку обратного трафика. DNS-запрос без ответа сужает поиск до резолвера, маршрута к нему или UDP/TCP 53. Пакеты только на LAN указывают на forwarding или firewall, а пакеты на WAN без обратного ответа требуют проверки WAN-маршрута и внешней стороны.

Сопоставляйте захват с nft list ruleset и conntrack -L. Счетчики правил показывают, попадает ли пакет под ожидаемое разрешение, а conntrack помогает увидеть состояние соединения.

Firewall и безопасная настройка серверных сетевых запросов

Интернет-шлюз и VPN требуют явных разрешений, а не открытого транзита между всеми интерфейсами. Базовая модель: запретить входящие подключения из WAN к административным сервисам, разрешить порт VPN, разрешить трафик из доверенных подсетей в необходимые направления и пропускать обратные соединения в состоянии established,related.

Правила firewall для LAN, WAN и VPN

Разделите правила на INPUT, FORWARD и OUTPUT. В INPUT разрешите только нужное управление из административной подсети, SSH при необходимости, порт VPN на WAN и DNS на тех интерфейсах, где сервер действительно выступает резолвером. В FORWARD разрешите LAN или VPN к согласованным назначениям, затем обратный трафик. Входящие новые соединения из WAN к внутренним сегментам блокируйте.

Порядок правил влияет на результат. Более широкое правило accept, размещенное до ограничения, отменит задуманный запрет. После каждого изменения проверяйте счетчики и доступ с контрольного клиента.

Ограничение доступа клиентов

Разделите пользовательские, серверные и административные VLAN. Запретите peer-to-peer между пользовательскими устройствами, если он не требуется. Ограничьте доступ к панелям управления, базам данных, системам оркестрации и хранилищам конкретными источниками, назначениями и портами.

Логи firewall полезны для диагностики, но не включайте подробное логирование каждого пакета на высоконагруженном интерфейсе. Логируйте ограниченные правила drop с rate limit, чтобы не перегружать журнал и не скрыть значимые события.

Проверка URL-редиректов на сервере

Серверное приложение, которое загружает URL по пользовательскому вводу, должно проверять адрес до каждого фактического соединения. Проверки только исходного URL недостаточно: HTTP-редирект может перенаправить запрос на loopback, приватную сеть, link-local адрес, адрес интерфейса сервера или cloud metadata endpoint.

Проверяйте allowlist хостов после каждого HTTP-редиректа.
Повторно разрешайте имя и проверяйте полученный IP перед соединением.
Блокируйте loopback, RFC1918, link-local, multicast и внутренние служебные диапазоны.
Не доверяйте имени хоста без проверки фактического адреса назначения.
Отключайте следование редиректам, если функция не нуждается в нем.

Отключение редиректов уменьшает поверхность атаки, но не заменяет проверку конечного назначения там, где редиректы разрешены по требованиям приложения.

Контроль DNS и предотвращение обхода политик

Разрешайте клиентам DNS только через утвержденные резолверы, если политика требует централизованной фильтрации и журналирования. Учитывайте UDP и TCP 53. Для DNS через VPN проверьте, что маршрут к корпоративному резолверу действительно проходит через туннель.

Чувствительные серверные функции должны повторно разрешать доменное имя перед подключением и сопоставлять итоговый IP с политикой доступа. DNS-ответ может измениться между первичной проверкой URL и созданием соединения.

Типовые сценарии и итоговый чек-лист проверки маршрутизации и NAT

Ниже приведена таблица для быстрого поиска причины. Выполняйте проверку в указанном порядке и фиксируйте результат до внесения исправления.

Клиент подключен к сети, но сайты не открываются

Симптом	Вероятная причина	Проверка	Исправление
Нет IP или `169.254.x.x`	DHCP, VLAN, bridge, Wi-Fi или кабель	`ip addr`, lease DHCP, сравнение с другим клиентом	Восстановить выдачу DHCP и доступ клиента к нужному VLAN
Шлюз недоступен	Ошибка LAN, маски, VLAN или локального firewall	`ping GATEWAY`, `ip route`	Исправить адресацию, порт, VLAN и правила
Шлюз доступен, внешний IP нет	WAN, forwarding, NAT или провайдер	`ping 1.1.1.1`, `tcpdump`, счетчики nftables	Проверить маршрут WAN, `ip_forward`, masquerade и FORWARD
IP работает, имена нет	DNS	`dig example.com`, `resolvectl status`	Исправить DNS, маршрут до резолвера и правила UDP/TCP 53
DNS работает, HTTPS нет	Прокси, TLS, MTU или TCP-фильтрация	`curl -v`, проверка proxy и времени	Исправить прокси, MTU, сертификаты или firewall

VPN работает, но внешний интернет недоступен

Проверьте handshake через wg show или статус OpenVPN. Затем проверьте AllowedIPs либо redirect-gateway, маршрут по умолчанию, forwarding, masquerade на WAN, правило обратного трафика и DNS. Сравните внешний IP до и после подключения. Отдельно исключите конфликт локальной сети клиента с удаленной сетью, например одинаковый диапазон 192.168.1.0/24 с обеих сторон.

Для связи удаленных LAN через WireGuard или OpenVPN потребуется маршрут в обе стороны и правила доступа между подсетями. Готовая схема с проверками обратного пути описана в статье о маршрутизации между удаленными сетями через VPN.

Финальный чек-лист перед эксплуатацией

Зафиксируйте адресный план, VLAN, владельцев подсетей и назначения DNS-серверов.
Проверьте, что клиенты получают IP, маску, шлюз и DNS через DHCP.
Убедитесь, что на шлюзе сохранены net.ipv4.ip_forward=1, правила nftables и конфигурация интерфейсов.
Проверьте единственный ожидаемый default route на WAN или документированные policy rules.
Подтвердите счетчиками nftables работу NAT и обратного трафика.
Проверьте full-tunnel и split-tunnel отдельно, если оба режима используются.
Протестируйте DNS по IP, DNS по имени и HTTPS через назначенный путь.
Убедитесь, что firewall блокирует входящие соединения из WAN к административным сервисам.
Проверьте, что VPN-клиенты видят только разрешенные сети и порты.
Проверьте серверные загрузчики URL на блокировку loopback, приватных адресов, link-local сетей и cloud metadata endpoint после каждого редиректа.
Перезапустите сервисы в тестовом окне и повторите ключевые проверки после перезагрузки.

Рабочая диагностика всегда движется по фактическому пути пакета: клиент, шлюз, NAT, WAN, DNS, VPN, прокси и внешний ресурс. Такая последовательность помогает найти ошибку без хаотичных изменений конфигурации и снижает риск открыть лишний доступ в инфраструктуре.