WireGuard клиенті OpenVPN клиентіне жете алмай ма?

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

Симптомда әр жолы бір бөлік жетіспейді

Бұл дизайн wg1 интерфейсінде 10.71.0.0/24 WireGuard пулын және tun1 интерфейсінде 10.72.0.0/24 OpenVPN пулын пайдаланады, екеуі де бір шлюзде аяқталады. Сыналатын сұраныс 10.71.0.5 мекенжайынан 10.72.0.30 мекенжайындағы HTTPS-ке барады. Төмендегі әр қадам сол бір ағынға қатысты. Әр тексерудің істен шығу белгісі бөлек, бірақ пайдаланушы оларды бірдей сезінеді, және әдетте бір уақытта үшеуінің біреуі ғана жетіспейді.

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

Тармақтың межелік қамтуын кеңейтіңіз

WireGuard клиентінде бар әріптес жазбасы OpenVPN межелігі үшін шлюзді таңдауы керек, яғни межелік префиксі сол әріптестің рұқсат етілген тізімінде болуы тиіс. Оны қосу екінші туннель жасамайды; ол клиент сол мекенжайды іздегенде қай әріптесті таңдайтынын өзгертеді, ал wg-quick кезінде маршрут әдетте тізімді өздігінен ұстанады.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Нақты кілт пен соңғы нүкте жолдарын тиіспеңіз, және Table = off пайдаланатын басқару құралы бұл тізімнен мүлдем маршрут алмайтынын есте сақтаңыз. Ондай жағдайда сол префиксті жүйенің маршрут кестесіне оған иелік ететін нәрсе орнатуы керек, ал онда жоқ маршрут дәл жоқ рұқсат етілген префикске ұқсайды.

Көздің меншігін шлюзде сақтаңыз

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

AllowedIPs = 10.71.0.5/32

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

OpenVPN жағына қайтару маршрутын беріңіз

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

push "route 10.71.0.0 255.255.255.0"

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

Тек рұқсат беруді ойлаған сол бір қызметке рұқсат беріңіз

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Бұлар қайта бағытталған трафик ережелері, шлюздің екі VPN қызметі үшін тыңдау ережелерінен бөлек. Сыртқы UDP порттарын ашу ішкі сұранысқа рұқсат бермейді, ал ішкі сұранысқа рұқсат беру шлюзге шектеусіз SSH немесе қайта бағыттауға әдепкі рұқсатты талап етпейді. Межеліктің өз firewall-ы мен тыңдау мекенжайы да сәйкесуі керек, өйткені loopback-ке байланған қызмет ең ұқыпты маршрутталған пакетті де қабылдамайды. Әңгіменің бір бағытын ғана қамтитын саясат әдетте сәтті сұраныс пен үнсіз жауаппен сәтсіздікке ұшырайды, бұл үш нәтиженің ең шатастыратыны.

Өзара маршруттар әдетте көз аудармасы қажет емес екенін білдіреді, бұл WireGuard мекенжайын межелікте сақтайды және журналдарды оқылатын етеді. Екі хаттама қатысқаны үшін жалпылама masquerading қоспаңыз, және бар аударма ережесін оған не тәуелді екенін білмей жоймаңыз. Содан кейін сол бір ағынды басынан аяғына дейін тексеріңіз, және бір тыйым салынған көзді немесе портты да сынап көріңіз: әр жақта жұмыс істейтін қол алысу айқас маршрутты да, оқшаулауды да дәлелдемейді.