IKEv2 клиентіне оның берілген виртуалды IP-де жету

Шлюзден IKEv2 клиентіне басталған сұраныс сәйкес селекторды, дұрыс жергілікті көзді және қолжетімді мекенжайда тыңдаушыны қажет етеді. Үшеуін тексеріңіз.

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

Туннель көз мекенжайын түзетпейді

CHILD SA трафик селекторларының жұбын қамтиды, әр жаққа біреу, және сол жұптың екі бағытында да трафикке рұқсат береді. Ол IKE алмасуын қай серіктестің бірінші ашқаны туралы ештеңе айтпайды. Бастапқыда туннельді тыңдаған шлюз бірінші қолданба пакетін әлі де жібере алады, егер таңдалған көз бен меже орнатылған селекторлардың ішінде болса. Сұраныс дұрыс емес интерфейстен шыққанда, ол туннельге жарамсыз болып қалады.

Клиентке қарай маршруттау қажет және жеткіліксіз. Саясат сіз шын мәнінде пайдаланған көзді рұқсат етуі керек.

Орнатылған саясатты оқыңыз, конфигурация файлын емес

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

ipsec statusall
ip xfrm policy

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

Клиент пакет жететін жерде тыңдауы керек

Тіпті мінсіз саясат та қызмет тек loopback-ке байланғанда жабық портқа жетеді. Тыңдаушы берілген мекенжайда немесе жергілікті әмбебап мекенжайда болуы керек.

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

Жаңа бағытты жеке сынаңыз

Клиенттен серверге сәтті сұраныс бұл жолды ешқашан сынамайды. Сұранысты шлюзден жасап, екі ұшын да бақылаңыз.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Маршрутты іздеу шлюздің қай көзді және интерфейсті пайдаланатынын жауаптайды, және саясат рұқсат етуі керек мән осы. Жазу сұраныстың ашық интерфейсте қарапайым TCP ретінде емес, ESP ішінде шығатынын көрсетуі керек. Клиентте келуді және қызметтің жауабын растау үшін шифры ашылған трафикті жазып алыңыз. Егер сұраныс желіде ESP-сыз жоғалып кетсе, клиенттің қабырғасынан бұрын көз мекенжайынан күдіктеніңіз.

Кілт жаңартылғаннан немесе қайта қосылғаннан кейін тестті қайталаңыз, өйткені VIP өзгеруі мүмкін. Тек келесі сессияға дейін жұмыс істейтін жол — жұмыс істейтін жол емес.

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