Felicitaciones, acaba de profundizar en el concepto de capas de red al darse cuenta de que los puertos y protocolos no están directamente conectados entre sí. Como dicen otros, telnet se puede usar para conectarse a cualquier puerto TCP. Sin embargo, para comprender por qué esto es posible, debe comprender un poco acerca de las capas de red. Si alguna vez has oído hablar del modelo de capa OSI 7, esto es lo que te permite usar telnet para conectarte a otro puerto. Aunque en Internet, solo se refieren a 4 de las capas y se llama Internet Protocol Suite . Sin capas de red, cada programa no solo necesitaría comprender su propio protocolo, sino que también tendría que definir su propio esquema de direccionamiento IP y sistema de puertos, lo que significa que cada enrutador necesitaría comprender cómo enrutar estos esquemas y diferentes protocolos serían mucho más difícil de aprender y diagnosticar. En pocas palabras, Internet no funcionaría tan bien sin capas.
Lo que le preocupa es la capa de transporte y la capa de aplicación. En la capa de transporte tenemos protocolos de Internet como TCP y UDP con números de puerto que van del 1 al 65535 en cada uno. En la capa de aplicación tenemos protocolos como HTTP, SMTP y DNS. Por lo general, cada documento de estándares de Internet que define un protocolo especifica un puerto TCP o UDP predeterminado que el protocolo debe usar de manera predeterminada. Como el puerto TCP 80 para HTTP, el puerto TCP 25 para SMTP, el puerto UDP 53 para DNS y el puerto TCP 23 para Telnet. El programa telnet en realidad habla el protocolo TELNET, que es un protocolo estándar, pero principalmente uno antiguo según los estándares actuales. Debido a que sus secuencias de protocolo están hechas de caracteres de 8 bits, rara vez se ve el protocolo en sí y es mayormente transparente en comparación con otros protocolos más modernos como HTTP y SMTP que usan palabras visibles en humanos en ASCII como GET, POST, HELO, LOGIN, etc.
Debido a que su protocolo no es generalmente visible, Telnet fue una herramienta decente para conectarse a otros puertos TCP y permitir al usuario escribir protocolos manualmente. Algunos administradores de red utilizan esta técnica para diagnosticar problemas con los servidores. Sin embargo, debido a que el programa telnet todavía tiene su propio protocolo y puede enviar bits de datos adicionales a veces, aún puede experimentar problemas con esta técnica. Cuando usa telnet, realmente está "haciendo una conexión" en la capa de aplicación y en la capa de transporte. Simplemente sucede que otros protocolos de capa de aplicación pueden funcionar bien para la mayoría de los diagnósticos y no interferirán con el protocolo telnet. Hay un mejor programa para hacerlo llamado nc (Net Cat. Recibe su nombre de ser una versión basada en la red del comando cat).
$ nc www.stackexchange.com 80
El programa nc no habla ningún protocolo de capa de aplicación y cuando realiza una conexión con él está "haciendo una conexión" solo en la capa de Internet (dirección IP) y la capa de transporte (TCP o UDP). Lo que eso significa es que usted controla qué protocolo de capa de aplicación se utiliza. Casi todo es juego limpio, incluso protocolos binarios. Esto también le permite hacer cosas útiles como transferir archivos sin que estén dañados y escuchar en los puertos el tráfico entrante:
nc -l 9000 < movie.mp4 (Your friend runs this)
nc friends.computer.hostname 9000 > movie.mp4 (you run this)
Y luego movie.mp4 se transfiere a través de la red sin ningún protocolo de capa de aplicación (como FTP). El protocolo de aplicación es en realidad tu amigo diciéndote que están listos para que ejecutes tu comando.
nc también puede manejar paquetes UDP y sockets de dominio UNIX. Usarlo para escuchar también puede ser interesante.
nc -l 12345
Ahora en su navegador web visite http: // localhost: 12345 / y en su sesión nc debería ver la GET / HTTP/1.1
solicitud del navegador . En este punto, puede escribir algo y presionar Ctrl-D
y debería aparecer en su navegador en texto sin formato (si desea que se muestre HTML, debe enviarlo de vuelta con la respuesta de protocolo HTTP adecuada seguido del código HTML).
A veces, los programas que hablan de forma nativa un protocolo como HTTP pueden conectarse a otros puertos que están destinados a un protocolo diferente. Por lo general, ya no puede hacer esto en un navegador GUI porque les ha impedido conectarse a algunos puertos, pero si usa un programa como curl para conectarse al puerto 25 (SMTP para enviar correo) probablemente verá un par de errores sobre romper el protocolo.
$ curl yourispsmtpserverhost.com:25
220 yourispsmtpserverhost.com ESMTP Postfix
221 2.7.0 Error: I can break rules, too. Goodbye.
Esto sucede porque curl normalmente habla el protocolo HTTP, por lo que después de establecer un protocolo de enlace TCP, comienza a enviar datos de esta manera:
GET / HTTP/1.1
Host: yourispsmtpserverhost.com:25
User-agent: curl
Pero lo que el servidor SMTP espera es SMTP, que es más como esto:
HELO myhomecomputername.local
En ese momento el servidor devuelve su línea de identificación:
250 yourispsmtpserverhost.com
Entonces, verá que no hay nada que impida que curl establezca una conexión de capa de transporte con el servidor SMTP, simplemente no puede hablar el protocolo. Pero puede hablar el protocolo usted mismo con un programa como telnet o más preferiblemente nc.
nc(1)
) es mucho más flexible. Se puede conectar a servicios cifrados SSL / TLS y también se puede utilizar como servidor e incluso transmitir datos.