Роутердеги VPN иштейт, бирок LAN кардарларында интернет жок

Роутер өз туннели аркылуу интернетке чыгат, ал эми анын артындагы түзмөктөр чыкпайт. Жөнөтүү, которуу жана кайтаруу маршруттары өзүнчө укуктар.

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

Бузулушту LAN хостунан окуу

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

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

Жергиликтүү жана жөнөтүлүүчү трафик ар башка

Linux жана көпчүлүк роутер прошивкалары кутучанын өзү жараткан пакеттерди андан өтүүчү пакеттерден башкача иштетет. Чыгуу тизмеги биринчи түрүн көрөт, жөнөтүү тизмеги экинчисин көрөт, жана роутердин өз трафигине ылайыкталган саясат жөнөтүүнү тийбестен калтырышы мүмкүн.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

Кайтуу жолу да болушу керек

Баштапкы даректи которуу кайтуу жолунун керекпи же жокпу аныктайт. Туннель интерфейсинде маскараддоо болсо, жооптор туннелдин дарегине кайтат жана роутер аларды кайра которот. Ансыз алыскы шлюзга кардардын ички тармагына так маршрут керек, жана анын өз саясаты да ошол багытка уруксат бериши керек.

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

Кардардын DNS да ошол эле кароого кирет. Роутердин чечүүчүсү жооп бере алат, ал эми башка серверге багытталган кардар эч нерсе албайт.

Бир уруксат берилген жана бир тыюу салынган агымды текшерүү

Оңдоодон кийин роутердин учурдагы сессиясынан эмес, кардардан жаңы байланышты сынаңыз. Анан туннелди колдонбошу керек болгон сегмент дагы эле колдонбогонун ырастаңыз.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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

Тектеш макалалар