Att nå en IKEv2-klient på dess tilldelade virtuella IP

En gateway måste starta en anslutning till en bärbar dator som är ansluten till den via IKEv2, och använda den virtuella adress som tilldelats klienten. Tunneln är uppe, klienten når allt bakom gatewayen, och den motsatta riktningen misslyckas fortfarande. Den asymmetrin är normal: den förhandlade policyn beskriver vilka adresser som får tala, inte vilken sida som får initiera. Tre saker måste stämma innan en begäran som gatewayen startar fungerar.

Tunneln rättar inte källadressen

En CHILD SA omfattar ett par trafikväljare, en per sida, och tillåter trafik i båda riktningarna av paret. Den säger ingenting om vilken peer som öppnade IKE-utbytet först. En gateway som ursprungligen lyssnade efter tunneln kan fortfarande skicka det första applikationspaketet, förutsatt att den valda källan och destinationen ligger inom de installerade väljarna. När begäran lämnar fel gränssnitt är den helt enkelt inte kvalificerad för tunneln.

Routning mot klienten är nödvändig och inte tillräcklig. Policyn måste tillåta den källa du faktiskt använde.

Läs den installerade policyn, inte konfigurationsfilen

Börja med den aktiva associationen och dess väljare, eftersom dynamisk tilldelning ändrar vad som är installerat i kärnan.

ipsec statusall
ip xfrm policy

Statusutskriften namnger anslutningen, den tilldelade virtuella adressen och de väljare som gäller för den peeren just nu. Policydumpen visar samma väljare som kärntillstånd, och det är den paketvalet faktiskt konsulterar. Jämför väljaren på gateway-sidan med den källa som din applikation ska använda, eftersom en avvikelse förklarar felet direkt. Läs klientens aktuella adress i stället för en från en tidigare session, eftersom en nytilldelad VIP gör den gamla policyn ogiltig.

Klienten måste lyssna där paketet anländer

Även en perfekt policy når en stängd port när tjänsten bara binder till loopback. Lyssnaren måste vara på den tilldelade adressen eller på en lokal jokeradress.

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

Socketlistan visar om porten är bunden till den virtuella adressen, och brandväggsreglerna visar om nya anslutningar accepteras från den skyddade källan. En regel skriven för etablerade anslutningar släpper inte in en anslutning som gatewayen startar. Behåll tjänstens egen autentisering, eftersom ankomst genom tunneln bara fastställer vilket nätverk paketet kom från. En klient bakom sin egen NAT behöver fortfarande ingen vidarebefordran av inkommande port, eftersom dessa begäranden färdas inne i den befintliga tunneln.

Testa den nya riktningen separat

En fungerande begäran från klient till server prövar aldrig denna väg. Generera begäran från gatewayen och observera båda ändarna.

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

Routsökningen svarar på vilken källa och vilket gränssnitt gatewayen skulle använda, och det är det värde som policyn måste tillåta. Insamlingen bör visa begäran lämna inne i ESP i stället för som vanlig TCP på det publika gränssnittet. På klienten, fånga den dekrypterade trafiken för att bekräfta ankomsten och om tjänsten svarade. Om begäran försvinner utan ESP på länken, misstänk källadressen före klientens brandvägg.

Upprepa testet efter ett nyckelbyte eller en återanslutning, eftersom VIP:n kan ändras. En väg som bara fungerar till nästa session är ingen fungerande väg.