Екі OpenVPN серверінің клиенттері бір-біріне жете ала ма?

Екінші OpenVPN серверді көтеру клиенттер қосылатын екінші орын береді, одан артық емес. Ол бұл клиенттерді бірінші сервердің желісіне қоспайды, ал client-to-client деп аталатын опция тек бір сервер процесінің ішіндегі жіберуді өзгертеді. Екі пул бір желіге айналады, егер олардың арасында әдейі маршруттасаңыз, әр бағыт үшін бір жауаптымен. Төмендегілердің бәрі пайдаланушы кеңістігіндегі TUN режимін және сол ішкі жіберу өшірулі деп есептейді, сондықтан шешімді ядро қабылдайды.

Аңыз: бір тіркелгі тізімі, бір желі

Аутентификация мен қолжетімділік шатасады, өйткені екеуі де сервер конфигурациясында тұрады. Екі шлюздің кез келгеніне кіре алатын пайдаланушы сырттан екі есігі бар бір жүйенің пайдаланушысындай көрінеді. Ішінде әр сервер өз пулынан мекенжайлар таратады және тек өзі аяқтайтын клиенттер үшін маршруттар орнатады. Сондықтан A шлюзіндегі клиент B шлюзіндегі клиентке пакет жібергенде, өз сервері ешқашан естімеген межелі орынды сұрайды. Пакет A-ның әдепкі маршрутына кетеді, туннельден шығады және оны рұқсат етуді ешқашан сұрамаған брандмауэрге жетеді.

Сондықтан екінші сервер қосу артықтық, табу немесе ортақ хабар тарату доменін қоспайды. Ол жоспар қажет ететін маршрутталған желіні қосады, ал жоспар мекенжайлаудан басталады.

Әр шлюзге өз пулын және транзиттік мекенжайын беріңіз

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

Профильдер бірдей болуы үшін екі серверге бір пул беру азғыруына қарсы тұрыңыз. Ядролық маршрут ортақ диапазон ішіндегі еркін мекенжайды қазір екі хосттың қайсысы ұстап тұрғанын айта алмайды, сондықтан маршруттау кестесі бір шлюзді көрсетер еді, ал клиент екіншісіне қосылған болуы мүмкін. Интерфейс атаулары — жергілікті конвенциялар, ортақ күй емес. Мұнда екі хост та туннель құрылғысын tun0, ал транзиттік байланысты transit0 деп атайды, бұл дұрыс, өйткені ешбір пакет бұл атауларды тасымайды.

Маршрутты екі жаққа орнатыңыз

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Пулдарды ауыстырып, мұны екінші хостта да қайталаңыз. Бірдей маршрутты байланыссыз скрипттен қайта-қайта қосу — хосттың бірнеше көшірмесі және келесі жолы кестені оқығанда жұмбақ өзгерісі қалатын жол. Егер транзиттік байланыс өзі туннель болса, маршрут сол туннельдің топологиясына сілтейді және секіруші оның қайта қосылуынан өтуі керек. Отыз секундқа жоғалатын транзиттік мекенжай пулдар арасындағы жолды да ала кетеді, бұл — ашу емес, жариялауға тұрарлық дизайн қасиеті.

Клиент маршрутын иеленуді жалғансыз жіберіңіз

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

push "route 10.64.20.0 255.255.255.0"

Айна жолын екінші сервердің конфигурациясына қойыңыз, содан кейін сынақ клиентін қайта қосып, оның кестесін оқыңыз. Жіберілген маршруттарды елемейтін клиентке өзінің бекітілген конфигурациясы керек, ал ешқашан жетпейтін маршрут — қатынауды бақылау емес. Клиентке екінші шлюздің бүкіл пулы үшін iroute бермеңіз. Бұл директива бір қосылған клиенттің артындағы ішкі желіге арналған, ал оны шлюздер арасындағы жетіспейтін маршрутты жасыру үшін қолдану өзі жете алмайтын мекенжайларды иеленемін деп ойлайтын сервер жасайды.

Бір сұранысты дәлелдеңіз, екіншісінен бас тартыңыз

Нақты операция таңдаңыз, мысалы 10.64.10.21-дегі клиенттен 10.64.20.37-дегі қызметке HTTPS, және екі хостта дәл соны рұқсат етіңіз. Әр брандмауэр сұранысты кіріс жағында, бақыланатын жауапты қайтару жағында қабылдайды; межелі жердің өз қызмет саясаты оны әлі де қабылдауы керек.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Өзара маршруттар болғанда бастапқы NAT қажет емес және мұнда белсенді түрде зиянды: бастапқыны аудару қай клиент сұраныс жасағанын жасырады және межелі жақтағы бастапқыға негізделген саясатты әлсіретеді. Интернетке шығу үшін бар masquerade ережесі бұл жолды да ұстамайтынын тексеріңіз. Содан кейін бас тартуды сынаңыз. B пулында жергілікті қалуы тиіс қызмет A пулынан қолжетімсіз болып қалуы керек, ал бір шлюздегі клиент жұптарын да сынау керек, өйткені жаңа ғана өзгерткен жіберу саясаты оларға да қатысты.

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