VPN кардарлары серверге жетет, бирок LAN тармагына жетпейт: кайсы чечим?

Кардар OpenVPN серверинин туннель дарегине ping жасап, жооп алат, анан сервердин LAN тармагындагы хостту сынап көрөт жана эч нерсе албайт. Бул айырма акананы кыйла тарылтат: туннель көтөрүлгөн, жиберүү иштеп жатышы мүмкүн, ал эми жооп кайра алып барбаган эшиктен чыгат. Үч чечим бар жана туурасы эмнени көзөмөлдөөрүңүзгө жана эмнеден баш тартууга даяр экениңизге байланыштуу. Төмөнкү үч суроого ирети менен жооп бериңиз, ошондо тандоо табит маселеси болбой калат.

Алгач кайсы багыт бузулганын аныктаңыз

Сурам туннель интерфейсине VPN пулунан келген баштапкы дарек менен келет. Сервер аны LAN тармагындагы хостко жиберет, ал эми ал хост өз таблицасы көрсөткөн шлюзге, адатта LAN маршрутизаторуна жооп берет. Эгер маршрутизатордун пулга маршруту жок болсо, жооп ошол жерде өлөт же интернетти көздөй адашат.

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

Биринчи суроо: алыскы LAN тармагынын маршрутизаторун редакциялай аласызбы?

LAN маршрутизатору сиздики болсо, таза жооп — VPN пулуна VPN серверинин LAN дарегин кийинки секирик катары көрсөткөн статикалык маршрут. Ал кардарлардын баштапкы даректерин бузбай сактайт, бул LAN хосттору дарек боюнча журнал жазганда, чыпкалаганда же ылдамдыкты чектегенде маанилүү. Ал серверде котормону да талап кылбайт, ошондуктан туннель таза маршруттоо жолу бойдон калат. Ал жараткан милдет — документтештирүү, анткени пул, маршрут жана сервер конфигурациясы дал келиши керек.

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

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

Экинчи суроо: LAN тармагы кардар даректерин көрүүнү токтото алабы?

Маршрутизатор башка бирөөгө таандык болсо, VPN серверинде которуу кызматташууну талап кылбайт. LAN тармагындагы хост сервердин LAN дарегин көрөт, ага жооп берет, ал эми сервер кайра которот. Ошондуктан түзмөктөр жана NAT негизиндеги алыскы кирүү ролдору ушундай аракет кылат.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Баасы — таандыктык: ар бир кардарга тиешелүү даректер LAN журналдарынан жок болот. LAN тармагындагы хосттогу ар кандай уруксат тизмеси ошондо пулду эмес, серверди аташы керек.

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

Үчүнчү суроо: сервер өзү башка туннелдин кардарыбы?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

Анан эки багытты да, эки өлчөмдү да текшериңиз

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

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

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