OpenVPN арқылы жалпыға қолжетімді префикс: қайту жолын түзету

Туннельдің көтерілуін және клиенттің қарсы жаққа ping жіберуін көріңіз, содан кейін VPN артындағы жалпыға қолжетімді адрес басқа жерден жауап береді немесе мүлдем жауап бермейді. Бұл симптом әдетте шифрмен немесе сертификаттармен ешқандай байланысы жоқ. Провайдер маршруттаған префикс IP маршруты ретінде жеткізіледі, және оны OpenVPN арқылы тасымалдау сол маршрутты екі деңгейде қайта жасау және қайту жолында бастапқы адресті сақтау дегенді білдіреді. WAN-ды көпірлеу қажет емес, және адресті интерфейске қосу жоғарғы маршрутты жасамайды.

Префикс алдымен сізге маршрутталуы керек

Провайдерден блоктың қалай жеткізілетінін сұраңыз. Серверіңіздің негізгі адресіне маршрутталған префикс провайдер WAN сегментінде тікелей жетуді күтетін адрестерден өзгеше нәрсе. Мұндағы дизайнмен тек бірінші модель жұмыс істейді.

Егер провайдер 198.51.100.64/28-ді кіру серверіңізге маршруттаса, сол диапазонның пакеттері серверге жетіп, сіз оларды жібермейінше сонда тоқтайды. Егер провайдер оның орнына диапазонды жоғарғы арнаңызға көпірлесе, сервер ол үшін ARP жауабын беруі керек, бұл басқа мәселе.

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

Маршруттаудың екі деңгейі: ядро маршруты және iroute

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

Сервер жағындағы маршрут осылай көрінеді, префикс пен маска бөлуге сәйкес келуі керек:

ip route add 198.51.100.64/28 dev tun0

Клиентке тән конфигурация меншікті тағайындайды. Оны клиент сертификатының жалпы атымен аталған CCD файлына салыңыз және сервер шынымен сол каталогты оқитынын растаңыз:

iroute 198.51.100.64 255.255.255.240

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

Қызмет адресі қайда тұрады

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

Қызметті жергілікті түрде аяқтайтын Linux клиентінде бір хост адресі жеткілікті:

ip address add 198.51.100.70/32 dev lo

Егер префикс әрі қарай VM хостына немесе басқа LAN-ға маршрутталса, оның орнына сол төменгі жолды және оның қайту маршрутын конфигурациялаңыз. Блоктағы әрбір адресті VPN клиентіне тағайындау қажет емес және кейін қақтығыстар тудырады.

Қайту жолында жалпыға қолжетімді бастапқыны сақтаңыз

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

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

iptables -t nat -S POSTROUTING

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

Сену алдында екі бағытты тексеріңіз

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

Ядродан делегатталған адрестің қай жолды алатынын сұраңыз және сұраныс орындалып жатқанда туннельді бақылаңыз:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Соңында, сәтсіздік жағдайын тексеріңіз. Туннельді тоқтатып, жалпыға қолжетімді префикстің қарапайым жоғарғы арнадан ағып кетпейтінін растаңыз. VPN-ды қалпына келтіру қызметті хост ашатын порттарды кеңейтпестен қайтаруы керек.