Доступ да кліента IKEv2 на яго прызначаным віртуальным IP

Шлюзу трэба пачаць злучэнне з ноўтбукам, падключаным да яго праз 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

Пошук маршруту адказвае, якую крыніцу і інтэрфейс выкарыстае шлюз, і менавіта гэтае значэнне павінна дапусціць палітыка. Запіс павінен паказаць, што запыт выходзіць унутры ESP, а не як звычайны TCP на публічным інтэрфейсе. На кліенце запішыце расшыфраваны трафік, каб пацвердзіць прыход і тое, ці адказала служба. Калі запыт знікае без ESP у сетцы, падазравайце адрас крыніцы раней за брандмаўэр кліента.

Паўтарыце тэст пасля змены ключа або перападключэння, бо VIP можа змяніцца. Шлях, які працуе толькі да наступнай сесіі, не з’яўляецца працоўным шляхам.