Resumen

  • Una configuración aceptada no demuestra que esté aplicada, que el cliente haya utilizado el proxy seleccionado ni que este haya autorizado y establecido la conexión solicitada. El criterio operativo propuesto es asociar cada resultado a una configuración efectiva, una sesión y un destino, sin convertir una confirmación administrativa en evidencia de tráfico.
  • Una conexión retransmitida tampoco acredita por sí sola la identidad del servidor ni el éxito de una operación. La aceptación del servicio debe distinguir transporte, autenticación y resultado funcional; además, debe conservar el contexto suficiente para explicar posteriormente qué se comprobó, desde dónde y con qué permisos.

El error empieza al cerrar el cambio

Dar por disponible una aplicación después de recibir una respuesta satisfactoria a su configuración confunde el objeto de dos operaciones distintas. Una modifica el comportamiento que se espera del cliente. La otra utiliza ese cliente para intentar realizar un trabajo remoto. El éxito de la primera no contiene, por implicación, el resultado de la segunda.

NETCONF permite localizar exactamente el salto injustificado. El elemento <ok/> indica que una solicitud RPC se procesó sin errores ni advertencias y sin devolver datos; su significado depende de la operación a la que responde. Si confirma una modificación de configuración, no constituye una contestación del servicio que esa configuración pretende alcanzar. Así lo delimita la RFC 6241, sección 4.4.

La primera comprobación pendiente es incluso anterior a la red. La arquitectura NMDA distingue la configuración actual, running, de la configuración transformada que el sistema intenta aplicar, intended. El almacén operational incluye la configuración efectivamente utilizada y el estado operativo. La RFC 8342, secciones 5.1.3, 5.1.4 y 5.3, establece esa separación: intención y aplicación no son nombres alternativos del mismo hecho.

La consecuencia operativa es exigir dos respuestas, no una: qué aceptó el gestor y qué utilizó realmente el proceso que abrió la conexión. Consultar el estado aplicado mejora la evidencia, pero todavía no acredita una negociación SOCKS ni una respuesta remota. Incluso cuando la configuración correcta ya está en uso, sigue pendiente comprobar sus resultados.

Aquí no interesa cuánto dura una asociación UDP de SOCKS5. El problema es otro: qué comprobaciones permiten declarar utilizable un servicio después de configurar una salida TCP mediante un intermediario.

Tres agrupamientos y dos direcciones que no deben confundirse

Un agrupamiento YANG es una estructura reutilizable, no un servicio que se despliegue por sí mismo. La instrucción grouping no crea por sí sola nodos en el árbol del esquema; uses permite incorporarlos, con los ajustes correspondientes. Esta distinción procede de la RFC 7950, secciones 7.12 y 7.13. Por tanto, la evaluación debe identificar el modelo consumidor y la instancia concreta, no limitarse a comprobar que figura el nombre de un módulo.

La RFC 9643, secciones 2 a 4, distribuye la configuración entre tres agrupamientos:

Módulo y agrupamiento Qué permite configurar
ietf-tcp-common / tcp-common-grouping Sondas TCP de mantenimiento opcionales: idle-time, max-probes y probe-interval.
ietf-tcp-client / tcp-client-grouping Destino, vinculación local opcional, proxy opcional y parámetros comunes.
ietf-tcp-server / tcp-server-grouping Puntos locales de escucha mediante local-bind y parámetros comunes.

El documento no define nodos config false que informen de resultados operativos. El contenedor proxy-server es opcional; al configurarlo, debe elegirse SOCKS4, SOCKS4a o SOCKS5, según las funciones soportadas. La descripción del modelo distingue SOCKS4a por admitir nombres además de direcciones IP.

El remote-address exterior identifica el destino; el anidado bajo los parámetros SOCKS, el proxy. El puerto predeterminado 1080 corresponde al intermediario; el tratamiento del puerto del destino queda al modelo consumidor. Para SOCKS5, authentication-parameters también es opcional; presente, selecciona GSS-API o usuario y contraseña. El contenedor gss-api queda vacío, preparado para ampliaciones. Estos detalles están recogidos en la RFC 9643, sección 3.

La recomendación práctica es conservar ambas identidades de red en cualquier comprobación. Un registro que solo diga «conectado a la dirección remota» resulta insuficiente si no permite saber si habla del intermediario o del servicio final.

También conviene separar el nombre solicitado de la dirección utilizada. Para atribuir un intento a un extremo concreto, el operador debería conservar el resultado de resolución cuando sea observable y señalar qué componente lo obtuvo. Resolver el mismo nombre más tarde no reconstruye necesariamente el intento anterior. Cuando ese dato falte, debe permanecer como incertidumbre.

Elegir SOCKS no equivale a obtener permiso para pasar

En SOCKS5 se abre primero TCP hacia el proxy. Después se ofrecen métodos, el servidor selecciona uno, se realiza la subnegociación correspondiente y se solicita CONNECT con destino y puerto. La RFC 1928, secciones 3 a 6, distingue la selección sin autenticación, 0x00, de la ausencia de métodos aceptables, 0xFF, y de los resultados posteriores de retransmisión: éxito, prohibición por reglas, destino inalcanzable o conexión rechazada.

