Protokol 47 kontra TCP-port 47: to headere, to regler

Hotelnettværk og konferencefirewalls viser ofte en tilpasset tilladelsesboks, og nogen skriver 47 i den og forventer, at PPTP virker. Reglen bliver oprettet, tunnelen fejler stadig, og det næste forsøg bruger et andet nummer. Det, der gik galt, sidder i pakken selv: IPv4 har et protokolfelt, der navngiver, hvad der følger efter IP-headeren, mens TCP og UDP har portfelter, som kun findes, når du er inde i en af disse headere. De er ikke to stavemåder af den samme tilladelse.

IPv4-headeren navngiver den næste protokol

Protokolfeltet er én byte i IPv4-headeren, og det indeholder et tal, der beskriver nyttelasten: 6 for TCP, 17 for UDP, 47 for GRE, 50 for ESP. Alt, der filtrerer pakker, læser den værdi, før det kigger dybere, fordi den dybere header først giver mening, når typen er kendt. Skift en port senere i samtalen, og dette felt har ikke rørt sig.

En regel skrevet mod protokol 47 beskriver derfor IP-laget. Ingen port deltager overhovedet i beslutningen.

Porte findes inde i TCP og UDP, ingen andre steder

Porte er seksten bit lange identifikatorer inde i TCP- og UDP-headere, og deres opgave er at adskille samtaler, der deler én adresse. En GRE-header bærer en protokoltypeværdi, ofte en EtherType, plus valgfrie nøgler til multipleksing. Udtrykket port 47 navngiver derfor intet, som en GRE-pakke kan matche.

Firewall-grænseflader er forskellige i, hvor meget af dette de viser. Nogle accepterer et protokolnnummer, nogle tilbyder en navngivet liste, og få accepterer kun TCP eller UDP med porte.

PPTP bruger begge lag på én gang

PPTP er det klareste eksempel, fordi det bevidst deler sit arbejde mellem de to. Kontrolforbindelsen er en TCP-session til port 1723, og datastien er GRE, protokol 47, uden nogen port involveret. En firewall, der tillader 1723 og intet andet, lader forhandlingen starte og kasserer derefter nyttelasten. Tunnelen ser ud til at hænge efter godkendelse i stedet for at undlade at forbinde, og derfor rapporteres symptomet ofte som et adgangskodeproblem.

Læs de to rækker hver for sig, når du skriver reglen, og kontroller hver af dem mod leverandørens syntaks. Den ene række kræver en port, den anden kræver et protokolnnummer, og ingen enkelt post dækker begge.

Hvorfor en portvideresendelsesside ikke kan udtrykke GRE

En videresendelsesformular, der kun accepterer TCP og UDP, kan ikke beskrive GRE, uanset hvad formularen hedder. Adresseoversættelse tilføjer en anden vanskelighed, fordi GRE ikke har porte, og oversætteren må i stedet følge opkaldets identifikator. Nogle forbrugerroutere leveres med en hjælper, der klarer det; mange gør ikke, og ingen ekstra TCP-tilladelsespost vil skabe den adfærd.

Hvor en moderne tunnel er det faktiske krav, vælg et design, der bevidst bruger TCP eller UDP, i stedet for at håbe på, at en oversætter gætter rigtigt.

Indkapsling afgør, hvad filteret ser

Indkapsling ændrer den ydre pakke, og den ydre pakke er det, en regel matcher. Indbygget ESP er protokol 50, mens NAT-traversal pakker ESP ind i UDP 4500, så det kan overleve adresseoversættelse. Et filter, der tillader UDP 4500, ser aldrig protokol 50, og et filter skrevet til protokol 50 matcher aldrig den indpakkede form.

Spørg, hvilken indkapsling klienten og gatewayen blev enige om, og skriv så reglen for netop den ydre form og intet mere.

Skriv reglen, så nogen kan kontrollere den

Udtryk hver regel som adressefamilie, ydre protokol, transportporte hvis nogen, retning og begge endepunkter. En anmelder kan sammenligne den sætning med en pakkefangst og nå en dom. En instruks om at åbne 47 kan ingen kontrollere, og det er derfor, den overlever i runbooks i årevis.

Tilføj testen, der beviser det: forbind, mens du fanger på det ydre interface, og bekræft den ydre protokol og port, der faktisk optræder i sporet.