Локална мрежа недоступна док је 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 ограничење које је већ постојало.

Име хоста то погоршава. Ако се локално име сада разрешава на јавну адресу, клијент ће наставити да испробава пут који не може да се врати. За тест користите приватну адресу, а затим исправите име уместо да додате још једно прослеђивање портова.

Треће, погледајте ко сада одговара на имена

Корпоративни resolver познаје интранет и обично не зна ништа о имену хоста NAS-а, Bonjour имену штампача или локалном алијасу рутера. Кад VPN прогура своје DNS сервере, та имена престају да се разрешавају иако су њихове адресе још доступне. Питајте име директно и упоредите одговор са адресом за коју знате да је уређај има.

На Linux-у resolvectl query nas.local показује који је resolver одговорио. На Windows-у nslookup nas.local именује сервер, а ipconfig /all показује редослед resolver-а. Ако локалним суфиксом сада управља корпоративни resolver, било преусмерите тај суфикс назад на локални resolver, било користите IP адресу за уређај.

Откривање је засебан слој. mDNS и емитовање не прелазе рутирани тунел, па уређај може бити доступан по адреси док његово име остаје невидљиво. Рефлектор или локални DNS запис то решава; рута не.

Четврто, проверите да ли је и други рачунар на VPN-у

Кад рачунар који желите да достигнете такође покреће VPN клијент, ваша сесија може да стигне док одговор излази кроз други тунел. То ствара везу која се успостави и затим запне, или покушај RDP-а и SSH-а који на вашој страни истекне без грешке. Проверите табелу рута другог хоста и његов подразумевани пут пре него што окривите свој клијент.

Проверите и адресу на којој сервис слуша. Слушалац везан само за адресу тунела прихвата везе из VPN-а и одбија оне из LAN-а, чак и кад је рутирање савршено. То је конфигурација сервиса, не мрежни пут, и често је на управљачким интерфејсима који су закључани на адресу VPN-а.

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

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

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

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

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