VPN и домашняя LAN в одной подсети: сначала пройдите маршрут
Оба адаптера претендуют на 192.168.1.0/24, и побеждает только один маршрут. Пройдите список адаптеров, победивший маршрут и обратный путь, прежде чем перенумеровывать или винить DNS.
Вы подключаетесь к офисному VPN, значок в трее становится зелёным, интранет загружается, а принтер в двух метрах перестаёт отвечать. Общая папка, работавшая утром, упирается в тайм-аут на той же машине, и ни один журнал не упоминает принтер. Первая реакция — DNS, потому что неразрешаемое имя выглядит как несуществующее, но проблема в адресе: два адаптера теперь претендуют на 192.168.1.0/24, и только один маршрут может победить этот префикс. Пройдите это в таком порядке, и вы увидите, какой адаптер его занял, прежде чем что-то менять.
Начните с симптома, а не с туннеля
Подсказка — в масштабе. Если интранет работает, а каждое локальное устройство отказывает, туннель здоров, а локальный путь нет. Если локальные устройства работают, а интранет отказывает, наоборот. Если всё работает, кроме одного узла, вы смотрите на один адрес, который существует с обеих сторон.
Запишите один локальный и один удалённый адрес, прежде чем трогать настройку. «Принтер» проверить нельзя; 192.168.1.40 можно. Этот один шаг предотвращает самый частый потерянный час в этой проблеме — переписывание настроек DNS ради решения о маршрутизации.
Шаг 1: увидьте оба адаптера, претендующих на префикс
Откройте «Сетевые подключения» (ncpa.cpl) и прочитайте оба адаптера рядом. Адаптер Ethernet показывает 192.168.1.50/24 со шлюзом 192.168.1.1. Адаптер VPN показывает 192.168.1.201/24, отправленный сервером. Оба легитимны, оба считают префикс on-link, и стек будет держать для него единственный маршрут.
Get-NetIPAddress -AddressFamily IPv4 перечисляет адреса, а Get-NetIPInterface | Sort-Object InterfaceMetric показывает порядок, в котором стек будет их использовать. Этот столбец метрики и есть решение, которое вы вот-вот прочитаете, поэтому запишите числа, а не пытайтесь их запомнить.
Опровергните теорию DNS дёшево: Resolve-DnsName printer.office.lan возвращает тот же адрес, что и вчера. Имя разрешилось; затем пакет ушёл через неверный адаптер. Две минуты здесь экономят полдня в настройках резолвера.
Шаг 2: прочитайте маршрут, который действительно победил
Find-NetRoute -RemoteIPAddress 192.168.1.40 печатает интерфейс, следующий переход и источник, которые стек использовал бы для этого адреса. Относитесь к выводу как к ответу, а не как к подсказке. route print -4 даёт всю таблицу, когда нужно увидеть, какая запись проиграла и на сколько.
Конкретность побеждает намерение. Отправленный 192.168.0.0/25 побеждает локальный 192.168.0.0/24, потому что префикс длиннее, поэтому 192.168.0.0–192.168.0.127 уходят через туннель, а верхняя половина остаётся локальной. Исчезновение половины LAN без сообщения об ошибке — правильное поведение этой таблицы.
tracert -d 192.168.1.40 подтверждает это извне таблицы: если первый переход — адрес туннеля, а не ваш собственный маршрутизатор, то маршрут и есть вся история. В Linux тот же вопрос — ip route get 192.168.1.40, который печатает адрес источника и устройство в одной строке. Когда в ответе звучит tun0, перестаньте смотреть в браузер.
Шаг 3: проверьте обратный путь, прежде чем винить клиента
Правильный маршрут вперёд всё равно не сработает, если дальняя сторона не может ответить. Когда до LAN клиента добираются через туннель, шлюз этой LAN должен знать, где живёт пул туннеля: ip route add 10.8.0.0/24 via 192.168.1.12 на этом маршрутизаторе, и push «route 192.168.1.0 255.255.255.0» с сервера, чтобы клиенты знали обратный путь.
Без первой записи ответ покидает цель в сторону своего шлюза по умолчанию, который передаёт приватный адрес провайдеру и отбрасывает его. Симптом односторонний и легко читается неправильно: запросы появляются на tun0, ответы — никогда.
Правило masquerade на узле VPN снимает необходимость в этом статическом маршруте: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Оно также скрывает реальные адреса источника, что усложняет каждый последующий вопрос по журналам. Целевой узел с неверным шлюзом по умолчанию даёт ту же тишину: в лучшем случае ICMP-перенаправление, в обычном — чёрная дыра, поэтому съём и нужен с обеих сторон.
Шаг 4: выберите исправление, с которым можно жить
Для этого используют пять исправлений, и они не взаимозаменяемы. Выбирайте по тому, что должно оставаться доступным одновременно, а не по тому, какая команда короче.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Метрики — дешёвый вариант и тот, к которому люди тянутся первым. Изменение применяется к интерфейсу, поэтому работает, пока туннель поднят, и его место — в скрипте рядом с клиентом, а не в оболочке, которую вы забудете. Он не может дать одновременный доступ к одному адресу в двух сетях, и именно этот предел отправляет всех остальных вниз по таблице.
Перенумерация домашней LAN в 10.10.0.0/24 — чистое решение: одно продление аренды DHCP плюс резервирования, очереди печати и жёстко прописанные адреса, упоминающие старый диапазон. Перенумерация офисной стороны обычно не ваше решение. IPv6 полностью убирает коллизию, когда обе сети его поддерживают, используя уникальный локальный префикс из fd00::/8 вместо чего-то запоминающегося, но проверяйте приложение по TCP, а не пингом, потому что ICMP может работать, пока служба нет.
Собственная опция трансляции OpenVPN — последнее средство, она отправляется с сервера в запись каталога, специфичную для клиента. После имени опции идут четыре параметра — направление, сеть, маска и псевдоним — и псевдоним не является необязательным: push "route 192.168.2.0 255.255.255.0" и push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Сеть и маска — это диапазон, который видит клиент (192.168.2.0/24), псевдоним — реальный офисный диапазон на стороне сервера (192.168.1.0/24), а отправленный маршрут делает этот видимый диапазон доступным. Офис тогда предстаёт для этого клиента под 192.168.2.x. Задокументируйте соответствие в профиле, иначе следующий человек будет отлаживать это как сбой маршрутизации.
Публикация одной службы — узкая версия трансляции, и опция OpenVPN ей вообще не нужна. Правило DNAT на узле VPN публикует заново один порт, поэтому LAN сохраняет свои адреса и достигает службы по адресу узла, который уже знает. Цена обычная: служба видит узел VPN как источник, поэтому журналы по клиентам и обратные запросы перестают что-либо значить. Это покрывает одну очередь печати или одну страницу администрирования, а не узлы с обеих сторон, достигающие друг друга.
Что всё равно не заработает и что записать
Широковещание не проходит через маршрутизируемый туннель. DLNA, UPnP, просмотр NetBIOS и Wake-on-LAN зависят от широковещания или многоадресной рассылки, которые устройство tun не несёт, поэтому ни один маршрут не исправит обнаружение. Мост через dev tap расширяет сегмент, а вместе с ним широковещание DHCP, ARP и любой другой пакет обнаружения; предпочитайте одноадресный маршрут к узлу, например route 192.168.2.1 255.255.255.255, для адреса со стороны LAN удалённого маршрутизатора.
Два маршрутизатора, оба использующие 192.168.1.1 на одном пути, относятся к одному семейству проблем: локальный адрес всегда побеждает, поэтому страница дальнего маршрутизатора остаётся недоступной, пока одна LAN не переедет. Добавление второго адаптера ничего не меняет ни в одном из случаев.
Запишите доказательства, прежде чем что-либо править: ip route get или Find-NetRoute, ping -c 3 до нужного адреса, traceroute, и tcpdump -ni tun0 icmp на клиенте, затем таблицу маршрутизации и счётчики NAT на сервере. Пинг, который работает в одну сторону и умирает в другую, указывает на обратный путь, а не на туннель, и именно это единственное различие решает, какое из исправлений выше вам действительно нужно.