ESP is IP-protocol 50, niet TCP-poort 50: wat u moet toestaan
Protocolnummers en poortnummers zijn verschillende naamruimten. Een regel voor TCP-poort 50 staat niets toe, en NAT-traversal verplaatst ESP naar UDP 4500.
Firewallformulieren vragen om een TCP-poort, en de voor de hand liggende invoer is 50. Die invoer staat niets toe, want ESP is IP-protocol nummer 50 en protocolnummers zijn geen poorten. De twee naamruimten delen kleine gehele getallen en niets anders, en de fout blijft onzichtbaar tot IKE klaar is en het beveiligde verkeer nooit aankomt.
Twee naamruimten die kleine getallen delen
Een IP-header draagt een protocolveld dat benoemt wat er volgt: 6 voor TCP, 17 voor UDP, 1 voor ICMP, 50 voor ESP, 51 voor AH. Een TCP- of UDP-header draagt poortnummers, die een proces op de doelserver kiezen. Protocol 50 en TCP-poort 50 zijn ongerelateerde waarden, maar een dialoogvenster kan ze verwisselbaar laten lijken.
Daarom kan een poortdoorschakelregel native ESP niet uitdrukken. Er is geen ESP-doelpoort om door te schakelen, en een apparaat dat alleen poortregels begrijpt, heeft helemaal geen vocabulaire voor dat pakket. De juiste regel benoemt in plaats daarvan het IP-protocol. Elk poortdialoogvenster is het verkeerde instrument voor dat pakket.
De verwarring heeft een tweede helft. Wanneer het pakket versleuteld is, is alles erin ondoorzichtig, inclusief de TCP-header van de oorspronkelijke verbinding. Een firewall die poorten in dat pakket inspecteert, kijkt naar de buitenste header, die in het native geval geen poorten heeft om te inspecteren.
Native ESP, dan het ingekapselde alternatief
Native ESP wordt rechtstreeks als IP-protocol gedragen, wat even efficiënt als onhandig is. Efficiënt omdat er geen extra header is, en onhandig omdat geen enkel apparaat dat adressen en poorten vertaalt het kan volgen. NAT-traversal bestaat om dat op te lossen, door het ESP-pakket in UDP te wikkelen zodat de vertaler poorten heeft om te herschrijven.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
De twee vormen zijn alternatieve implementaties van hetzelfde datakanaal, geen lagen van één. Native ESP toestaan staat de ingekapselde vorm niet toe, en UDP 4500 toestaan staat geen native verkeer toe, dus een regelset moet bij de implementatie passen in plaats van beide per ongeluk te dekken.
Detectie is hier ook belangrijk. De eindpunten kiezen tijdens de onderhandeling tussen de vormen, en de omschakeling gebeurt meestal wanneer er een NAT tussen hen wordt gedetecteerd. Een pad dat verandert nadat de tunnel is opgezet, kan het verkeer dus verplaatsen naar een naamruimte die uw regels nooit dekten.
Lees welke vorm de verbinding werkelijk gebruikt
Vraag het eindpunt in plaats van te gokken op basis van de firewall. Op Linux meldt de statusregel of de associatie UDP-inkapseling gebruikt en welke poorten betrokken zijn. Een pakketopname beantwoordt dezelfde vraag vanaf de draad, en beide zijn sneller dan een regelset lezen en hopen.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'
De eerste opdracht toont een inkapselingstype wanneer NAT-traversal in gebruik is en niets wanneer niet. De tweede toont welke van de twee vormen werkelijk de interface passeert, en dat beslecht discussies over een configuratie die op papier correct lijkt.
Tegenbewijs hoort in dezelfde stap. Een regel die nul treffers meldt, vertelt u dat het pakket hem nooit heeft bereikt, en dat is een routerings- of selectievraag, geen firewallvraag.
Bevestig daarna het controleverkeer apart. IKE heeft zijn eigen poorten en zijn eigen logbestanden, en een afgeronde onderhandeling zonder data is precies de splitsing waar dit artikel over gaat.
Schrijf de regel in de juiste naamruimte
Een protocolregel en een poortregel zijn verschillende instructies, dus het gereedschap moet uitdrukken welke u bedoelt. In nftables is de protocolovereenkomst expliciet, en het ingekapselde alternatief krijgt zijn eigen UDP-regel. Houd de twee regels naast elkaar zodat het paar zichtbaar is bij de beoordeling.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept
Weersta de verleiding om een van beide regels te verbreden om een verkeerde diagnose te compenseren. Alles toestaan voor het ESP-protocol op elke interface, of UDP-toestemming van waar dan ook naar waar dan ook, verhelpt een symptoom en verwijdert de controle die u probeerde in te stellen. De smalle ondersteunde stroom is bijna altijd voldoende zodra de vorm bekend is.
Ten slotte, houd de lagen recht als de tunnel werkt en de toepassing niet. Pakketten die bij de gateway aankomen hebben nog steeds doorsturing, een retourroute en een beleid nodig dat ze toelaat, en niets daarvan wordt door een ESP-regel uitgedrukt. De ontbrekende poort verklaart een specifieke storing, niet elke IPsec-storing. Houd de regelfix en de routeringscontrole als twee aparte conclusies.
Noteer de vorm die u hebt waargenomen, de protocolregel die u hebt toegevoegd en de teller die u daarna zag. Drie regels, en de volgende persoon kan een naamruimtefout in een minuut van een routeringsfout onderscheiden in plaats van in een middag.