Te traemos el arreglo a esta incógnita, al menos eso creemos. Si continuas con dudas coméntalo, que para nosotros será un placer ayudarte
Solución:
Felicitaciones, acaba de profundizar en el concepto de capas de red al darse cuenta de que los puertos y protocolos no están conectados directamente entre sí. Como dicen otros, telnet se puede utilizar para conectarse a cualquier puerto TCP. Sin embargo, para comprender por qué esto es posible, debe comprender un poco las capas de red. Si alguna vez ha oído hablar del modelo OSI de 7 capas, esto es lo que le permite usar telnet para conectarse a otro puerto. Aunque en Internet, solo se preocupan por 4 de las capas y se llama Internet Protocol Suite. Sin capas de redes, 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 los diferentes protocolos serían mucho más importantes. 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 mayormente 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 humanas 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” tanto en la capa de aplicación como en la capa de transporte. Simplemente sucede que otros protocolos de la capa de aplicación pueden funcionar bien a través de él para la mayoría de los diagnósticos y no interferirán con el protocolo Telnet. Hay un programa mejor para hacer esto llamado nc (Net Cat. Obtiene 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 usted hace 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 los protocolos binarios. Esto también le permite hacer cosas útiles como transferir archivos sin que se corrompan 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 la 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 el GET / HTTP/1.1 solicitud. En este punto, puede escribir algo y presionar Ctrl-D y debería aparecer en su navegador en texto sin formato (si desea que aparezca HTML, debe devolverlo con la respuesta del protocolo HTTP adecuada seguida 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 han restringido la conexión 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 la ruptura del 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 como este:
GET / HTTP/1.1
Host: yourispsmtpserverhost.com:25
User-agent: curl
Pero lo que espera el servidor SMTP es SMTP, que se parece más a 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.
telnet es una herramienta que puede conectarse a cualquier puerto tcp.
De forma predeterminada, se conecta al puerto telnet (23), pero puede decirle que se conecte al puerto http (80) o al puerto smtp (25) o lo que sea.
Sin embargo, necesita saber cómo “hablar” el protocolo que el servidor remoto está escuchando en ese puerto.
Por ejemplo, si desea obtener los encabezados de un sitio web (nombres de dominio, etc. cambiados para proteger a los culpables):
$ telnet www.example.com 80
Trying xxx.xxx.xxx.xxx...
Connected to www.example.com.
Escape character is '^]'.
HEAD http://www.example.com/ HTTP/1.0
HTTP/1.1 200 OK
Date: Fri, 30 Oct 2015 09:28:58 GMT
Server: Apache/2.4.17 (Debian)
Last-Modified: Sun, 14 Nov 2010 06:30:26 GMT
ETag: "843-494fd75830480"
Accept-Ranges: bytes
Content-Length: 2115
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
Connection closed by foreign host.
El HEAD línea es lo que escribí en la conexión. Tenga en cuenta que el protocolo http requiere que envíe una línea en blanco para indicar el final de su HEAD o GET o cualquier solicitud. Esa es la línea en blanco inmediatamente después de la solicitud HEAD.
La negociación inicial para ambos protocolos utiliza comandos de texto, por lo que puede conectarse y comenzar a ingresar comandos. Esto es true de otro viejo protocolos como SMTP y telnet se han utilizado durante mucho tiempo para solucionar problemas conexiones a los respectivos servicios.
Por ejemplo
- Ayuda de HTTP: Cómo probar HTTP usando Telnet
- XFOR: Telnet al puerto 25 para probar la comunicación SMTP
Los protocolos son independientes del puerto en el que se comunican. Casi todas las implementaciones se pueden configurar para escuchar en cualquier puerto.
Algunos protocolos (como HTTPS) no utilizan comandos de texto para la negociación. Sin embargo, puede (normalmente) conectarse al Puerto en el que escucha el servidor, pero no hace nada útil.
Más adelante puedes encontrar los comentarios de otros gestores de proyectos, tú asimismo eres capaz mostrar el tuyo si te apetece.