Protocol 47 versus TCP-poort 47: twee headers, twee regels

Hotelnetwerken en conferentiefirewalls tonen vaak een eigen toestemmingsvak, en iemand typt er 47 in in de hoop dat PPTP werkt. De regel wordt aangemaakt, de tunnel faalt nog steeds, en de volgende poging gebruikt een ander nummer. Wat er misging zit in het pakket zelf: IPv4 heeft een protocolveld dat benoemt wat na de IP-header komt, terwijl TCP en UDP poortvelden hebben die pas bestaan als je je binnen een van die headers bevindt. Het zijn geen twee spellingen van dezelfde toestemming.

De IPv4-header benoemt het volgende protocol

Het protocolveld is één byte in de IPv4-header, en het bevat een nummer dat de payload beschrijft: 6 voor TCP, 17 voor UDP, 47 voor GRE, 50 voor ESP. Alles wat pakketten filtert leest die waarde voordat het dieper kijkt, want de diepere header heeft pas betekenis als het type bekend is. Wijzig later in het gesprek een poort, en dit veld is niet bewogen.

Een regel die tegen protocol 47 is geschreven beschrijft dus de IP-laag. Geen enkele poort neemt deel aan de beslissing.

Poorten bestaan binnen TCP en UDP, nergens anders

Poorten zijn zestien bits lange identificaties binnen TCP- en UDP-headers, en hun taak is gesprekken te scheiden die één adres delen. Een GRE-header draagt een protocoltypewaarde, vaak een EtherType, plus optionele sleutels voor multiplexing. De uitdrukking poort 47 benoemt daarom niets waar een GRE-pakket op kan passen.

Firewallinterfaces verschillen in hoeveel hiervan ze tonen. Sommige accepteren een protocolnummer, sommige bieden een benoemde lijst, en een paar accepteren alleen TCP of UDP met poorten.

PPTP gebruikt beide lagen tegelijk

PPTP is het duidelijkste voorbeeld omdat het zijn werk bewust over de twee verdeelt. De besturingsverbinding is een TCP-sessie naar poort 1723, en het datapad is GRE, protocol 47, zonder dat ergens een poort betrokken is. Een firewall die 1723 toestaat en niets anders laat de onderhandeling beginnen en gooit daarna de payload weg. De tunnel lijkt na de authenticatie te hangen in plaats van geen verbinding te maken, en daarom wordt het symptoom vaak als wachtwoordprobleem gemeld.

Lees de twee rijen apart wanneer u de regel schrijft, en controleer elk tegen de syntaxis van de leverancier. De ene rij heeft een poort nodig, de andere een protocolnummer, en geen enkele vermelding dekt beide.

Waarom een port-forwardpagina GRE niet kan uitdrukken

Een doorstuurformulier dat alleen TCP en UDP accepteert kan GRE niet beschrijven, hoe het formulier ook heet. Adresvertaling voegt een tweede moeilijkheid toe, omdat GRE geen poorten heeft en de vertaler in plaats daarvan de oproepidentificatie moet volgen. Sommige consumentenrouters leveren een helper die dat afhandelt; veel niet, en geen extra TCP-toestemmingsvermelding zal dat gedrag creëren.

Waar een moderne tunnel de echte eis is, kies een ontwerp dat bewust TCP of UDP gebruikt in plaats van te hopen dat een vertaler goed raadt.

Inkapseling bepaalt wat het filter ziet

Inkapseling verandert het buitenste pakket, en het buitenste pakket is waar een regel op past. Native ESP is protocol 50, terwijl NAT-traversal ESP in UDP 4500 verpakt zodat het adresvertaling overleeft. Een filter dat UDP 4500 toestaat ziet nooit protocol 50, en een filter dat voor protocol 50 is geschreven past nooit op de verpakte vorm.

Vraag op welke inkapseling de client en de gateway het eens zijn geworden, en schrijf de regel dan voor precies die buitenste vorm en niets meer.

Schrijf de regel zodat iemand hem kan controleren

Druk elke regel uit als adresfamilie, buitenste protocol, transportpoorten indien aanwezig, richting en beide eindpunten. Een beoordelaar kan die zin vergelijken met een pakketopname en tot een oordeel komen. Een instructie om 47 te openen kan niemand controleren, en zo overleeft die jarenlang in runbooks.

Voeg de test toe die dat bewijst: maak verbinding terwijl u op de buitenste interface opneemt, en bevestig het buitenste protocol en de poort die werkelijk in het spoor verschijnen.