OpenVPN клиентінің артындағы қосымша желі неге қол жетімсіз?

Сервердің туннель мекенжайына ping сәтті өтеді, клиенттің өз маршрут кестесі дұрыс көрінеді, бірақ сол клиенттің артындағы LAN әлі де қол жетімсіз. Клиенттің маршруттау кестесі дұрыс көрінеді, серверде туннельге бағытталған маршрут бар, ал пакеттер әлі де жоғалады. Бұл layer-3 туннелінің классикалық симптомы, ол өз клиенттерінің бірі шлюз екенін білмейді.

tun интерфейсінде әр клиентке келесі секіріс жоқ. Ядро көптеген серіктесі бар бір интерфейсті көреді, сондықтан қашықтағы LAN үшін пакетті қай клиент алатыны туралы шешім OpenVPN процесінің ішінде қабылдануы керек. Бұл шешім iroute арқылы конфигурацияланады, онсыз пакетке баратын жер жоқ.

Сервер интерфейс бойынша емес, клиент бойынша маршруттайды

Сервер клиенттің туннель мекенжайына пакет жіберуі қажет болғанда, жауап бірауыздан: мекенжай сол клиенттің сессиясына тиесілі. Ал мақсат сол клиенттің артындағы тұтас қосымша желі болғанда, мекенжай сервер білетін ешкімге тиесілі емес, және ядроның туннельге бағытталған маршруты тек «осы интерфейстен» дейді, қай серіктес екенін айтпайды.

OpenVPN мұны мақсат префиксін белгілі бір клиентке байланыстыратын ішкі маршруттау кестесімен шешеді. Ол кесте iroute жазбаларынан құрылады, сондықтан сервер хостындағы қарапайым маршрут жеткіліксіз. Ядро маршруты пакетті туннель интерфейсіне жеткізеді, ал ішкі байланыстыру қай сессияның оны алатынын шешеді. Сондықтан да түзету ядроның маршрут шығысында ешқашан көрінбейді.

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

Клиентті атайтын iroute жазбасын жазу

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

LAN-ы 10.20.0.0/24 және сертификатының ортақ аты branch-router болатын филиал үшін сол жолдағы файлда iroute 10.20.0.0 255.255.255.0 сияқты жол болады. Негізгі конфигурацияға тек каталог опциясы керек; префикс клиентте тұрады.

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

Бір клиент бірнеше префикске ие бола алады. Әр желі үшін бір iroute жолын қосыңыз және байланыстыру тексерілетін болып қалуы үшін тізімді сол клиенттің қалған параметрлерінің қасында ұстаңыз.

Қайтару жолын екі бағытта да құру

Пакеттерді қашықтағы LAN-ға жеткізу — жұмыстың жартысы. Клиент сол LAN трафигін туннельге де жіберуі керек, бұл әдетте клиентке маршрутты итеру арқылы жасалады: push "route 10.8.0.0 255.255.255.0" сияқты жол әр клиентке сервер жағындағы желіге қалай жетуге болатынын айтады. Филиал үшін баламалы маршрут сервер жағында жетуге тиіс барлық нәрсеге туннельді нұсқайды.

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

Сервер хостында жіберу қосылуы керек. Онсыз ядро туннельден пакетті қабылдап, оны LAN интерфейсіне өткізуден бас тартады, бұл клиент тұрғысынан жоқ iroute сияқты көрінеді.

Қолжетімділікті дұрыс зондтармен тексеру

Алыс шетке ping жасап болжау орнына қабат-қабат тексеріңіз. Серверден префикс үшін ішкі байланыстыру бар екенін және ядро маршруты туннельге бағытталғанын тексеріңіз. Клиенттен итерілген маршруттың орнатылғанын және LAN мекенжайы үшін әдепкі жолының туннель екенін растаңыз.

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

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