Қашықтағы пайдаланушылар VPN хабы арқылы екінші сайтқа жете алмайды

Қашықтағы пайдаланушы хабқа қосылады, хабтың өз LAN желісіндегі файл серверіне жетеді және бәрі дұрыс көрінеді. Содан кейін ол бас кеңседегі 10.20.0.50 мекенжайындағы ортақ буманы ашады, оған хаб бөлек сайт-сайт туннелі арқылы жетеді, бірақ күту уақыты бітеді. Екі туннель де көтерілген және екі есептегіш те өсуде, сондықтан ешбір туннель бұзылмаған. Хабтан өту — үш құрылғыдағы үш маршруттау шешімі, және туннель тек өзі құрылған префикстерді тасымалдайды. Міне, мен тексеретін рет және әр қадамның дұрыстығын көрсететін пәрмен.

Өту үш іздеуді қажет етеді, бір туннельді емес

Әр құрылғы өзінің ең ұзын префиксін сәйкестендіріп, оны ұмытып кетеді. Ноутбук 10.20.0.50-ді жергілікті маршрутизаторға емес, туннельге жіберуі керек. Хаб қашықтан қатынау интерфейсіне келген пакетті қабылдап, оны сайт-сайт интерфейсіне беруі керек. Бас кеңсе пайдаланушы мекенжайына жауапты туннель арқылы кері жіберуі керек. Осы үшеуінің кез келгенінің сәтсіздігі браузерде бірдей көрінеді: тыныштық.

Сондықтан әр туннельді жеке тексеру өте аз дәлелдейді. Хабтың LAN мекенжайына ping жасау бірінші шешімді тексереді, ал бас кеңседен хабқа ping жасау үшіншісін тексереді. Сәтсіз пакеттің көзі пайдаланушылар пулы, ал межелі жері екінші сайт, сондықтан алдымен сол префикстерді жазып алыңыз. Мұнда пул — 10.80.0.0/24, хабтың LAN-ы — 10.10.0.0/24, бас кеңсе — 10.20.0.0/24.

Алыс префиксті қашықтағы клиентке итеріңіз

Бір OpenVPN қашықтан қатынау серверінде клиент маршруттарды қосылу кезінде үйренеді. push жоқ болса, бөлінген туннельді клиент 10.20.0.50-ді өз қақпасына жібереді және пакет туннельге ешқашан кірмейді.

push "route 10.20.0.0 255.255.255.0"

Итерілген маршрут клиент қосылғанда күшіне енеді, сондықтан желіде қалған пайдаланушы қайта қосылғанша ештеңе көрмейді. Клиентте тексеріңіз: Linux-те ip route get 10.20.0.50, Windows-та route print. Шығыс туннель интерфейсінің атын көрсетуі керек.

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

Хабқа нақты шығу маршрутын беріңіз

Хабқа бас кеңсе префиксі үшін өзінің келесі хопы қажет. Маршрутталған туннельде бұл сайт-сайт интерфейсі арқылы өтетін қарапайым маршрут, ал бір пәрмен таңдалған маршрутты да, таңдалған көзді де көрсетеді:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Сайт-сайт тармағы өзі OpenVPN болса, маршрут сол конфигурацияда серіктестің туннель мекенжайын қақпа ретінде ұстай алады: route 10.20.0.0 255.255.255.0 172.30.0.2. Қақпа міндетті. Оны қалдырып кетсеңіз, келесі хоп іске асырудың әдепкі мәніне түседі, ол бір қашықтағы клиент пен бірнеше серіктесті хаб арасында өзгеше.

Саясатқа негізделген IPsec басқаша: хабтың ядросы пакетті әдеттегі LAN қақпасына жібереді және саясат оны шығу жолында ұстап алады, сондықтан туннель маршруты не ештеңе істемейді, не трафикті саясатты айналып өткізеді. Жоғарыдағы пәрмендегі көзге назар аударыңыз, өйткені пул мекенжайының орнына 10.10.0.1 болса, ядро алыс жақ қабылдамайтын мекенжайды таңдағаны. iroute те жауап емес; ол серверге қай клиент өз туннелінің артындағы қосалқы желіге ие екенін айтады, үшінші сайт үшін трафикті қайда жіберу керектігін емес.

