Sasniegt IKEv2 klientu tā piešķirtajā virtuālajā IP

Vārtejai ir jāuzsāk savienojums ar klēpjdatoru, kas ar to savienots pa IKEv2, izmantojot šim klientam piešķirto virtuālo adresi. Tunelis ir uzcelts, klients sasniedz visu aiz vārtejas, un pretējais virziens joprojām neizdodas. Šī asimetrija ir normāla: sarunātā politika apraksta, kuras adreses drīkst runāt, nevis kura puse drīkst uzsākt. Trīs lietām jāsakrīt, pirms vārtejas uzsāktais pieprasījums sāk darboties.

Tunelis neizlabo avota adresi

CHILD SA aptver trafika selektoru pāri, pa vienam katrai pusei, un atļauj trafiku abos šī pāra virzienos. Tā neko nepasaka par to, kura puse pirmā atvēra IKE apmaiņu. Vārteja, kas sākotnēji klausījās tuneli, joprojām var nosūtīt pirmo lietojumprogrammas paketi, ja izvēlētais avots un galamērķis iekrīt instalētajos selektoros. Kad pieprasījums iznāk no nepareizā interfeisa, tas vienkārši nav piemērots tunelim.

Maršrutēšana uz klientu ir nepieciešama un nav pietiekama. Politikai jāatļauj avots, kuru jūs faktiski izmantojāt.

Lasiet instalēto politiku, nevis konfigurācijas failu

Sāciet ar aktīvo asociāciju un tās selektoriem, jo dinamiskā piešķiršana maina to, kas instalēts kodolā.

ipsec statusall
ip xfrm policy

Statusa izvade nosauc savienojumu, piešķirto virtuālo adresi un selektorus, kas šobrīd ir spēkā šim partnerim. Politikas izdruka parāda tos pašus selektorus kā kodola stāvokli, un tieši to faktiski konsultē pakešu atlase. Salīdziniet vārtejas puses selektoru ar avotu, ko izmantos jūsu lietojumprogramma, jo neatbilstība uzreiz izskaidro kļūmi. Lasiet klienta pašreizējo adresi, nevis kādu no iepriekšējās sesijas, jo no jauna piešķirts VIP padara veco politiku nederīgu.

Klientam jāklausās tur, kur pakete ierodas

Pat ideāla politika sasniedz slēgtu portu, kad pakalpojums ir piesaistīts tikai loopback. Klausītājam jābūt piešķirtajā adresē vai lokālā aizstājējadresē.

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

Ligzdu saraksts parāda, vai ports ir piesaistīts virtuālajai adresei, un ugunsmūra noteikumi parāda, vai tiek pieņemti jauni savienojumi no aizsargātā avota. Noteikums, kas rakstīts jau izveidotiem savienojumiem, neielaiž savienojumu, ko uzsāk vārteja. Saglabājiet paša pakalpojuma autentifikāciju, jo ierašanās pa tuneli tikai nosaka, no kura tīkla pakete nāca. Klientam aiz sava NAT joprojām nav vajadzīga ienākošā porta pāradresācija, jo šie pieprasījumi ceļo esošā tuneļa iekšienē.

Pārbaudiet jauno virzienu atsevišķi

Veišķīgs pieprasījums no klienta uz serveri nekad neizmanto šo ceļu. Ģenerējiet pieprasījumu no vārtejas un novērojiet abus galus.

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

Maršruta meklēšana atbild, kuru avotu un interfeisu vārteja izmantotu, un tas ir vērtība, kas politikai jāatļauj. Ierakstā jābūt redzamam, ka pieprasījums iznāk ESP iekšienē, nevis kā vienkāršs TCP publiskajā interfeisā. Klientā ierakstiet atšifrēto trafiku, lai apstiprinātu ierašanos un vai pakalpojums atbildēja. Ja pieprasījums pazūd bez ESP līnijā, aizdomās turamais ir avota adrese pirms klienta ugunsmūra.

Atkārtojiet testu pēc atslēgu maiņas vai atkārtotas pieslēgšanās, jo VIP var mainīties. Ceļš, kas darbojas tikai līdz nākamajai sesijai, nav strādājošs ceļš.