Pag-abot sa isang kliyente ng IKEv2 sa itinalagang virtual IP nito

Kailangang magsimula ng koneksyon ang isang gateway patungo sa isang laptop na nakakonekta rito sa pamamagitan ng IKEv2, gamit ang virtual address na itinalaga sa kliyenteng iyon. Bukas ang tunel, naaabot ng kliyente ang lahat sa likod ng gateway, at nabibigo pa rin ang kabaligtarang direksyon. Normal ang asimetriyang iyon: inilalarawan ng napagkasunduang patakaran kung aling mga address ang maaaring mag-usap, hindi kung aling panig ang maaaring magsimula. Tatlong bagay ang dapat magtugma bago gumana ang kahilingang sinimulan ng gateway.

Hindi inaayos ng tunel ang pinagmulang address

Sakop ng isang CHILD SA ang isang pares ng mga tagapili ng trapiko, isa sa bawat panig, at pinapayagan ang trapiko sa dalawang direksyon ng pares na iyon. Wala itong sinasabi tungkol sa kung aling peer ang unang nagbukas ng palitan ng IKE. Ang gateway na noong una ay nakikinig para sa tunel ay maaari pa ring magpadala ng unang packet ng aplikasyon, basta ang napiling pinagmulan at destinasyon ay nasa loob ng mga naka-install na tagapili. Kapag lumabas ang kahilingan sa maling interface, hindi lang ito karapat-dapat para sa tunel.

Kailangan ang pagruruta patungo sa kliyente at hindi sapat. Dapat tanggapin ng patakaran ang pinagmulang aktwal mong ginamit.

Basahin ang naka-install na patakaran, hindi ang config file

Magsimula sa aktibong asosasyon at sa mga tagapili nito, dahil binabago ng dinamikong paglalaan ang naka-install sa kernel.

ipsec statusall
ip xfrm policy

Pinapangalanan ng output ng estado ang koneksyon, ang itinalagang virtual address at ang mga tagapiling kasalukuyang may bisa para sa peer na iyon. Ipinapakita ng dump ng patakaran ang parehong mga tagapili bilang estado ng kernel, at iyon ang aktwal na kinukonsulta ng pagpili ng packet. Ihambing ang tagapili sa panig ng gateway sa pinagmulang gagamitin ng iyong aplikasyon, dahil agad na ipinapaliwanag ng pagkakaiba ang kabiguan. Basahin ang kasalukuyang address ng kliyente at hindi ang mula sa nakaraang sesyon, dahil binabalewala ng muling itinalagang VIP ang lumang patakaran.

Dapat makinig ang kliyente kung saan dumarating ang packet

Kahit ang perpektong patakaran ay umaabot sa saradong port kapag ang serbisyo ay nakagapos lamang sa loopback. Dapat nasa itinalagang address o sa lokal na wildcard address ang tagapakinig.

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

Ipinapakita ng listahan ng socket kung nakagapos ang port sa virtual address, at ipinapakita ng mga tuntunin ng firewall kung tinatanggap ang mga bagong koneksyon mula sa protektadong pinagmulan. Ang tuntuning isinulat para sa mga naitatag na koneksyon ay hindi tumatanggap ng koneksyong sinisimulan ng gateway. Panatilihin ang sariling pagpapatotoo ng serbisyo, dahil ang pagdating sa tunel ay nagtatatag lamang kung saang network nagmula ang packet. Ang kliyenteng nasa likod ng sariling NAT ay hindi pa rin kailangan ng papasok na port forwarding, dahil naglalakbay ang mga kahilingang ito sa loob ng umiiral na tunel.

Subukan ang bagong direksyon nang hiwalay

Ang matagumpay na kahilingan mula kliyente patungo sa server ay hindi kailanman sumusubok sa landas na ito. Bumuo ng kahilingan mula sa gateway at obserbahan ang dalawang dulo.

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

Sinasagot ng paghahanap ng ruta kung aling pinagmulan at interface ang gagamitin ng gateway, at iyon ang halagang dapat tanggapin ng patakaran. Dapat ipakita ng capture ang kahilingang lumalabas sa loob ng ESP at hindi bilang payak na TCP sa pampublikong interface. Sa kliyente, i-capture ang na-decrypt na trapiko upang kumpirmahin ang pagdating at kung tumugon ang serbisyo. Kung mawawala ang kahilingan nang walang ESP sa linya, paghinalaan ang pinagmulang address bago ang firewall ng kliyente.

Ulitin ang pagsubok pagkatapos ng pagpalit ng susi o muling pagkonekta, dahil maaaring magbago ang VIP. Ang landas na gumagana lamang hanggang sa susunod na sesyon ay hindi gumaganang landas.