Туннелдин көтөрүлүшүн жана кардардын каршы тарапка ping жөнөтүшүн көрүңүз, анан VPN артындагы коомдук дарек башка жерден жооп берет, же такыр жооп бербейт. Бул симптомдун адатта шифр же сертификаттар менен эч кандай байланышы жок. Провайдер маршруттаган префикс IP маршруту катары жеткирилет, жана аны OpenVPN аркылуу ташуу ошол маршрутту эки деңгээлде кайра жаратуу жана кайтуу жолунда булак дарегин сактоо дегенди билдирет. WANды көпүрөлөө талап кылынбайт, жана даректи интерфейске кошуу жогорку маршрутту түзбөйт.

Префикс адегенде сизге маршрутталышы керек

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

Эгер провайдер 198.51.100.64/28ди кирүү сервериңизге маршруттаса, ошол диапазондун пакеттери серверге келип, сиз аларды өткөрүп бербесеңиз, ошол жерде токтойт. Эгер провайдер анын ордуна диапазонду жогорку байланышыңызга көпүрөлөсө, сервер ага ARP жообун бериши керек, бул башка маселе.

OpenVPNге тийүүдөн мурун жеткирүү модельин текшериңиз: сырттан блоктогу дарекке ping жөнөтүп, аны кайсы интерфейс кабыл аларын караңыз. Эч нерсе келбесе, эч кандай туннель конфигурациясы жардам бербейт. Эгер дарек WANда түздөн-түз жооп берсе, провайдер маршруттоонун ордуна көпүрөлөп жатат, жана төмөнкү долбоор колдонулбайт.

Маршруттоонун эки деңгээли: ядро маршруту жана iroute

OpenVPNге префикс эки жерде керек. Ядро префикстин туннель түзмөгүнө таандык экенин билиши керек, ошентип өткөрүлгөн пакеттер демейки маршруттун ордуна OpenVPNге кирет. OpenVPN ошондой эле кайсы аутентификацияланган кардар префикске ээ экенин билиши керек, жана бул кардарга тиешелүү каталогдогу iroute жазуусу.

Сервер тараптагы маршрут мындай көрүнөт, префикс жана маска бөлүштүрүүгө туура келиши керек:

ip route add 198.51.100.64/28 dev tun0

Кардарга тиешелүү конфигурация ээликти дайындайт. Аны кардар сертификатынын жалпы аты менен аталган CCD файлына салыңыз жана сервер чындыгында ошол каталогду окуганын ырастаңыз:

iroute 198.51.100.64 255.255.255.240

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

Кызмат дареги кайда жашайт

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

Кызматты жергиликтүү түрдө бүтүргөн Linux кардарында бир хост дареги жетиштүү:

ip address add 198.51.100.70/32 dev lo

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

Кайтуу жолунда коомдук булакты сактаңыз

Делегацияланган префикстен жооп туннелден чыгып, провайдердин маршрутуна жетиши керек. Эгер алыскы хост аны өзүнүн ISPси аркылуу жөнөтсө, булак дареги жасалма көрүнөт, жана провайдер же багыт аны таштайт. Чечим — булакка негизделген эреже же атайын маршруттоо таблицасы, кеңири NAT эмес. Онсуз кызмат туннел шеригинен иштейт жана калган бардык жерден ийгиликсиз болот.

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

iptables -t nat -S POSTROUTING

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

Ишенүүдөн мурун эки багытты текшериңиз

Текшерүү бир эмес, төрт байкоо. Провайдердин маршруту келерин, ядро префиксти туннелге жөнөтөрүн, OpenVPN аны туура кардарга таандык кыларын, жана жооп коомдук булак менен бүтүн кайтарын ырастаңыз. Ар бир байкоонун өз буйругу бар, ошондуктан ийгиликсиздик бүт долбоорду эмес, бир катмарды көрсөтөт. Ар бир конфигурация өзгөрүүсүнөн кийин аларды ушундай тартипте аткарыңыз.

Ядродон делегацияланган даректин кайсы жолду аларын сураңыз жана сурамжылоо аткарылып жатканда туннелди байкаңыз:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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

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