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

En gateway skal starte en forbindelse til en bærbar computer, der er forbundet til den via IKEv2, ved at bruge den virtuelle adresse, der er tildelt klienten. Tunnelen er oppe, klienten når alt bag gatewayen, og den modsatte retning fejler stadig. Den asymmetri er normal: den forhandlede politik beskriver, hvilke adresser der må tale, ikke hvilken side der må starte. Tre ting skal passe sammen, før en anmodning, som gatewayen starter, virker.

Tunnelen retter ikke kildeadressen

En CHILD SA dækker et par trafikvælgere, én per side, og tillader trafik i begge retninger af det par. Den siger intet om, hvilken peer der åbnede IKE-udvekslingen først. En gateway, der oprindeligt lyttede efter tunnelen, kan stadig sende den første applikationspakke, forudsat at den valgte kilde og destination ligger inden for de installerede vælgere. Når anmodningen forlader den forkerte grænseflade, er den simpelthen ikke kvalificeret til tunnelen.

Routing mod klienten er nødvendig og ikke tilstrækkelig. Politikken skal tillade den kilde, du faktisk brugte.

Læs den installerede politik, ikke konfigurationsfilen

Start ved den aktive association og dens vælgere, fordi dynamisk tildeling ændrer, hvad der er installeret i kernen.

ipsec statusall
ip xfrm policy

Statusoutputtet navngiver forbindelsen, den tildelte virtuelle adresse og de vælgere, der aktuelt gælder for den peer. Politikdumpet viser de samme vælgere som kernetilstand, og det er den, pakkevalget faktisk konsulterer. Sammenlign vælgeren på gateway-siden med den kilde, din applikation vil bruge, fordi en uoverensstemmelse straks forklarer fejlen. Læs klientens aktuelle adresse i stedet for en fra en tidligere session, fordi en gentildelt VIP ugyldiggør den gamle politik.

Klienten skal lytte, hvor pakken ankommer

Selv en perfekt politik når en lukket port, når tjenesten kun binder til loopback. Lytteren skal være på den tildelte adresse eller på en lokal jokeradresse.

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

Socket-oversigten viser, om porten er bundet til den virtuelle adresse, og firewall-reglerne viser, om nye forbindelser accepteres fra den beskyttede kilde. En regel skrevet til etablerede forbindelser tillader ikke en forbindelse, som gatewayen starter. Behold tjenestens egen godkendelse, fordi ankomst gennem tunnelen kun fastslår, hvilket netværk pakken kom fra. En klient bag sin egen NAT har stadig ikke brug for videresendelse af indgående port, fordi disse anmodninger rejser inde i den eksisterende tunnel.

Test den nye retning for sig selv

En fungerende anmodning fra klient til server prøver aldrig denne vej. Generer anmodningen 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

Ruteopslaget svarer på, hvilken kilde og grænseflade gatewayen ville bruge, og det er den værdi, politikken skal tillade. Optagelsen bør vise anmodningen forlade inde i ESP i stedet for som almindelig TCP på den offentlige grænseflade. På klienten, optag den dekrypterede trafik for at bekræfte ankomsten og om tjenesten svarede. Hvis anmodningen forsvinder uden ESP på nettet, skal du mistænke kildeadressen før klientens firewall.

Gentag testen efter en nøgleudveksling eller en genopkobling, fordi VIP’en kan ændre sig. En vej, der kun virker indtil næste session, er ikke en fungerende vej.