Atingi IKEv2-klienton ĉe ĝia asignita virtuala IP

Pordego devas komenci konekton al tekkomputilo konektita al ĝi per IKEv2, uzante la asignitan virtualan adreson de tiu kliento. La tunelo estas supre, la kliento atingas ĉion malantaŭ la pordego, kaj la kontraŭa direkto ankoraŭ malsukcesas. Tiu nesimetrio estas normala: la intertraktita regularo priskribas kiujn adresojn rajtas paroli, ne kiun flankon rajtas komenci. Tri aferoj devas kongrui antaŭ ol peto komencita de la pordego funkcios.

La tunelo ne riparas la fontan adreson

CHILD SA kovras paron da trafikaj selektiloj, po unu por ĉiu flanko, kaj permesas trafikon en ambaŭ direktoj de tiu paro. Ĝi diras nenion pri tio, kiu samtavolano unue malfermis la IKE-interŝanĝon. Pordego, kiu komence aŭskultis por la tunelo, ankoraŭ povas sendi la unuan aplikaĵan pakon, kondiĉe ke la elektita fonto kaj celo falas ene de la instalitaj selektiloj. Kiam la peto eliras el la malĝusta interfaco, ĝi simple ne estas elektebla por la tunelo.

Enkursigado al la kliento estas necesa kaj ne sufiĉa. La regularo devas akcepti la fonton, kiun vi efektive uzis.

Legu la instalitan regularon, ne la agordan dosieron

Komencu de la aktiva asocio kaj ĝiaj selektiloj, ĉar dinamika asigno ŝanĝas tion, kio estas instalita en la kerno.

ipsec statusall
ip xfrm policy

La statusa eligo nomas la konekton, la asignitan virtualan adreson kaj la selektilojn nun validajn por tiu samtavolano. La regulara elŝuto montras la samajn selektilojn kiel kernan staton, kaj ĝin efektive konsultas la pakoelekto. Komparu la selektilon flanke de la pordego kun la fonto, kiun uzos via aplikaĵo, ĉar malkongruo tuj klarigas la malsukceson. Legu la nunan adreson de la kliento, ne tiun el antaŭa kunsido, ĉar reasignita VIP nuligas la malnovan regularon.

La kliento devas aŭskulti tie, kie la pako alvenas

Eĉ perfekta regularo atingas fermitan pordon, kiam la servo ligiĝas nur al loopback. La aŭskultanto devas esti sur la asignita adreso aŭ sur komodina loka adreso.

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

La inga listo montras, ĉu la pordo estas ligita al la virtuala adreso, kaj la fajroŝirmilaj reguloj montras, ĉu novaj konektoj estas akceptataj de la protektita fonto. Regulo skribita por establitaj konektoj ne permesas konekton, kiun komencas la pordego. Konservu la propran aŭtentikigon de la servo, ĉar alveno tra la tunelo nur establas, el kiu reto la pako venis. Kliento malantaŭ sia propra NAT ankoraŭ bezonas neniun envenan pordopluksendadon, ĉar ĉi tiuj petoj vojaĝas ene de la ekzistanta tunelo.

Testu la novan direkton memstare

Funkcianta peto de kliento al servilo neniam ekzercas ĉi tiun vojon. Generu la peton el la pordego kaj observu ambaŭ finojn.

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

La voja serĉo respondas, kiun fonton kaj interfacon la pordego uzus, kaj tio estas la valoro, kiun la regularo devas akcepti. La kaptaĵo devus montri la peton eliranta ene de ESP, ne kiel ordinara TCP sur la publika interfaco. Ĉe la kliento, kaptu la malĉifritan trafikon por konfirmi la alvenon kaj ĉu la servo respondis. Se la peto malaperas sen ESP en la drato, suspektu la fontan adreson antaŭ la fajroŝirmilo de la kliento.

Ripetu la teston post ŝlosilŝanĝo aŭ rekonekto, ĉar la VIP povas ŝanĝiĝi. Vojo, kiu funkcias nur ĝis la sekva kunsido, ne estas funkcianta vojo.