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

Если из 10.0.20.0/24 сайт открывается, а из 10.0.10.0/24 нет — origin скорее жив. Сравните на двух клиентах четыре вещи: DNS-ответ, default/маршрут, NAT (какой source на WAN), прокси/фильтр. Не перезагружайте веб-сервер первым. Работайте таблицей «сеть A vs сеть B».

Шлюз проблемной сети в примерах 10.0.10.1, DNS 10.0.10.2.

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

  • Wi‑Fi гостевой открывает, corp VLAN нет (или наоборот);
  • филиал жив, офис нет;
  • LTE жив, офис нет.

Это не «у всех нет интернета»: соседняя сеть — контроль. Если обе мертвы — есть IP нет интернета. Если ping есть везде — ICMP vs HTTP.

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

  1. Разный DNS: split, другой форвардер, NXDOMAIN только в одной зоне поиска.
  2. NAT/ACL: masquerade только для 10.0.20.0/24.
  3. Policy routing: 10.0.10.0/24 в мёртвый WAN.
  4. Прокси обязателен в одной сети, PAC не отдаётся.
  5. Фильтр по source VLAN/SGT.
  6. MTU/VPN только на одном пути.
  7. Hairpin нужен только из LAN сайта.
  8. IPv6 есть в одной сети, ломает Happy Eyeballs.

Диагностика

Снимите одинаковые команды с узла A (10.0.10.10) и узла B (10.0.20.10).

1. DNS

nslookup www.example.com
nslookup www.example.com 10.0.10.2
Resolve-DnsName www.example.com
resolvectl query www.example.com
dig www.example.com @10.0.10.2

Разные IP → split / кеш. Одинаковый IP — дальше не DNS.

2. Маршрут и traceroute

Find-NetRoute -RemoteIPAddress 93.184.216.34
tracert -d www.example.com
Test-NetConnection www.example.com -Port 443
ip route get 93.184.216.34
traceroute -n 93.184.216.34

Разный первый хоп — PBR. Один хоп мёртвый только из A — uplink этой VRF.

3. NAT source

На шлюзе 10.0.10.1:

sudo nft list chain inet nat postrouting
# или iptables -t nat -L -n -v

Счётчики для ip saddr 10.0.10.0/24 нулевые при живом трафике — нет masquerade. Из 10.0.20.0/24 счётчики растут. См. NAT не для всех.

4. Прокси

netsh winhttp show proxy

PAC доступен из A? Часто WPAD только в одном VLAN. curl без прокси vs браузер.

5. Политика фильтра

Сравните 403/captive. Из A — категория blocked, из B нет. Это не маршрут.

Методика трёх инструментов: ping tracert nslookup.

Решение

Сценарий A. DNS разный

Выровняйте option 6 / внутреннюю зону. Не ставьте публичный DNS только в «проблемной» сети как костыль на доменных ПК.

Сценарий B. Нет NAT для 10.0.10.0/24

Добавьте masquerade/srcnat для этой сети, stateful forward. Не accept all.

Сценарий C. PBR в мёртвый канал

Уберите mark или почините WAN. Проверьте, что ICMP и TCP ходят в один next-hop.

Сценарий D. Прокси

Либо PAC для обеих сетей, либо bypass к этому сайту. Документируйте.

Сценарий E. Hairpin только из сети сервера

Из 10.0.10.0/24 к публичному IP сайта, который сам в этой LAN — нужен hairpin или внутренний A. Из 10.0.20.0/24 пакеты идут на WAN нормально.

6. Заполните таблицу A vs B до любых правок на origin

Возьмите 10.0.10.10 и 10.0.20.10, один FQDN, один момент времени. Строки: IP клиента, DNS-сервер NIC, A/AAAA ответа, Find-NetRoute/ip route get на этот IP, первый hop traceroute, Test-NetConnection :443, WinHTTP-прокси, curl -I. Где первая расходящаяся строка — там слой. DNS разный → split/кэш/option 6. Маршрут разный → PBR/VRF. NAT: на шлюзе счётчики masquerade только для /20 → добавьте 10.0.10.0/24. Прокси PAC недоступен из VLAN 10 — браузер ждёт прокси, ping жив. Фильтр 403 только из A — категория, не маршрут. Hairpin: сайт живёт в 10.0.10.0/24, имя резолвится в белый, из этой сети нужен loopback или внутренний A; из 10.0.20.0/24 пакет уходит на WAN и DNAT работает.

Не меняйте origin, пока таблица не заполнена. Не чините обе сети сразу. После правки NAT/DNS повторите только сломанную сеть, затем контрольную, чтобы не сломать рабочую. IPv6 RA в одной VLAN и не в другой даёт «сайт открывается только там, где нет AAAA». Get-NetNeighbor к шлюзу должен быть Reachable в обеих, иначе вы сравниваете не маршрутизацию сайта, а мёртвый L2. Сохраните два текстовых файла net10-diag.txt и net20-diag.txt в заявке. Без этого «у нас в бухгалтерии не открывается» через неделю начнётся с нуля.

Дополнительно: MTU/VPN только на пути A, QUIC UDP/443 режется только ACL VLAN 10, SNI-фильтр на одном WAN. Каждый из этих пунктов проверяется после равенства DNS+NAT+прокси, не вместо.

Команды для пары узлов держите одинаковыми, включая ping -n 4 10.0.10.1 vs ping -c 4 10.0.20.1 — каждый к своему шлюзу. nslookup всегда с явным сервером. Get-NetNeighbor к шлюзу. Если L2 мёртв в A, вы сравниваете VLAN, не сайт. После выравнивания DNS не забудьте, что браузер ещё час может держать старый IP. Прокси WinHTTP vs WinINET: curl жив, Edge нет — PAC. Зафиксируйте HTTP-код: 403 и timeout — разные ветки. Не открывайте порт origin «для бухгалтерии», пока source IP бухгалтерии не виден в access-логе: если запроса нет, проблема до сервера.

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

С узла A: тот же IP, что у B (если так задумано), TCP/443 True, страница открывается, curl -I 200/301. Traceroute не в чёрную дыру. Повторите после DHCP renew. Узел B не сломался.

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

  • Только HTTPS, HTTP есть — TLS-инспекция на одном VLAN.
  • Только один FQDN — SNI-фильтр.
  • Асимметрия на обратном пути из этой сети.
  • Квота/user auth на прокси для группы VLAN 10.

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

  • Чек-лист «новая VLAN»: DNS option, NAT, proxy, ACL, мониторинг синтетики из этой сети.
  • Не копировать NAT-правило «как для 20-й» забыв сменить prefix.
  • Карта: какая сеть каким WAN выходит.

FAQ

Почему с телефона админа из corp работает, с ПК пользователя нет?

Разная сеть (Wi‑Fi vs кабель), другой DNS, или PAC. Сравнивайте IP источника, не «одного человека».

Можно ли лечить маршрутом на самом ПК?

Только как тест Find-NetRoute. Постоянно — на шлюзе.

ping до сайта из A есть, из браузера нет.

Снова отделите ICMP. Смотрите TCP/прокси.

Обе сети в одном NAT, A всё равно мертва.

Тогда DNS, фильтр или MTU, не src-prefix. Идите по таблице построчно.

Стоит ли менять IP сайта?

Нет, пока две сети расходятся. Origin меняют последним.