Å nå ein IKEv2-klient på den tildelte virtuelle IP-en

Ein gateway må starte ei tilkobling til ein berbar datamaskin som er knytt til han via IKEv2, ved å bruke den virtuelle adressa som er tildelt klienten. Tunnelen er oppe, klienten når alt bak gatewayen, og den motsette retninga feilar framleis. Denne asymmetrien er normal: den forhandla policyen skildrar kva adresser som kan snakke, ikkje kva side som kan starte. Tre ting må stemme før ein førespurnad som gatewayen startar, verkar.

Tunnelen rettar ikkje kjeldadressa

Ein CHILD SA dekkjer eit par trafikkveljarar, éin per side, og tillèt trafikk i begge retningane av paret. Han seier ingenting om kva peer som opna IKE-utvekslinga først. Ein gateway som opphavleg lytta etter tunnelen, kan framleis sende den første applikasjonspakken, føresett at den valde kjelda og destinasjonen ligg innanfor dei installerte veljarane. Når førespurnaden forlèt feil grensesnitt, er han rett og slett ikkje kvalifisert for tunnelen.

Ruting mot klienten er nødvendig og ikkje tilstrekkeleg. Policyen må tillate kjelda du faktisk brukte.

Les den installerte policyen, ikkje konfigurasjonsfila

Start med den aktive assosiasjonen og veljarane hans, fordi dynamisk tildeling endrar det som er installert i kjernen.

ipsec statusall
ip xfrm policy

Statusutskrifta namngjev tilkoblinga, den tildelte virtuelle adressa og veljarane som gjeld for den peeren no. Policydumpen viser dei same veljarane som kjernetilstand, og det er den pakkevalet faktisk konsulterer. Samanlikn veljaren på gateway-sida med kjelda applikasjonen din skal bruke, fordi eit avvik forklarer feilen med ein gong. Les den gjeldande adressa til klienten i staden for ei frå ei tidlegare økt, fordi ein tildelt VIP på nytt gjer den gamle policyen ugyldig.

Klienten må lytte der pakken kjem inn

Jamvel ein perfekt policy når ein lukka port når tenesta berre bind til loopback. Lyttaren må vere på den tildelte adressa eller på ei lokal jokeradresse.

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

Socket-oversikta viser om porten er bunden til den virtuelle adressa, og brannmurreglane viser om nye tilkoblingar blir godtekne frå den verna kjelda. Ei regel skriven for etablerte tilkoblingar slepp ikkje inn ei tilkobling som gatewayen startar. Hald på tenesta si eiga autentisering, fordi ankomst gjennom tunnelen berre fastslår kva nettverk pakken kom frå. Ein klient bak sin eigen NAT treng framleis inga videresending av inngåande port, fordi desse førespurnadene reiser inne i den eksisterande tunnelen.

Test den nye retninga for seg sjølv

Ein fungerande førespurnad frå klient til tenar prøver aldri denne vegen. Generer førespurnaden frå gatewayen og observer begge endar.

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

Ruteoppslaget svarar på kva kjelde og kva grensesnitt gatewayen ville bruke, og det er verdien policyen må tillate. Opptaket bør vise førespurnaden forlèt inne i ESP i staden for som vanleg TCP på det offentlege grensesnittet. På klienten, ta opp den dekrypterte trafikken for å stadfeste ankomsten og om tenesta svara. Viss førespurnaden forsvinn utan ESP på linja, mistenk kjeldadressa før brannmuren til klienten.

Gjenta testen etter eit nøkkelbyte eller ei gjenoppkopling, fordi VIP-en kan endre seg. Ein veg som berre verkar til neste økt, er ikkje ein fungerande veg.