Локалната мрежа е недостъпна при свързан VPN? Четири проверки

Тунелът се вдига, интранетът се появява и принтерът спира да отговаря. Нищо в локалната мрежа не се е повредило; клиентът е сменил пътя, който използва за адреси, които вече не смята за локални. Преминете четирите проверки по-долу по ред и спрете, когато една даде конкретно несъответствие, защото същият симптом има четири чести причини и само една от тях се отстранява с редактиране на VPN.

Първо, погледнете таблицата с маршрути, която клиентът е инсталирал

Отворете таблицата с маршрути на клиента, докато VPN е свързан. В Linux използвайте ip route, в Windows — route print или Get-NetRoute, а в macOS — netstat -rn. Търсите маршрут по подразбиране през тунела и какво се е случило с физическия маршрут по подразбиране.

Клиентът на пълен тунел често добавя два полумаршрута по подразбиране, 0.0.0.0/1 и 128.0.0.0/1, вместо да замени 0.0.0.0/0. Оригиналният маршрут по подразбиране остава видим, но губи всяко търсене, поради което таблицата може да изглежда непокътната, докато целият трафик извън подмрежата се мести. Ако VPN клиентът предлага опция за разделен тунел и политиката го позволява, това е най-чистата поправка.

Ако тунелът трябва да остане маршрутът по подразбиране, вместо това фиксирайте локалната подмрежа. В Linux маршрутът посочва физическия интерфейс и шлюза; в Windows добавете -p, за да го направите постоянен, и прочетете номера на интерфейса от route print, вместо да го гадаете:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Фиксираният маршрут се държи само докато адресът, който посочва, остава същият. Лаптоп, който преномерира Wi-Fi адаптера си при всяко свързване, отново ще наруши правилото, затова проверете адреса на интерфейса, преди да решите, че поправката е неуспешна.

Второ, потвърдете, че адресът е бил локален от самото начало

Ако дестинацията е вътре в свързаната подмрежа, маршрутът по подразбиране през тунела никога не се прилага и VPN не е причината. Принтер на 192.168.1.40 при клиент с 192.168.1.0/24 използва свързания маршрут; ако този адрес не работи, гледайте устройството, суича или защитната стена на клиента, а не VPN.

Случаят, който заблуждава хората, е публичен адрес за локален сървър. Отвътре в локалната мрежа достигането на WAN адреса на рутера и връщането обратно изисква hairpin NAT, а много рутери просто не го реализират за пренасочване на портове. Тествайте частния адрес до публичния. Ако частният адрес работи, а публичният не, VPN само е разкрил ограничение на NAT, което вече е било налице.

Името на хоста влошава нещата. Ако локалното име сега се разрешава до публичния адрес, клиентът ще продължи да опитва пътя, който не може да се върне. Използвайте частния адрес за теста, после поправете името, вместо да добавяте още едно пренасочване на порт.

Трето, вижте кой отговаря на имената сега

Корпоративният резолвер познава интранета и обикновено нищо не знае за име на NAS хост, Bonjour името на принтер или локалния псевдоним на рутер. Когато VPN изпрати своите DNS сървъри, тези имена спират да се разрешават, въпреки че адресите им са все още достъпни. Заявете името директно и сравнете отговора с адреса, за който знаете, че устройството има.

В Linux resolvectl query nas.local показва кой резолвер е отговорил. В Windows nslookup nas.local посочва сървъра, а ipconfig /all показва реда на резолверите. Ако локалният суфикс сега се обработва от корпоративния резолвер, или насочете суфикса обратно към локалния резолвер, или използвайте IP адреса на устройството.

Откриването е отделен слой. mDNS и broadcast не преминават през маршрутизиран тунел, затова устройството може да е достъпно по адрес, докато името му остава невидимо. Отражател или локален DNS запис решава това; маршрут не.

Четвърто, проверете дали другата машина също е във VPN

Когато машината, до която искате да достигнете, също изпълнява VPN клиент, сесията ви може да пристигне, докато отговорът ѝ излиза през другия тунел. Това създава връзка, която се установява и после засяда, или опит за RDP и SSH, който изтича без грешка от ваша страна. Проверете таблицата с маршрути на другия хост и маршрута му по подразбиране, преди да обвинявате клиента си.

Проверете и адреса, на който услугата слуша. Слушател, обвързан само с адреса на тунела, приема връзки от VPN и отказва тези от локалната мрежа, дори когато маршрутизацията е безупречна. Това е конфигурация на услуга, а не мрежов път, и е често срещано при интерфейси за управление, заключени към адреса на VPN.

Пазете път за управление, който не зависи от тунела: статичен маршрут, който посочва вашата изходна мрежа, друг интерфейс, свързан с локалната мрежа, или конзола, която заобикаля тунела напълно. Проектирането на този път след падане на сесията е много по-трудно от добавянето му преди следващото свързване.

Приложете поправката, която съответства на провалената проверка

Ако таблицата с маршрути показа прихващане на полумаршрут по подразбиране, изберете разделен тунел, когато политиката позволява, и фиксиран локален маршрут, когато не. Ако адресът се оказа публичен, превключете теста и името към частния адрес. Ако резолверът смени ръце, ограничете локалния суфикс или използвайте адреса. Ако другият хост е в тунел, поправете обратния му път или обвързването на слушателя.

Променете едно нещо, после повторете същата проверка. Маршрут, добавен за грешна подмрежа, суфикс на резолвер с печатна грешка и фиксиран маршрут на интерфейс, който се преномерира, изглеждат като първоначалната повреда. Повторението е това, което отделя поправка от съвпадение.

Запишете маршрута, адреса и резолвера, които са работили, докато VPN е бил свързан. Следващото повторно свързване ще промени поне един от тях, а бележката превръща следващото прекъсване в кратко сравнение вместо ново разследване.