Бір OpenVPN клиентіндегі екі қызмет мекенжайы: iroute және lo

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

Бүркеншік ат жергілікті, иелік қашықта

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

Клиентте мекенжай хостқа тиесілі, ал loopback — физикалық байланыста ешқашан көрінбеуі тиіс қызмет сәйкестігінің табиғи үйі. Хабта теңдесті префикске салыстыру — тек сервер оқитын бөлек декларация. Екі жазбаның ешқайсысы екіншісін білдірмейді.

Екі диапазонды жазбаларыңызда да бөлек ұстаңыз. Мысалдағы мекенжайлар құжаттамалық мәндер, ал оларды нақты LAN-мен қабаттастыру — жұмыс істеп тұрған конфигурацияны бұзылған көрсетудің ең жылдам жолы.

Мекенжайды клиентке тұрақты түрде қосыңыз

Қызмет мекенжайын хост префиксімен loopback-ке қойыңыз, хост оны жетуге тиіс ішкі желі ретінде емес, жергілікті кіріс ретінде қарастырсын. ip address add 10.66.0.10/32 dev lo мұны бір мекенжай үшін жасайды, ал екінші мекенжай үшін команданы қайталау екі қызметті үлгілейді.

Мұны бір реттік тест ретінде іске қосыңыз, содан кейін оны хосттың желілік конфигурациясына ие нәрсеге көшіріңіз, өйткені орындалу кезіндегі қосымша қайта жүктеуде жоғалады және қайта қосылулар арасында көшірмелер жинақталады. Желіден кейін реттелген systemd бірлігі — бір нұсқа, ал таратымның желілік менеджері — екіншісі. Қайсысын таңдасаңыз да, мекенжай қолданба қосылмас бұрын болуы керек, әйтпесе қызмет дұрыс емес сокетте шығады. Қолмен командадан кейін емес, қайта жүктеуден кейін ip address show dev lo арқылы тексеріңіз.

Байланыстыру — мекенжайдаудан бөлек шешім. Әр мекенжайда тыңдайтын қолданба сіз ешқашан көздемеген интерфейстерде трафик қабылдайды, сондықтан оны нақты қызмет мекенжайына бағыттаңыз. Сонда жергілікті кіріс саясатының нақты сәйкестендіретін нәрсесі болады.

Оны хаб шын мәнінде оқитын CCD файлында талап етіңіз

Серверде иелік декларациясы аутентификацияланған ортақ атаумен таңдалатын әр клиент файлына түседі, client-config-dir атаған каталогтың ішінде. Жол — iroute 10.66.0.10 255.255.255.255, әр мекенжайға бір, және ол серверге қай теңдестің сол тағайындалған жерге трафик алуы керектігін айтады.

Екі бөлшек мұны үнсіз бұзады. Файл атауы сервер шын мәнінде қолданатын атауға сәйкес болуы керек, ол username-as-common-name ойында болғанда өзгеше болады. Ал iroute тек TUN режимінде клиент конфигурациясының каталогы конфигурацияланғанда күшіне енеді, сондықтан бірдей жол көпірлі орналастыруда ештеңе істемейді. Жолдарды бар файлға қосыңыз, оны ауыстырмаңыз, өйткені онда бұрыннан тұрақты мекенжай немесе push опциялары болуы мүмкін. OpenVPN 2.6 анықтамалығы каталогты да, иелік директивасын да құжаттайды.

Хабтың өз ядросына да сол тағайындалған жерлерге жол қажет, жергілікті түзілген трафик туннель процесіне кірсін. Сервер конфигурациясындағы route 10.66.0.10 255.255.255.255 сервер өзі тудыратын трафикті қамтиды, ал басқа клиенттерге тағайындалған жерді өздері үйрену үшін push "route 10.66.0.10 255.255.255.255" қажет.

Маршруттау мен авторизация бөлек қалады. Жіберілген маршрут клиентке пакеттерді қайда жіберу керегін айтады және ештеңе бермейді; қызмет шақырушыны өз шарттарымен қабылдауы керек.

Кіріс саясатын және жауап жолын тексеріңіз

Бүркеншік атқа адрестелген пакет ие хостқа жергілікті кіріс ретінде жетеді, сондықтан сұрақ — жергілікті файрвол сол көз бен портқа рұқсат бере ме. Бүкіл мекенжайды ашудың орнына VPN көз диапазонынан нақты қызмет портына рұқсат беріңіз.

Жауаптарға шақырушыға қайтатын жол қажет. Қалыпты туннель пулының ішіндегі шақырушы үшін бұл жол бұрыннан бар, өйткені оны туннель құрылғысы тасымалдайды. Басқа маршрутталған желінің артындағы шақырушыға сол желінің қайтару маршруты да қажет, және дәл осында асимметриялық конфигурациялар пакеттерді жоғалтады.

Бір портта басқа мекенжайға байланған екінші тыңдаушыға назар аударыңыз, өйткені ядро сәйкес келген сокетке жеткізеді және нәтижелер кездейсоқ көрінеді. ss -lntp арқылы тексеріңіз және байланған мекенжай қызметтің бүркеншік аты екенін растаңыз. Мұнда көз NAT қажет емес, ал оны қосу журналдарыңыз тәуелді шақырушының сәйкестігін жасырады.

Мекенжайлар мен иелікті бөлек тексеріңіз

Екі қадаммен тексеріңіз. Алдымен ие хосттың бүркеншік атындағы қызметке өзінен жете алатынын растаңыз, бұл байланыстыру мен файрвол мәселелерін маршруттаудан бөледі. Содан кейін қолданбаның өз аутентификациясын пайдаланып нақты VPN шақырушысынан тексеріңіз. Біріншісі өтіп, екіншісі сәтсіз болса, жетіспейтін бөлік хаб жағында.

Байланыстан кейін де қалатын ақау режимдерін де тексеріңіз: туннель өшірулі болса да бүркеншік ат тағайындалған күйде қалады, ал теңдес жоқ болса да хаб өз маршрутын сақтайды. Ешбір нысан жалғыз өзі қызметтің қолжетімді екенін дәлелдемейді, сондықтан екі қадамдық тест ноутбуктен бір ping-нен артық.