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 кошпогула, жана бар котормо эрежесин ага эмне көз каранды экенин билбей туруп өчүрбөгүлө. Андан кийин ошол бир агымды башынан аягына чейин текшергиле, жана бир тыюу салынган булакты же портту да сынап көргүлө: ар тарапта иштеген кол алышуу кайчылаш маршрутту да, обочолонууну да далилдебейт.