La inferencia es inmediata, pero operativamente importante: una credencial aceptada no garantiza permiso para alcanzar cualquier destino. Tampoco omitir parámetros de autenticación en la configuración demuestra qué método se negoció. La opción administrativa y el intercambio observado deben contrastarse, no tratarse como duplicados.

La credencial introduce además una frontera entre representación y uso. La RFC 9640, secciones 2.1.4.1 y 2.1.4.2, permite representar contraseñas en claro o cifradas mediante password-grouping. En la representación cifrada, encrypted-by debe ser ampliado por el modelo consumidor con referencias a las claves correspondientes. Una estructura que describe el secreto no es, por sí misma, el resultado de utilizarlo.

Como criterio de aceptación, conviene comprobar que el proceso autorizado pudo obtener la credencial necesaria y que el interlocutor la aceptó. Esto no exige copiar el secreto en el registro de vigilancia. Un resultado de autenticación, asociado a una referencia de credencial y a una sesión, puede aportar la evidencia necesaria sin multiplicar lugares donde una contraseña queda expuesta.

Con usuario y contraseña, la RFC 1929, secciones 2 y 3, define una respuesta propia de autenticación y advierte que la contraseña viaja en claro dentro de esa subnegociación. Cifrar su representación almacenada no cambia ese formato. Tampoco una sesión TLS establecida posteriormente con el destino protege retroactivamente un intercambio anterior con el proxy. La pregunta de seguridad debe precisar qué tramo se protege, desde qué momento y frente a quién.

GSS-API exige comprobar otros hechos. La RFC 1961, secciones 3 a 5, separa el establecimiento del contexto de seguridad entre cliente y servidor SOCKS de la negociación de protección de los mensajes. Contempla integridad, integridad con confidencialidad y protección selectiva; si el nivel elegido por el servidor resulta inaceptable, el cliente debe cerrar la conexión.

La evidencia útil debería identificar el mecanismo, el interlocutor y el nivel efectivamente acordados, no únicamente la opción seleccionada en la configuración. Autenticar la relación con el proxy, incluso protegiendo sus mensajes, no sustituye la autenticación del servidor de aplicación situado detrás.

Para el diagnóstico, estas distinciones evitan una etiqueta excesivamente amplia: «fallo del proxy». Un desacuerdo sobre métodos, una credencial rechazada y una denegación de salida reclaman responsables y remedios diferentes. Ampliar permisos sin identificar la etapa fallida puede modificar un control que estaba funcionando correctamente.

El proxy comunica un resultado, no una identidad de aplicación

Una respuesta satisfactoria de CONNECT sí tiene valor: conforme al procedimiento SOCKS5, comunica el éxito de la conexión solicitada y permite comenzar el intercambio de datos. Pero BND.ADDR y BND.PORT describen el extremo utilizado por el proxy para conectar al destino, no la dirección y el puerto del servidor aplicativo. Así lo especifica la RFC 1928, sección 6.

La recomendación es tratar esa respuesta como una observación del cliente sobre lo comunicado por el intermediario, sin presentarla como una captura directa de todo el tramo saliente. Para investigar la salida concreta utilizada, puede ser necesario correlacionarla con registros del proxy.

También deben distinguirse las conexiones cliente–proxy y proxy–destino. Establecer la primera no demuestra la segunda. TCP proporciona un flujo fiable y ordenado de bytes; sus mecanismos de establecimiento y confirmación no constituyen respuestas de operaciones de aplicación. Esa es la frontera de transporte descrita en la RFC 9293, secciones 2.2 y 3.5.

La evidencia adicional debe ser proporcional a la afirmación. Para comprobar una operación concreta, una respuesta autenticada y correlacionada puede ser decisiva. Para atribuir un fallo a una salida específica del intermediario, harán falta observaciones de ese tramo. Ninguna de las dos necesidades autoriza a rellenar automáticamente la otra.

Existe además un error inverso: obtener una respuesta correcta de la aplicación y concluir que se utilizó el proxy exigido. El éxito funcional no demuestra por sí mismo el cumplimiento del camino autorizado. La prueba debería vincular resultado, sesión y ruta efectiva; de lo contrario, un acceso directo podría parecer satisfactorio para disponibilidad y ser inaceptable para el control de salida.

SSH y TLS responden a otra pregunta: con quién se habla

Las configuraciones de autenticación pertenecen a capas distintas. La RFC 9644, sección 3.1.2.1, separa la identidad del cliente SSH de las anclas utilizadas para autenticar al servidor. La RFC 9645, sección 3.1.2.1, establece una separación equivalente para TLS y contempla que la autenticación del cliente pueda realizarse en una capa superior. Incorporar esos parámetros amplía lo configurado; no constituye el registro de una autenticación ejecutada.

En SSH hay que distinguir reconocer la clave del servidor de verificar la prueba criptográfica del intercambio. La RFC 4253, sección 8, describe la comprobación de que la clave pertenece al servidor y la verificación de la firma del intercambio. También advierte que aceptar la clave sin verificar su vinculación deja el protocolo expuesto a ataques activos.