Алыс жақты пайдаланушылар пулына дейін кеңейтіңіз

Бас кеңсе хабтың LAN-ын, 10.10.0.0/24-ті әлдеқашан қамтиды. Пайдаланушылар пулы — екінші префикс және ол селекторларда да болуы керек, әйтпесе 10.80.0.25-ке жіберілген жауапты ешбір саясат қамтымайды. Әр серіктес өз жағынан префикс жиынтықтарының сол жұбын атайды:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Бір құрылғының local_ts мәні екіншісінің remote_ts мәні. Хаб блогын бас кеңсеге көшіріңіз, жұп төңкеріледі, сондықтан еншілес SA ешқашан көтерілмейді.

Ескірек ipsec.conf синтаксисі үтірмен бөлінген leftsubnet қолданады. Жұмыс істеп тұрған қауіпсіздік қауымдастығы келісілген селекторларды сақтайды, сондықтан өңдеуден кейін туннельді қайта орнатыңыз. 10:00-де өзгертілген селектор 09:40-та көтерілген SA-ға қарсы сыналса, әлі де сәтсіз болады, ал конфигурация файлы бүкіл уақытта дұрыс көрінеді.

Содан кейін соңғы хопты тексеріңіз. Алыс шеттегі ip route get 10.80.0.25 туннельге қарай бағытталуы керек. Егер қызмет LAN маршрутизаторын әдепкі қақпасы ретінде пайдаланса, сол маршрутизаторға да қайтару маршруты қажет, әйтпесе жауап сонда өледі. Сол сегментте tcpdump -ni eth1 host 10.80.0.25 іске қосу жауаптың шеттен шыққанын көрсетеді.

Хабта ағынға рұқсат беріңіз

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Кері жол сүзгісі — оның жанындағы тыныш сәтсіздік: екі тармақ түрлі интерфейстерде болса, rp_filter=1 жауапты тастай алады, ал қабылдау ережесінің есептегіші мүлде қозғалмайды. Әрекеттен бұрын және кейін iptables -vnL FORWARD салыстырыңыз. Ешқашан өспейтін ережеге жетпейді, сондықтан оны қайта жазудың орнына бір қабат төмен қараңыз.

Егер өту тек бір топқа қажет болса, жаһандық push-ты кеңейтудің орнына маршрутты client-config-dir астындағы әр клиенттің файлына қойыңыз. Хабтағы Source NAT та алыс жақтың қайтару маршрутының қажеттілігін жояды, бірақ ол пайдаланушы мекенжайын жасырады, сондықтан алыс сайттың журналдары мен мекенжайға негізделген ережелер пайдаланушыларды ажырата алмайды.

Клиенттен тексеріңіз, содан кейін кері ретпен қайтарыңыз

Тек ICMP емес, TCP портын сынаңыз, өйткені ping өтуі мүмкін, ал қызмет бұғаттаулы қалады. Клиенттен nc -vz 10.20.0.50 445 және traceroute -n 10.20.0.50 екінші хоп хабтың туннель мекенжайы екенін көрсетеді. Хабта tcpdump -ni tun0 host 10.20.0.50 және сайт-сайт интерфейсіндегі сол сүзгі: екеуінде де сұраныс, бірақ ешқайсында жауап жоқ болса, мәселе алыс жаққа көшеді.

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

Қайтару тізімін ұстаңыз, өйткені төрт нысан өзгерді және үшеуін ұмыту оңай: итерілген маршрут, хабтың маршруты, селекторлар және желіаралық экран ережелері. Оларды кері ретпен болдырмаңыз, SA-ны қайта орнатыңыз және бір пайдаланушыға қайта қосылуға рұқсат етіңіз. Ішінара қайтару енді сәйкес келмейтін туннельге сілтейтін маршрут қалдырады, оны оқу бастапқы тыныштықтан қиынырақ. OpenVPN 2.6 нұсқаулығы сіздің нұсқаңыз үшін push, route және iroute құжаттайды.