strongSwan ESP-in-UDP: als er geen NAT te detecteren valt

NAT-detectie vindt adresvertaling, geen firewallbeleid. Een siteverbinding zonder NAT kan toch een expliciete ESP-in-UDP-keuze nodig hebben.

NAT-detectie beantwoordt één vraag: zijn de adressen of poorten onderweg veranderd? Ze beantwoordt niet of een firewall IP-protocol 50 toestaat. Sitegateways zonder enige vertaling kunnen nog steeds achter een beleid zitten dat native ESP laat vallen, en die eis moet worden geconfigureerd in plaats van ontdekt. Het mechanisme is ESP-in-UDP, en dat is een beslissing, geen terugvaloptie die vanzelf verschijnt.

Detectie is rekenwerk op adressen, geen firewallcontrole

IKEv2 draagt NAT-detectiepayloads met hashes van de bron- en bestemmingsadressen en -poorten. Elke kant vergelijkt wat hij ontving met wat hij lokaal ziet, en een verschil vertelt hem dat iets het pakket heeft vertaald. Niets in die uitwisseling test of een router in het midden protocol 50 doorstuurt.

Het praktische gevolg is de moeite waard om ronduit te zeggen. Een tunnel die met native ESP werkte, ontdekt niet vanzelf een nieuw beperkend firewall, en de volgende poging mislukt in de datafase terwijl IKE blijft slagen. Je ziet gevestigde IKE-beveiligingsassociaties en geen beschermd verkeer, wat op een routeringsfout lijkt tot je op de kabel afvangt.

Inkapseling is dus een eigenschap van de verbinding die je configureert, geen uitkomst die de peers uit het netwerkgedrag onderhandelen.

Hoe encap de uitwisseling verandert

In een moderne strongSwan-implementatie die via swanctl.conf wordt beheerd, beïnvloedt de instelling encap = yes op de verbinding de NAT-detectie-uitwisseling zodat beide peers UDP-inkapseling voor ESP gebruiken. De beschermde pakketten reizen dan binnen UDP, gewoonlijk op poort 4500, en beide uiteinden moeten het over die regeling eens zijn.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Dat fragment hoort binnen een echte verbindingsdefinitie en is geen volledig siteprofiel. Behoud de peeradressen, de authenticatie en de child-verkeersselectors die je al draait; de enige toegevoegde sleutel verandert hoe de beschermde gegevens worden ingepakt, niet wat ze beschermen.

De strongSwan-gids over NAT-traversal beschrijft dit gedrag, inclusief de interactie met poort floating wanneer MOBIKE wordt gebruikt.

Gebruik de instelling die bij je backend hoort

strongSwan heeft twee configuratiebackends, en de sleutel verschilt ertussen. Een swanctl.conf verbinding neemt encap, terwijl een oudere ipsec.conf verbinding forceencaps neemt. Het sleutelwoord van de ene backend in de andere zetten levert een configuratie op die zonder klagen laadt en niets verandert, wat erger is dan een fout.

Controleer welke daemon werkelijk draait voordat je iets bewerkt. Op veel distributies bestaan beide bestanden omdat een ervan een overblijfsel van een eerdere migratie is, en de actieve is degene die de service-eenheid start. Lees die eenheid in plaats van te gissen uit bestandstijdstempels. Een controle van vijf seconden hier voorkomt uren testen van een instelling die niets heeft geladen.

Pas de wijziging toe via de eigenaar van de verbinding en herstel de associatie tijdens een gecontroleerd venster. Een al geïnstalleerde child behoudt zijn huidige inkapseling tot hij wordt vervangen, dus een bestandswijziging alleen bewijst niet dat de nieuwe regeling in gebruik is.

Verifieer de ingepakte gegevens, niet alleen de poort

Vang af op de gateway terwijl beschermd verkeer stroomt, en vergelijk dat daarna met strongSwans eigen beeld:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP verschijnt als IP-protocol 50 en lijkt helemaal niet op UDP. Ingepakt ESP verschijnt als UDP-datagrammen op 4500 waarvan de payload geen IKE is. IKE-verkeer op dezelfde poort is geen bewijs van inkapseling, want MOBIKE kan IKE daarheen verplaatsen terwijl het datapad native blijft, dus lees de payload, niet het poortnummer.

Houd ook de MTU van het pad in gedachten. De inkapseling voegt overhead toe, en een pad dat native ESP droeg kan aanpassingen nodig hebben wanneer de pakketten groeien. Noodzakelijke ICMP-afhandeling zou al deel van het ontwerp moeten zijn; inkapseling neemt die afhankelijkheid niet weg.

Accepteer de wijziging wanneer vers applicatieverkeer in de tunnel in de opname aan beide uiteinden als ingepakt ESP zichtbaar is, en wanneer de interne dienst en zijn retourroute nog werken. Alles minder is een configuratie die er in een bestand juist uitziet.

Gerelateerde artikelen