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

Тунелот се крева, интранетот се појавува, а печатачот престанува да одговара. На LAN ништо не се расипало; клиентот го сменил патот што го користи за адреси што веќе не ги смета за локални. Поминете ги четирите проверки подолу по ред и застанете кога една ќе покаже конкретно несовпаѓање, бидејќи истиот симптом има четири вообичаени причини и само една од нив се поправа со уредување на 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.

Случајот што ги збунува луѓето е јавна адреса за локален сервер. Од внатрешноста на LAN, стигнувањето до 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 и ги одбива од LAN, дури и кога рутирањето е совршено. Тоа е конфигурација на услугата, не мрежен пат, и е вообичаено на управувачки интерфејси што биле заклучени на VPN адресата.

Одржувајте управувачки пат што не зависи од тунелот: статична рута што ја именува вашата изворна мрежа, друг интерфејс поврзан на LAN, или конзола што целосно го заобиколува тунелот. Да го дизајнирате тој пат откако сесијата ќе падне е многу потешко отколку да го додадете пред следното поврзување.

Применете ја поправката што одговара на неуспешната проверка

Ако табелата со рути покажа полустандардно преземање, изберете поделен тунел кога политиката дозволува и прикачена локална рута кога не дозволува. Ако адресата се покажа како јавна, префрлете го тестот и името на приватната адреса. Ако резолверот смени раце, ограничете се на локалната наставка или користете ја адресата. Ако другиот домаќин е во тунел, поправете го неговиот повратен пат или врзувањето на слушачот.

Сменете една работа, потоа повторете ја истата проверка. Рута додадена за погрешна подмрежа, наставка на резолвер со печатна грешка и прикачена рута на интерфејс што добива нови броеви, сите изгледаат како оригиналниот дефект. Повторувањето е она што ја одделува поправката од случајноста.

Запишете ја рутата, адресата и резолверот што работеле додека VPN бил поврзан. Следното повторно поврзување ќе смени барем едно од нив, а белешката го претвора следниот прекин во кратко споредување наместо нова истрага.