VPN туташканда жергиликтүү тармак жеткиликсиз бүтүп калдыбы? Төрт текшерүү

Туннель көтөрүлөт, интранет көрүнөт, ал эми принтер жооп берүүнү токтотот. LAN тармагында эч нерсе бузулган жок; кардар өзү мындан ары жергиликтүү деп эсептебеген даректер үчүн кайсы жолду колдонорун өзгөрткөн. Төмөнкү төрт текшерүүнү тартиби менен аткарып, бири так дал келбестикти көрсөткөндө токтоңуз, анткени бир эле белгинин төрт кеңири тараган себеби бар жана алардын бирөө гана VPN жөндөөсүн өзгөртүү менен дарыланат.

Алгач кардар орноткон маршрут таблицасын караңыз

VPN туташканда кардардын маршрут таблицасын ачыңыз. Linux боюнча ip route, Windows боюнча route print же Get-NetRoute, ал эми macOS боюнча netstat -rn колдонуңуз. Сиз туннель аркылуу өткөн демейки маршрутты жана физикалык демейкиге эмне болгонун издейсиз.

Толук туннель кардары 0.0.0.0/0 дарегин алмаштыруунун ордуна көбүнчө эки жарым демейки маршрут кошот: 0.0.0.0/1 жана 128.0.0.0/1. Баштапкы демейки маршрут көрүнүп турат, бирок ар бир издөөдөн утулат, ошондуктан таблица бүтүн көрүнүшү мүмкүн, ал эми ички тармактан тышкаркы бардык трафик жылат. Эгер 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.0/24 кардарындагы 192.168.1.40 принтер туташкан маршрутту колдонот; эгер ал дарек иштебесе, VPN эмес, түзмөктү, коммутаторду же кардардын firewall-ин караңыз.

Адамдарды адаштырган учур — жергиликтүү сервердин ачык дареги. 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 аракети сиз тарапта катасыз убакыттан өтүп кетет. Өз кардарыңызды күнөөлөөдөн мурун экинчи хосттун маршрут таблицасын жана анын демейки жолун текшериңиз.

Ошондой эле кызмат угуп жаткан даректи текшериңиз. Бир гана туннелдин дарегине байланган listener VPNден келген байланыштарды кабыл алып, LANдан келгендерин четке кагат, ал тургай маршруттоо кемчиликсиз болсо да. Бул кызматтын конфигурациясы, тармак жолу эмес, жана VPN дарегине жабылган башкаруу интерфейстеринде кеңири таралган.

Туннелге көз каранды эмес башкаруу жолун сактаңыз: башат тармагыңызды атаган статикалык маршрут, LANга туташкан башка интерфейс, же туннелди толук айланып өткөн консоль. Ошол жолду сессия үзүлгөндөн кийин долбоорлоо кийинки туташуунун алдында кошуудан алда канча кыйын.

Ийгиликсиз текшерүүгө туура келген оңдоону колдонуңуз

Эгер маршрут таблицасы жарым демейки маршруттун басып алынганын көрсөтсө, саясат уруксат берсе бөлүнгөн туннелди, бербесе бекитилген жергиликтүү маршрутту тандаңыз. Эгер дарек ачык болуп чыкса, сыноону жана атты жеке дарекке которуңуз. Эгер чечүүчү кол алмаштырса, жергиликтүү уланды менен чектелиңиз же даректи колдонуңуз. Эгер экинчи хост туннелде болсо, анын кайтуу жолун же listener байлоосун оңдоңуз.

Бир нерсени өзгөртүп, анан ошол эле текшерүүнү кайталаңыз. Туура эмес ички тармак үчүн кошулган маршрут, ката жазылган чечүүчү уландысы жана жаңы номер алган интерфейске бекитилген маршрут — баары баштапкы бузулушка окшош. Оңдоону кокустан ажырата турган нерсе — кайталоо.

VPN туташканда иштеген маршрутту, даректи жана чечүүчүнү жазып алыңыз. Кийинки кайра туташуу алардын жок дегенде бирөөсүн өзгөртөт, ал эми жазуу кийинки үзүлүштү жаңы иликтөөнүн ордуна кыска салыштырууга айландырат.