Arritja e një klienti IKEv2 në IP-në e tij virtuale të caktuar

Një portë duhet të nisë një lidhje drejt një laptopi të lidhur me të përmes IKEv2, duke përdorur adresën virtuale që i është caktuar atij klienti. Tuneli është aktiv, klienti arrin gjithçka pas portës, dhe drejtimi i kundërt ende dështon. Kjo asimetri është normale: politika e negociuar përshkruan cilat adresa mund të flasin, jo cila anë mund të fillojë. Tri gjëra duhet të përputhen përpara se një kërkesë e nisur nga porta të funksionojë.

Tuneli nuk e rregullon adresën e burimit

Një CHILD SA mbulon një palë përzgjedhës të trafikut, një për çdo anë, dhe lejon trafik në të dy drejtimet e asaj pale. Nuk thotë asgjë për atë se cila palë hapi i pari shkëmbimin IKE. Një portë që fillimisht dëgjonte për tunelin mund të dërgojë ende paketën e parë të aplikacionit, me kusht që burimi dhe destinacioni i zgjedhur të bien brenda përzgjedhësve të instaluar. Kur kërkesa del nga ndërfaqja e gabuar, thjesht nuk është e përshtatshme për tunelin.

Rrugëtimi drejt klientit është i nevojshëm dhe nuk mjafton. Politika duhet të pranojë burimin që përdorët në të vërtetë.

Lexoni politikën e instaluar, jo skedarin e konfigurimit

Filloni nga shoqata aktive dhe përzgjedhësit e saj, sepse caktimi dinamik ndryshon atë që është instaluar në kernel.

ipsec statusall
ip xfrm policy

Dalja e statusit emërton lidhjen, adresën virtuale të caktuar dhe përzgjedhësit që janë aktualisht në fuqi për atë palë. Shkarkimi i politikës tregon të njëjtët përzgjedhës si gjendje e kernelit, dhe është pikërisht ajo që konsulton zgjedhja e paketave. Krahasoni përzgjedhësin në anën e portës me burimin që do të përdorë aplikacioni juaj, sepse mospërputhja e shpjegon menjëherë dështimin. Lexoni adresën aktuale të klientit dhe jo një nga një sesion i mëparshëm, sepse një VIP i ricaktuar e bën politikën e vjetër të pavlefshme.

Klienti duhet të dëgjojë aty ku arrin paketa

Edhe një politikë e përsosur arrin në një portë të mbyllur kur shërbimi lidhet vetëm me loopback. Dëgjuesi duhet të jetë në adresën e caktuar ose në një adresë lokale të përgjithshme.

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

Lista e soketeve tregon nëse porta është e lidhur me adresën virtuale, dhe rregullat e murit të zjarrit tregojnë nëse lidhjet e reja pranohen nga burimi i mbrojtur. Një rregull i shkruar për lidhjet e vendosura nuk pranon një lidhje që nis porta. Mbani vërtetimin e vetë shërbimit, sepse ardhja përmes tunelit përcakton vetëm nga cili rrjet erdhi paketa. Një klient pas NAT-it të vet nuk ka ende nevojë për përcjellje të portës hyrëse, sepse këto kërkesa udhëtojnë brenda tunelit ekzistues.

Testoni drejtimin e ri veçmas

Një kërkesë e suksesshme nga klienti te serveri nuk e ushtron kurrë këtë rrugë. Gjeneroni kërkesën nga porta dhe vëzhgoni të dy skajet.

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

Kërkimi i rrugës përgjigjet se cilën burim dhe ndërfaqe do të përdorte porta, dhe kjo është vlera që politika duhet të pranojë. Kapja duhet të tregojë kërkesën duke dalë brenda ESP dhe jo si TCP i thjeshtë në ndërfaqen publike. Në klient, kapni trafikun e dekriptuar për të konfirmuar ardhjen dhe nëse shërbimi u përgjigj. Nëse kërkesa zhduket pa ESP në linjë, dyshoni adresën e burimit përpara murit të zjarrit të klientit.

Përsëritni testin pas një ndryshimi çelësi ose një rilidhjeje, sepse VIP-i mund të ndryshojë. Një rrugë që funksionon vetëm deri në sesionin e ardhshëm nuk është një rrugë funksionale.