Бір жеке ішкі желі үшін жұмыс істейтін strongSwan қосылымы біреу бір жолды өңдеді деп интернет трафигін тасымалдамайды. Толық туннель — child SA қандай мекенжайларды қорғайтыны туралы екі тараптың келісімі, және әр тарап екіншісін өзіне қатысты атайды. Бір жағын дұрыс, екіншісін қате қылсаңыз, child SA не көтерілмейді, не көзделгеннен тар көтеріледі. Төмендегі бес тексеру осы келісімді клиенттен шлюз арқылы интернетке дейін қадағалайды.

Алдымен клиенттің селекторын тексеріңіз

Клиент қашық жақта қорғағысы келетінін remote_ts ретінде сипаттайды, ал жіберетіннің бәрі өзіне берілген мекенжайдан шығады. Интернет трафигі үшін бұл мән пайдаланушы шынымен жететін межелерді қамтуы керек, бұл іс жүзінде бүкіл IPv4 кеңістігін білдіреді. Әлі де бір ішкі желіні тізбелейтін клиент бөлінген туннель сұрайды, профиль интерфейсте қалай аталса да. Бастау жағы әдетте dynamic, өйткені мекенжай қосылу кезінде беріледі. Сол жерде жазылған тұрақты бастау мекенжайлар пулы өзгергенде бұзылады.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Бұл үзінді толық қосылым файлы емес және аутентификация, сәйкестіктер және виртуалды мекенжайлар пулы әлдеқашан конфигурацияланған деп есептейді. Клиенттің бастау селекторы мен сервер беретін мекенжай әлі де сәйкесуі керек, әйтпесе child SA екі жақ та күтпеген ауқыммен көтеріледі. Оны swanctl --load-all көмегімен жүктеп, табысқа сенбес бұрын шығысты оқыңыз. Талданатын файл да басқа жақтың ұсынысымен қабаттаспайтын селекторға байланысты қабылданбауы мүмкін.

Шлюздің селекторын өз жағында тексеріңіз

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Клиент үзіндісін шлюз файлына көшіру пайдалы ештеңені сипаттамайтын селектор жұбын жасайды, өйткені екі жақ бір рөлді талап етеді. strongSwan қайта бағыттау нұсқаулығы клиент пен шлюздің жұптасуын айқын құжаттайды және оны сәтсіздіктен кейін емес, қосылым файлының жанында оқыған жөн. Шлюз файлына remote_ts сілтейтін пулдың анықтамасы да қажет. Жоқ пулды атайтын селектор шағымсыз жүктеледі және қосылу кезінде сәтсіз болады.

Ескі ipsec.conf әртүрлі кілттермен сол және оң рөлдерді пайдаланады, ал rightsubnet жолы swanctl мәнінің тікелей орнын баспайды. Екі синтаксисті бірін екіншісіне қоюдың орнына бөлек файлдарда ұстаңыз. Оларды бір каталогта араластыру — жұмыс істеп тұрған қосылымның қайта жүктеуден кейін үнсіз артқа қайту жолы.

Келісілген child SA-ны тексеріңіз, файлды емес

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Бірінші команда демонның нені жүктегенін, екіншісі орнатылған child SA-ларды, үшіншісі ядро қолданатын саясаттарды көрсетеді. Егер файл 0.0.0.0/0 десе және тізім бір ішкі желіні көрсетсе, келіссөз ауқымды тарылтқан және файлды қайта оқу мұны түсіндірмейді. child-ты тоқтатыңыз, қайта іске қосыңыз және үш шығысты қайта салыстырыңыз. Сол тар ауқыммен қайтатын child жергілікті файлмен емес, алыс жақпен тарылтылған, және бұл жергілікті өңдеу емес, басқа әкімшімен әңгіме.

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

Қайта бағыттауды және қайтару маршрутын тексеріңіз

Селектор трафикті шлюзге жіберуге рұқсат етеді, бірақ шлюзді оны әрі қарай маршруттауға мәжбүрлемейді. Қайта бағыттау қосулы болуы керек, брандмауэр ағынды рұқсат етуі керек және жауап клиенттер пулына қайту жолын табуы керек. Бұл үш бөлек талап және әрқайсысы әртүрлі белгімен сәтсіз болады. Жетіспейтін қайта бағыттау ережесі қара құрдым сияқты әрекет етеді, ал жетіспейтін қайтару маршруты бір бағытты туннель сияқты.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Жеке клиент мекенжайлары әдетте жария интерфейстен шығар алдында әдейі бастау аудармасын қажет етеді, ал айқын маршрутталған бөлу басқа өңдеуді талап етеді. NAT қатысса, іске асыру қолдайтын ерекшеліктерді сақтаңыз, сонда қауіпсіздік саясаты тексеруі тиіс трафик оның жанынан аударылып өтпейді. Басқа шлюзден көшірілген кең masquerade ережесі авторы көздегеннен әлдеқайда көп ағынды өзгертеді. Ережені тек клиенттер пулы үшін жазыңыз және оның неге бар екенін түсіндіретін түсініктеме қалдырыңыз.

Клиентте сіз болжаған маршруттарды емес, backend орнатқан маршруттарды растаңыз. Маршрут орнату өшірілген менеджерге қолмен ұсталатын маршруттау дизайны қажет және бұл дизайн туннель өзгерген сайын жаңартылуы керек. Маршруттау кестесін қайта қосылғаннан кейін тексеріңіз, тек жаңа жүктеуден кейін емес.

Туннель әлі нені қамтымайтынын тексеріңіз

Селектор жұбы IPv4-ті қамтиды, басқа ештеңе емес. IPv6, DNS және кез келген қолданбалы деңгейдегі саясат — кең IPv4 селекторы үнсіз елемейтін бөлек шешімдер. Әр IPv4 пакетін тасымалдайтын туннель де әрбір атау іздеуін ағызуы мүмкін.

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Жоғарыдағы тізімнен келісілген селекторлармен бірге осы екі команда арқылы тізбекті растаңыз. Егер traceroute жергілікті маршрутизаторды бірінші секіріс ретінде көрсетсе, селекторлар не десе де, трафик туннельді пайдаланбайды. Интернетке қолжетімділік таңдалған трафик жобаланған шлюз арқылы рұқсат етіліп, қайта бағытталып және қайтарылғанда ғана толық. Профильде 0.0.0.0/0 табу — сол тізбектің басы, оның дәлелі емес.

Қатысты мақалалар