Protokol 47 teenoor TCP-poort 47: twee kopskrifte, twee firewall-reëls

Hotelnetwerke en konferensiefirewalls bied dikwels ’n pasgemaakte toelaatblokkie, en iemand tik 47 daarin in die hoop dat PPTP sal werk. Die reël word geskep, die tonnel misluk steeds, en die volgende poging gebruik ’n ander nommer. Wat verkeerd gegaan het, sit in die pakket self: IPv4 het ’n protokolveld wat noem wat ná die IP-kopskrif volg, terwyl TCP en UDP poortvelde het wat eers bestaan wanneer jy binne een van daardie kopskrifte is. Dit is nie twee spellings van dieselfde toestemming nie.

Die IPv4-kopskrif noem die volgende protokol

Die protokolveld is een greep in die IPv4-kopskrif, en dit hou ’n nommer wat die loonvrag beskryf: 6 vir TCP, 17 vir UDP, 47 vir GRE, 50 vir ESP. Enigiets wat pakkette filter, lees daardie waarde voordat dit dieper kyk, want die dieper kopskrif maak eers sin sodra die tipe bekend is. Verander later in die gesprek ’n poort, en hierdie veld het nie beweeg nie.

’n Reël wat teen protokol 47 geskryf is, beskryf dus die IP-laag. Geen poort neem hoegenaamd aan die besluit deel nie.

Poorte bestaan binne TCP en UDP, nêrens anders nie

Poorte is sestienbis-identifiseerders binne TCP- en UDP-kopskrifte, en hul taak is om gesprekke te skei wat een adres deel. ’n GRE-kopskrif dra ’n protokoltipewaarde, dikwels ’n EtherType, plus opsionele sleutels vir multipleksing. Die frase poort 47 noem dus niks wat ’n GRE-pakket kan pas nie.

Firewall-koppelvlakke verskil in hoeveel hiervan hulle blootlê. Sommige aanvaar ’n protokolnommer, sommige bied ’n lys name, en ’n paar aanvaar net TCP of UDP met poorte.

PPTP gebruik albei lae tegelyk

PPTP is die duidelikste voorbeeld omdat dit sy werk doelbewus oor die twee verdeel. Die beheerverbinding is ’n TCP-sessie na poort 1723, en die datapad is GRE, protokol 47, met geen poort hoegenaamd betrokke nie. ’n Firewall wat 1723 toelaat en niks anders nie, laat die onderhandeling begin en gooi dan die loonvrag weg. Die tonnel lyk of dit ná verifikasie hang eerder as om te misluk om te verbind, en daarom word die simptoom dikwels as ’n wagwoordprobleem gerapporteer.

Lees die twee rye afsonderlik wanneer jy die reël skryf, en kontroleer elkeen teen die verskaffer se sintaksis. Een ry het ’n poort nodig, die ander het ’n protokolnommer nodig, en geen enkele inskrywing dek albei nie.

Waarom ’n poortaanstuur-bladsy GRE nie kan uitdruk nie

’n Aanstuurvorm wat net TCP en UDP aanvaar, kan GRE nie beskryf nie, hoe die vorm ook al genoem word. Adresvertaling voeg ’n tweede moeilikheid by, want GRE het geen poorte nie en die vertaler moet eerder die oproepidentifiseerder volg. Sommige huishoudelike routers het ’n helper wat dit hanteer; baie het nie, en geen bykomende TCP-toelaatinskrywing sal daardie gedrag skep nie.

Waar ’n moderne tonnel die werklike vereiste is, kies ’n ontwerp wat TCP of UDP doelbewus gebruik eerder as om te hoop dat ’n vertaler reg raai.

Enkapsulering bepaal wat die filter sien

Enkapsulering verander die buitenste pakket, en die buitenste pakket is wat ’n reël pas. Inheemse ESP is protokol 50, terwyl NAT-deurgang ESP binne UDP 4500 toedraai sodat dit adresvertaling kan oorleef. ’n Filter wat UDP 4500 toelaat, sien nooit protokol 50 nie, en ’n filter wat vir protokol 50 geskryf is, pas nooit die toegedraaide vorm nie.

Vra watter enkapsulering die kliënt en die poort bestem het, en skryf dan die reël vir daardie buitenste vorm en niks meer nie.

Skryf die reël so dat iemand dit kan kontroleer

Druk elke reël uit as adresfamilie, buitenste protokol, vervoerpoorte indien enige, rigting en albei eindpunte. ’n Resensent kan daardie sin met ’n pakketopname vergelyk en tot ’n oordeel kom. ’n Opdrag om 47 oop te maak, kan niemand kontroleer nie, en daarom oorleef dit jare lank in runbooks.

Voeg die toets by wat dit bewys: verbind terwyl jy op die buitenste koppelvlak vasvang, en bevestig die buitenste protokol en poort wat werklik in die spoor verskyn.