La conclusión operativa es que «SSH conectado» resulta demasiado ambiguo. Conviene saber qué clave se presentó, por qué se consideró perteneciente al servidor esperado y qué comprobación terminó correctamente. La identidad usada por el cliente para acceder al servicio y los permisos concedidos a ese cliente requieren resultados diferenciados; no quedan demostrados únicamente por reconocer al servidor.

En TLS 1.3 con certificados, CertificateVerify aporta una prueba de posesión de la clave privada correspondiente y Finished autentica el intercambio y las claves calculadas. Son comprobaciones concretas de la RFC 8446, secciones 4.4.3 y 4.4.4, no consecuencias de haber abierto un puerto.

La identidad esperada tampoco debe extraerse circularmente de lo que presente el interlocutor. La RFC 9525, sección 6.1.1, exige construir los identificadores de referencia independientemente de los identificadores presentados por el servidor. Para una conexión dirigida a un servicio mediante SOCKS, sustituir sin justificación el nombre de ese servicio por el del proxy cambiaría la pregunta de autenticación.

Por tanto, la evidencia recomendada no es simplemente «había un certificado». Debe indicar la identidad esperada, el resultado de su comprobación y el contexto de confianza aplicado. Si se admite una excepción, esa excepción forma parte del resultado y no debería desaparecer bajo una etiqueta genérica de éxito.

No toda sesión TLS presenta un certificado nuevo: existen modalidades con claves precompartidas y reanudación, descritas en la RFC 8446, sección 2.2. El registro debe reflejar el mecanismo realmente utilizado y la asociación de confianza relevante. Exigir siempre la misma evidencia documental produciría falsos diagnósticos.

Finalmente, autenticar una pasarela no identifica por sí solo un servidor interno concreto. La afirmación defendible es la que corresponde al extremo autenticado y a la operación observada, no a una arquitectura interna supuesta.

La respuesta debe pertenecer a la operación que importa

Alcanzabilidad, autorización y éxito funcional necesitan resultados separados. Para un servicio NETCONF, una prueba concreta sería solicitar mediante <get-config> una parte conocida de su configuración y evaluar la contestación. La RFC 6241, secciones 4.2, 4.3 y 7.1, define esa operación, la respuesta <rpc-reply> con el mismo message-id y la comunicación de errores mediante <rpc-error>.

El criterio propuesto es relacionar solicitud y respuesta dentro de una sesión identificada, después de comprobar la identidad del servidor. Una contestación auténtica que rechaza la operación demuestra algo diferente de un intento que no obtuvo respuesta. Y una respuesta sintácticamente correcta solo acredita el trabajo previsto si su contenido satisface el criterio de aceptación establecido.

No hay contradicción con el error inicial. El primer intercambio configuraba un cliente; este segundo intercambio utiliza la ruta resultante para consultar una aplicación remota. Aunque ambos emplearan NETCONF, serían operaciones distintas, posiblemente contra sistemas distintos y con identidades diferentes.

El operador debe declarar qué pretende probar antes de elegir la sonda. Para acreditar acceso de consulta, una lectura autorizada puede ser adecuada. Para acreditar capacidad de modificación, esa lectura no basta. Tampoco una comprobación realizada con una cuenta administrativa representa automáticamente a clientes con permisos limitados.

Conviene conservar el resultado interpretado y establecer un plazo de validez de la observación. Una prueba positiva sigue siendo una muestra situada: determinada operación, identidad, ruta y momento. No acredita todos los destinos posibles de un nombre, todos los usuarios ni disponibilidad continua. Una comprobación que no se ejecutó no debería figurar como exitosa por ausencia de errores.

Las sondas de mantenimiento no prueban trabajo útil

Los mecanismos TCP de mantenimiento, o keepalives, solicitan una respuesta del par TCP durante la inactividad. La RFC 9293, sección 3.8.4, exige que estén desactivados por defecto, permite controlarlos por conexión y prohíbe interpretar la falta de respuesta a una sonda aislada como prueba de conexión muerta.

En una conexión cliente–proxy, una respuesta a esa sonda no demuestra que el servidor de aplicación esté procesando solicitudes. Acortar los intervalos cambia cuándo se buscan señales; no convierte una comprobación de transporte en una operación funcional ni en una nueva validación de identidad.

La decisión razonable es instrumentar la capa que contiene el compromiso que se quiere vigilar. Para mantener una sesión de transporte, interesa su estado. Para asegurar una consulta autenticada, interesa su respuesta. Para asegurar la finalización de una modificación, interesa el resultado de esa modificación. Una señal de una capa inferior puede ayudar al diagnóstico sin sustituir la prueba de la superior.

El límite de evidencia es también un límite de responsabilidad. Quien aplica la configuración debe poder identificarla; quien administra el proxy, explicar la retransmisión; quien define la confianza, justificar la identidad aceptada; y quien opera la aplicación, establecer qué resultado cuenta como útil. Dar por disponible el conjunto exige relacionar esas respuestas, no escoger la primera que parezca satisfactoria.