Protokoll 47 mot TCP-port 47: to headere, to regler

Hotellnettverk og konferansebrannmurer viser ofte en tilpasset tillatelsesboks, og noen skriver 47 i den og forventer at PPTP skal virke. Regelen blir opprettet, tunnelen feiler fortsatt, og neste forsøk bruker et annet nummer. Det som gikk galt, sitter i pakken selv: IPv4 har et protokollfelt som navngir hva som følger etter IP-headeren, mens TCP og UDP har portfelter som bare finnes når du er inne i en av disse headerne. De er ikke to stavemåter av den samme tillatelsen.

IPv4-headeren navngir neste protokoll

Protokollfeltet er én byte i IPv4-headeren, og det inneholder et tall som beskriver nyttelasten: 6 for TCP, 17 for UDP, 47 for GRE, 50 for ESP. Alt som filtrerer pakker leser denne verdien før det ser dypere, fordi den dypere headeren først gir mening når typen er kjent. Bytt en port senere i samtalen, og dette feltet har ikke flyttet seg.

En regel skrevet mot protokoll 47 beskriver derfor IP-laget. Ingen port deltar i avgjørelsen i det hele tatt.

Porter finnes inne i TCP og UDP, ingen andre steder

Porter er seksten bit lange identifikatorer inne i TCP- og UDP-headere, og oppgaven deres er å skille samtaler som deler én adresse. En GRE-header bærer en protokolltypeverdi, ofte en EtherType, pluss valgfrie nøkler for multipleksing. Uttrykket port 47 navngir derfor ingenting som en GRE-pakke kan samsvare med.

Brannmur-grensesnitt er forskjellige i hvor mye av dette de viser. Noen godtar et protokollnummer, noen tilbyr en navngitt liste, og noen få godtar bare TCP eller UDP med porter.

PPTP bruker begge lagene samtidig

PPTP er det klareste eksempelet fordi det bevisst deler arbeidet sitt mellom de to. Kontrollforbindelsen er en TCP-økt til port 1723, og datastien er GRE, protokoll 47, uten at noen port er involvert noe sted. En brannmur som tillater 1723 og ingenting annet, lar forhandlingen starte og kaster deretter nyttelasten. Tunnelen ser ut til å henge etter autentisering i stedet for å ikke klare å koble til, og derfor rapporteres symptomet ofte som et passordproblem.

Les de to radene hver for seg når du skriver regelen, og kontroller hver av dem mot leverandørens syntaks. Den ene raden trenger en port, den andre trenger et protokollnummer, og ingen enkelt oppføring dekker begge.

Hvorfor en portvideresendelsesside ikke kan uttrykke GRE

Et videresendingsskjema som bare godtar TCP og UDP, kan ikke beskrive GRE, uansett hva skjemaet heter. Adresseoversettelse legger til en annen vanskelighet, fordi GRE ikke har porter, og oversetteren må følge anropsidentifikatoren i stedet. Noen forbrukerrutere leveres med en hjelper som håndterer det; mange gjør ikke, og ingen ekstra TCP-tillatelsesoppføring vil skape den atferden.

Der en moderne tunnel er det faktiske kravet, velg et design som bevisst bruker TCP eller UDP i stedet for å håpe at en oversetter gjetter riktig.

Innkapsling avgjør hva filteret ser

Innkapsling endrer den ytre pakken, og den ytre pakken er det en regel samsvarer med. Innebygd ESP er protokoll 50, mens NAT-gjennomgang pakker ESP inn i UDP 4500 slik at det overlever adresseoversettelse. Et filter som tillater UDP 4500 ser aldri protokoll 50, og et filter skrevet for protokoll 50 samsvarer aldri med den innpakkede formen.

Spør hvilken innkapsling klienten og gatewayen ble enige om, og skriv deretter regelen for nettopp den ytre formen og ingenting mer.

Skriv regelen slik at noen kan kontrollere den

Uttrykk hver regel som adressefamilie, ytre protokoll, transportporter hvis noen, retning og begge endepunktene. En gjennomgåer kan sammenligne den setningen med en pakkefangst og komme til en dom. En instruks om å åpne 47 kan ingen kontrollere, og det er derfor den overlever i årevis i prosedyrebøker.

Legg til testen som beviser det: koble til mens du fanger på det ytre grensesnittet, og bekreft den ytre protokollen og porten som faktisk vises i sporet.