Å nå en IKEv2-klient på dens tildelte virtuelle IP

En gateway må starte en forbindelse til en bærbar datamaskin som er koblet til den via IKEv2, ved å bruke den virtuelle adressen som er tildelt klienten. Tunnelen er oppe, klienten når alt bak gatewayen, og den motsatte retningen feiler fortsatt. Denne asymmetrien er normal: den forhandlede policyen beskriver hvilke adresser som kan snakke, ikke hvilken side som kan starte. Tre ting må stemme før en forespørsel som gatewayen starter, virker.

Tunnelen retter ikke kildeadressen

En CHILD SA dekker et par trafikkvelgere, én per side, og tillater trafikk i begge retninger av paret. Den sier ingenting om hvilken peer som åpnet IKE-utvekslingen først. En gateway som opprinnelig lyttet etter tunnelen, kan fortsatt sende den første applikasjonspakken, forutsatt at den valgte kilden og destinasjonen ligger innenfor de installerte velgerne. Når forespørselen forlater feil grensesnitt, er den rett og slett ikke kvalifisert for tunnelen.

Ruting mot klienten er nødvendig og ikke tilstrekkelig. Policyen må tillate kilden du faktisk brukte.

Les den installerte policyen, ikke konfigurasjonsfilen

Start med den aktive assosiasjonen og velgerne dens, fordi dynamisk tildeling endrer det som er installert i kjernen.

ipsec statusall
ip xfrm policy

Statusutskriften navngir forbindelsen, den tildelte virtuelle adressen og velgerne som gjelder for den peeren nå. Policydumpen viser de samme velgerne som kjernetilstand, og det er den pakkevalget faktisk konsulterer. Sammenlign velgeren på gateway-siden med kilden applikasjonen din skal bruke, fordi et avvik forklarer feilen umiddelbart. Les klientens gjeldende adresse i stedet for en fra en tidligere økt, fordi en tildelt VIP på nytt gjør den gamle policyen ugyldig.

Klienten må lytte der pakken ankommer

Selv en perfekt policy når en lukket port når tjenesten bare binder til loopback. Lytteren må være på den tildelte adressen eller på en lokal jokeradresse.

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

Socket-oversikten viser om porten er bundet til den virtuelle adressen, og brannmurreglene viser om nye forbindelser godtas fra den beskyttede kilden. En regel skrevet for etablerte forbindelser slipper ikke inn en forbindelse som gatewayen starter. Behold tjenestens egen autentisering, fordi ankomst gjennom tunnelen bare fastslår hvilket nettverk pakken kom fra. En klient bak sin egen NAT trenger fortsatt ingen videresending av innkommende port, fordi disse forespørslene reiser inne i den eksisterende tunnelen.

Test den nye retningen for seg selv

En fungerende forespørsel fra klient til server prøver aldri denne veien. Generer forespørselen fra gatewayen og observer begge ender.

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 svarer på hvilken kilde og hvilket grensesnitt gatewayen ville bruke, og det er verdien policyen må tillate. Opptaket bør vise forespørselen forlate inne i ESP i stedet for som vanlig TCP på det offentlige grensesnittet. På klienten, ta opp den dekrypterte trafikken for å bekrefte ankomsten og om tjenesten svarte. Hvis forespørselen forsvinner uten ESP på linjen, mistenk kildeadressen før klientens brannmur.

Gjenta testen etter et nøkkelbytte eller en gjenoppkobling, fordi VIP-en kan endres. En vei som bare virker til neste økt, er ikke en fungerende vei.