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, а не ping, бо 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 на сервері. Ping, що працює в один бік і вмирає в інший, указує на зворотний шлях, а не на тунель, і саме ця різниця вирішує, яке з виправлень вище вам справді потрібне.