OpenVPN әлі де ескі маршруттарды итермелеп жүр ме? Ол нені жүктегенін тексеріңіз

Маршрут қосасыз, қызметті қайта іске қосасыз, қайта қосыласыз, ал клиенттің кестесі бұрынғыдай болып қалады. Екі түрлі нәрсе дұрыс болуы мүмкін: сервер сіздің өзгерісіңізді жүктемеген, немесе клиент алғанын орнатпаған. Симптомнан басқа ортақ ештеңе жоқ, сондықтан бірінші қадам қай жағдай екенін анықтау.

Төмендегі салыстыру процестен сыртқа қарай жүреді, өйткені қай файлдың күшінде екенін тек процесс біледі.

Сіз өңдеген файл және процесс оқитын файл

unit пен оның жасаған пәрмен жолынан бастаңыз. systemd хостында systemctl cat openvpn@server ExecStart жолын басып шығарады, ал instance unit әдетте конфигурация жолын instance атауынан алады, сондықтан openvpn@office ретінде іске қосылған демон openvpn@server ретінде іске қосылғаннан өзге файлды оқиды. Мұны істеп тұрған процестің argv-імен салыстырыңыз. Конфигурацияны басқару құралы өзгерісті жоғалтудың тағы бір жолын қосады: ол дұрыс файлды unit ешқашан атамайтын жерге жаза алады, сонда сәтті орналастыру ештеңе істемегендей көрінеді.

Уақыт белгілері мұны тез шешеді: файл процестің басталу уақытынан жаңарақ болса, процесс оны оқи алмаған. Маршрутизатор firmware-і үшінші жағдайды қосады, өйткені көптеген үлгілер параметрлерін flash-та сақтайды және жүктелу кезінде конфигурацияны қайта құрады, бұл дискідегі файлды өңдеуді мүлде дұрыс емес қабатқа айналдырады.

Сервер нені итермелейді және клиент нені орнатады

Жіберілген маршрут екі сүзгіден өтуі керек. Серверде ол жүктелген конфигурацияда болуы керек, түсініктемеге алынған блокта немесе аты сәйкес келмейтін клиентке тән файлда емес. Клиентте pull қосулы болуы керек және ешбір pull-filter бұл опцияны лақтырмауы керек. verbosity 4-пен қосылып, клиент хабарлайтын жіберілген опцияларды оқыңыз: маршрут сол тізімде болса, сервер өз жұмысын істеді, ал оны орнатпауды клиент таңдап отыр.

Клиентке тән файлдар жиі шатасудың көзі болады. Сертификаттың common name-і бойынша аталған файл опцияларды тек сол клиентке жібереді, ал бір таңба айырмашылығы жіберуді үнсіз тоқтатады, екі жақта да қате көрінбейді. Сервер қосылу кезінде көрген common name-ді жазады, сондықтан бұл мәнді файл атымен салыстырыңыз, клиенттің аты деп ойлағаныңызбен емес.

Жіберілген префикс және қайту маршруты екі бөлек мәселе

Өзінің жергілікті интернет жолын сақтау үшін redirect-gateway-ті әдейі елемейтін клиент екінші, байланысы жоқ олқылық жасайды. Сервердің зондтары туннель мекенжайына жетеді, ал жауаптар ешқашан келмейді, өйткені сервердің туннель IP-іне жіберілген жауап клиенттің қарапайым әдепкі шлюзі арқылы маршрутталады. Мұнда жіберілген ішкі желі маршруты кінәлі емес; жетіспейтіні сервердің туннель желісінің трафигін туннель құрылғысы арқылы қайтаратын маршрут.

Осы маршрутты клиентте қосу сервер бастаған зондтарға жауаптарды түзейді. Ол жіберілген ішкі желі маршрутын алмастырмайды, керісінше де солай, өйткені екеуі қарсы бағыттарды сипаттайды.

Екі ұшындағы кестелерді салыстырыңыз

Кез келген өзгерістен кейін қайта қосылып, клиенттің кестесінен жіберілген префиксті және туннель құрылғысын оқыңыз. Содан кейін екі бағытта тексеріңіз: клиенттен жіберілген ішкі желідегі хостқа және сол хосттан кері клиентке. Бар болса да трафикті тасымайтын маршрут үшеудің бірін білдіреді: алыс жақ жібермейді, firewall ағынды тастайды, немесе жауаптың қайту жолы жоқ.

Үш идентификаторды бірге ұстаңыз: конфигурация жолы, unit немесе instance атауы және сынақ жүргізген клиенттің бірегейлігі.

Осы үшеу келесі оқиғаны қайта тергеудің орнына бес минуттық тексеріске айналдырады, әрі туннель басқа біреудің мәселесіне айналғанда әріптесіңізге керегі де осы.

Қайта іске қосудан аман қалған маршрут мәселесі көбіне маршруттау мәселесі де емес; ақау сіз үнемі оқып отырған кестеден жоғарырақ тұр.