Een IKEv2-client bereiken op zijn toegewezen virtuele IP

Een gateway moet een verbinding starten naar een laptop die via IKEv2 met hem is verbonden, met het virtuele adres dat aan die client is toegewezen. De tunnel staat, de client bereikt alles achter de gateway, en de omgekeerde richting mislukt nog steeds. Die asymmetrie is normaal: het onderhandelde beleid beschrijft welke adressen mogen praten, niet welke kant mag beginnen. Drie dingen moeten kloppen voordat een verzoek dat de gateway start werkt.

De tunnel lost het bronadres niet op

Een CHILD SA omvat een paar verkeersselectors, één per kant, en staat verkeer in beide richtingen van dat paar toe. Hij zegt niets over welke peer de IKE-uitwisseling als eerste opende. Een gateway die oorspronkelijk op de tunnel luisterde, kan nog steeds het eerste applicatiepakket sturen, mits de gekozen bron en bestemming binnen de geïnstalleerde selectors vallen. Wanneer het verzoek via de verkeerde interface vertrekt, is het simpelweg niet geschikt voor de tunnel.

Routering naar de client is noodzakelijk en niet voldoende. Het beleid moet de bron toelaten die je werkelijk hebt gebruikt.

Lees het geïnstalleerde beleid, niet het configuratiebestand

Begin bij de actieve associatie en zijn selectors, omdat dynamische toewijzing verandert wat er in de kernel is geïnstalleerd.

ipsec statusall
ip xfrm policy

De statusuitvoer noemt de verbinding, het toegewezen virtuele adres en de selectors die op dit moment voor die peer gelden. De beleidsdump toont dezelfde selectors als kernelstatus, en dat is wat pakketselectie werkelijk raadpleegt. Vergelijk de selector aan de gatewaykant met de bron die je applicatie gaat gebruiken, want een verschil verklaart de fout onmiddellijk. Lees het huidige adres van de client in plaats van een adres uit een eerdere sessie, want een opnieuw toegewezen VIP maakt het oude beleid ongeldig.

De client moet luisteren waar het pakket aankomt

Zelfs een perfect beleid bereikt een gesloten poort wanneer de dienst alleen aan loopback bindt. De listener moet op het toegewezen adres of op een lokaal jokeradres staan.

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

De socketlijst laat zien of de poort aan het virtuele adres is gebonden, en de firewallregels laten zien of nieuwe verbindingen vanaf de beschermde bron worden geaccepteerd. Een regel die voor bestaande verbindingen is geschreven, laat een verbinding die de gateway start niet toe. Behoud de eigen authenticatie van de dienst, want aankomst via de tunnel stelt alleen vast uit welk netwerk het pakket kwam. Een client achter zijn eigen NAT heeft nog steeds geen inkomende port forwarding nodig, want deze verzoeken reizen binnen de bestaande tunnel.

Test de nieuwe richting apart

Een werkend verzoek van client naar server oefent dit pad nooit. Genereer het verzoek vanaf de gateway en observeer beide uiteinden.

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

De route-opzoeking beantwoordt welke bron en interface de gateway zou gebruiken, en dat is de waarde die het beleid moet toelaten. De opname zou moeten laten zien dat het verzoek binnen ESP vertrekt en niet als gewone TCP op de publieke interface. Op de client, leg het ontsleutelde verkeer vast om de aankomst en of de dienst antwoordde te bevestigen. Als het verzoek verdwijnt zonder ESP op de lijn, verdenk dan het bronadres vóór de firewall van de client.

Herhaal de test na een sleutelwissel of een herverbinding, want de VIP kan veranderen. Een pad dat alleen tot de volgende sessie werkt, is geen werkend pad.