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 се достига през тунела, шлюзът ѝ трябва да знае къде живее пулът на тунела: 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 хоста като източник, затова журналите по клиенти и обратните резолввания губят смисъл. Това покрива една опашка за печат или една администраторска страница, не хостове от двете страни, които се достигат взаимно.
Какво още няма да работи и какво да запишете
Broadcast не пресича маршрутизиран тунел. DLNA, UPnP, разглеждането на NetBIOS и Wake-on-LAN зависят от broadcast или multicast, които tun устройство не носи, така че никой маршрут не поправя откриването. Мостът с dev tap разширява сегмента, а с него и DHCP broadcast, ARP и всеки друг пакет за откриване; предпочитайте unicast маршрут до хост, например 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, който работи в едната посока и умира в другата, сочи към обратния път, не към тунела, и точно това разграничение решава коя от поправките по-горе ви е нужна.