Эки 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 колдонмону өзү аутентификациялайт, ошондуктан ички кызмат аны колдонууну улантышы керек.