Короткий ответ

Интернет «пропадает», когда default route или 0.0.0.0/0 уезжает в туннель, а шлюз VPN не делает NAT/forward в интернет — либо DNS после смены резолвера перестаёт отвечать. Решите явно: split (только 10.0.10.0/24 и 10.8.0.0/24) или full tunnel с рабочим выходом в WAN на стороне vpn.example.com. Не лечите это отключением туннеля «навсегда» и не ставьте публичный DNS в nic офисного DC.

Снимите ip route / Get-NetRoute до и после подключения. Если default сменил устройство на wg0/tun0/VPN — вы в full tunnel, даже если «хотели только RDP».

Симптомы и как отличить

  • До VPN браузер работает, после — крутится.
  • LAN офиса при этом может быть доступна или нет.
  • ping 10.8.0.1 жив, ping 1.1.1.1 — timeout или ответы с огромным TTL через офис.

Отличия:

  • LAN недоступна, интернет жив — LAN, не эта статья.
  • Интернет «есть», но только по IP, имена мёртвые — DNS.
  • Канал офиса забит YouTube с дома — full tunnel перегружает.
  • Нужны узкие маршруты — split.

Возможные причины

  1. WireGuard AllowedIPs = 0.0.0.0/0 на клиенте.
  2. OpenVPN redirect-gateway def1 или push этого с сервера.
  3. Windows RAS: SplitTunneling $false (по умолчанию часто full).
  4. Шлюз принимает 0.0.0.0/0 из туннеля, но ip_forward/NAT в WAN нет — чёрная дыра.
  5. DNS уехал на 10.0.10.10, который недоступен (нет маршрута к LAN) — выглядит как «нет интернета».
  6. Метрика VPN-адаптера ниже, чем у физического, IPv6 default через VPN при мёртвом IPv6 на шлюзе.
  7. Kill-switch клиента (WireGuard/OpenVPN GUI) режет non-tunnel трафик, а туннель без WAN-NAT.

Диагностика

1. Таблица маршрутов до/после

Linux:

ip route show
ip route get 1.1.1.1
ip route get 10.0.10.10
wg show

После подключения запомните dev для 1.1.1.1. Если wg0 — full overlay.

Windows 11:

Get-VpnConnection | Format-List Name, ConnectionStatus, SplitTunneling
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric, DestinationPrefix
Find-NetRoute -RemoteIPAddress 1.1.1.1 | Format-List
Get-DnsClientServerAddress -AddressFamily IPv4

2. Есть ли выход с шлюза

На vpn.example.com:

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -n -i eth0 host 1.1.1.1

Ping с клиента на 1.1.1.1 при full tunnel должен появиться на WAN шлюза (после NAT — уже с WAN IP). Тишина на WAN при пакетах на wg0 — нет FORWARD/NAT.

3. DNS vs default route

resolvectl status
getent hosts example.com

Windows:

Resolve-DnsName example.com
Get-DnsClientNrptPolicy

Таймаут DNS при живом ping 1.1.1.1 — не маршруты, а резолвер. Живой DNS, мёртвый ping на 1.1.1.1 через wg0 — NAT/forward.

Решение

Сценарий A. Нужен только офис (split)

Клиент WireGuard:

AllowedIPs = 10.8.0.0/24, 10.0.10.0/24

без 0.0.0.0/0. OpenVPN: уберите redirect-gateway, оставьте route 10.0.10.0 255.255.255.0. Windows:

Set-VpnConnection -Name 'Office' -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName 'Office' -DestinationPrefix '10.0.10.0/24'
Add-VpnConnectionRoute -ConnectionName 'Office' -DestinationPrefix '10.8.0.0/24'

Переподключитесь. ip route get 1.1.1.1 должен вернуть домашний/офисный WAN-шлюз клиента, не wg0.

Сценарий B. Full tunnel задуман, но NAT нет

На шлюзе:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i wg0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

eth0 — WAN. Не маскарадьте LAN в себя. Политика «весь интернет сотрудников через офис» должна быть явной, с ёмкостью канала. См. перегруз.

Сценарий C. DNS уехал в никуда

Верните резолвер, достижимый при текущих маршрутах: либо DNS LAN при живом маршруте на 10.0.10.0/24, либо оставьте бытовой DNS в split. Для доменных имён без утечки — NRPT только на contoso.example, не на .. Статья DNS через VPN.

Сценарий D. IPv6 чёрная дыра

Если IPv4 split, а IPv6 default ушёл в туннель без IPv6 на шлюзе, браузеры «тупят». Либо объявите IPv6 в VPN осознанно, либо не принимайте ::/0 в AllowedIPs/prefixlist.

OpenVPN 2.6: смотрите, нет ли redirect-gateway ipv6. WireGuard: нет ли ::/0 в AllowedIPs.

Сценарий E. Kill-switch

В GUI снимите kill-switch, если split нужен для бытового интернета. Kill-switch при мёртвом NAT на сервере = гарантированный офлайн. Это не «баг Windows».

Как проверить, что проблема устранена

Split:

ip route get 1.1.1.1
ip route get 10.0.10.10
ping -c 2 1.1.1.1
ping -c 2 10.0.10.10

Первый ping не через wg0, второй — через туннель.

Full tunnel:

ip route get 1.1.1.1
ping -c 2 1.1.1.1
curl -sI https://example.com | head -n 1

На шлюзе counters NAT растут. Пользователь открывает сайт и RDP к 10.0.10.10.

Windows:

Find-NetRoute -RemoteIPAddress 1.1.1.1
Find-NetRoute -RemoteIPAddress 10.0.10.10
Get-VpnConnection -Name 'Office' | Select-Object SplitTunneling

Если не помогло

  • Сайты открываются, банки/RDP нет — MTU, не default route.
  • Только часть приложений «без сети» — они зашили DNS DoH в обход Nic; это не таблица маршрутов.
  • После VPN нет и LAN, и интернета — нет ни split-маршрутов, ни рабочего NAT; разберите по лестнице.
  • Маршруты «прыгают» обратно — GPO/Always On VPN перезаписывает SplitTunneling.

Профилактика

  • В шаблоне клиента по умолчанию — split на 10.0.10.0/24 + 10.8.0.0/24, full только по заявке.
  • Ёмкость WAN офиса считать до включения 0.0.0.0/0.
  • Не пушить redirect-gateway «на всякий случай» в server.conf OpenVPN.
  • Хранить эталон Get-NetRoute / ip route для профиля Office.

FAQ

Это «сломался интернет провайдера»?

Редко совпадает с моментом Connect. Снимите VPN — если интернет вернулся, виноват маршрут/DNS/NAT туннеля.

Можно ли оставить 0.0.0.0/0 и «как-нибудь» ходить в интернет локально?

Нет одновременно без policy routing (таблица main vs wg). Либо split AllowedIPs, либо full + NAT. Смесь без правил — лотерея.

Почему ping 10.8.0.1 есть, а google нет?

Потому что туннельный /24 маршрутизируется, а default — нет или уходит в дыру без NAT.

Windows: снял галку default gateway, офис пропал

Ожидаемо. Добавьте Add-VpnConnectionRoute на LAN. Галка и split — разные ручки одного смысла.

Нужно ли отключать IPv6 на NIC?

Не как постоянный костыль. Либо настройте IPv6 в VPN, либо не заворачивайте ::/0. Отключение IPv6 «навсегда» ломает другие сервисы.