Protocolo 47 fronte ao porto TCP 47: dúas cabeceiras, dúas regras

As redes de hotel e os cortalumes de conferencias adoitan amosar unha caixa de permiso personalizada, e alguén escribe 47 nela esperando que PPTP funcione. A regra créase, o túnel segue fallando e o seguinte intento usa outro número. O que saíu mal está no propio paquete: IPv4 ten un campo de protocolo que nomea o que vén despois da cabeceira IP, mentres que TCP e UDP teñen campos de porto que só existen cando xa estás dentro dunha desas cabeceiras. Non son dúas grafías do mesmo permiso.

A cabeceira IPv4 nomea o protocolo seguinte

O campo de protocolo é un byte na cabeceira IPv4 e contén un número que describe a carga útil: 6 para TCP, 17 para UDP, 47 para GRE, 50 para ESP. Todo o que filtra paquetes le ese valor antes de mirar máis fondo, porque a cabeceira máis interna só ten sentido unha vez coñecido o tipo. Cambia un porto máis adiante na conversa e este campo non se moveu.

Por tanto, unha regra escrita contra o protocolo 47 describe a capa IP. Ningún porto participa na decisión.

Os portos existen dentro de TCP e UDP, en ningún outro sitio

Os portos son identificadores de dezaseis bits dentro das cabeceiras TCP e UDP, e a súa tarefa é separar conversas que comparten un enderezo. Unha cabeceira GRE leva un valor de tipo de protocolo, a miúdo un EtherType, máis chaves opcionais para a multiplexación. Por iso a expresión porto 47 non nomea nada co que un paquete GRE poida coincidir.

As interfaces de cortalumes difiren en canto disto expoñen. Algunhas aceptan un número de protocolo, outras ofrecen unha lista con nomes e unhas poucas só aceptan TCP ou UDP con portos.

PPTP usa as dúas capas á vez

PPTP é o exemplo máis claro porque reparte deliberadamente o seu traballo entre as dúas. A conexión de control é unha sesión TCP cara ao porto 1723, e a ruta de datos é GRE, protocolo 47, sen ningún porto implicado en ningures. Un cortalumes que permite 1723 e nada máis deixa comezar a negociación e despois descarta a carga útil. O túnel parece quedar colgado tras a autenticación en lugar de non conectar, e por iso o síntoma adoita notificarse como un problema de contrasinal.

Le as dúas filas por separado ao escribir a regra, e comproba cada unha contra a sintaxe do fabricante. Unha fila necesita un porto, a outra necesita un número de protocolo, e ningunha entrada única cobre ambas.

Por que unha páxina de redirección de portos non pode expresar GRE

Un formulario de redirección que só acepta TCP e UDP non pode describir GRE, chámese como se chame o formulario. A tradución de enderezos engade unha segunda dificultade, porque GRE non ten portos e o tradutor debe seguir no seu lugar o identificador de chamada. Algúns routers domésticos inclúen un asistente que o resolve; moitos non, e ningunha entrada adicional de permiso TCP creará ese comportamento.

Cando o requisito real é un túnel moderno, escolle un deseño que use TCP ou UDP a propósito en lugar de esperar que un tradutor adiviñe ben.

A encapsulación decide que ve o filtro

A encapsulación cambia o paquete externo, e o paquete externo é o que unha regra fai coincidir. O ESP nativo é o protocolo 50, mentres que o tránsito por NAT envolve ESP dentro de UDP 4500 para que sobreviva á tradución de enderezos. Un filtro que permite UDP 4500 nunca ve o protocolo 50, e un filtro escrito para o protocolo 50 nunca coincide coa forma envolta.

Pregunta en que encapsulación se puxeron de acordo o cliente e a pasarela, e despois escribe a regra para esa forma externa e nada máis.

Escribe a regra para que alguén poida comprobala

Expresa cada regra como familia de enderezos, protocolo externo, portos de transporte se os hai, dirección e ambos os extremos. Un revisor pode comparar esa frase cunha captura de paquetes e chegar a un veredicto. Unha instrución de abrir 47 non a pode comprobar ninguén, e así sobrevive anos nos manuais de procedementos.

Engade a proba que o demostra: conéctate mentres capturas na interface externa, e confirma o protocolo externo e o porto que aparecen realmente na traza.