Bueno, me doy cuenta de que esta situación es algo inusual, pero necesito establecer una conexión TCP (el enlace de tres vías) utilizando solo conectores crudos (en C, en Linux), es decir, necesito construyo los encabezados IP y los encabezados TCP yo mismo. Estoy escribiendo un servidor (así que primero tengo que responder al paquete SYN entrante) y, por la razón que sea, parece que no puedo hacerlo bien. Sí, me doy cuenta de que SOCK_STREAM se encargará de esto por mí, pero por razones que no quiero mencionar, no es una opción.Protocolo de enlace TCP con socket SOCK_RAW
Los tutoriales que he encontrado en línea sobre el uso de sockets sin formato describen cómo crear un flooder SYN, pero esto es algo más fácil que establecer una conexión TCP, ya que no tiene que construir una respuesta basada en el original paquete. Obtuve el funcionamiento de los ejemplos de Flooder SYN, y puedo leer el paquete SYN entrante sin problemas desde el socket sin formato, pero todavía tengo problemas para crear una respuesta SYN/ACK válida a un SYN entrante del cliente.
Entonces, ¿alguien sabe un buen tutorial sobre el uso de sockets sin formato que va más allá de crear un flooder SYN, o alguien tiene algún código que pueda hacer esto (usando SOCK_RAW, y no SOCK_STREAM)? Estaría muy agradecido.
MarkR tiene toda la razón - el problema es que el núcleo es el envío de paquetes de restablecimiento en respuesta al paquete inicial, ya que piensa que el puerto está cerrado. El núcleo me está golpeando a la respuesta y la conexión muere. Ya estaba usando tcpdump para monitorear la conexión, debería haber sido más observador y haber notado que había DOS respuestas, una de ellas era un reinicio que estaba estropeando las cosas, así como la respuesta que creó mi programa. D'OH!
La solución que parece funcionar mejor es usar una regla de iptables, como sugiere MarkR, para bloquear los paquetes de salida. Sin embargo, hay una manera más fácil de hacerlo que usar la opción de marca, como se sugiere. Solo coincido si está configurado el indicador de reinicio TCP. Durante el curso de una conexión normal, es poco probable que sea necesario, y realmente no importa a mi aplicación si bloqueo todos los paquetes de reinicio salientes del puerto que se está utilizando. Esto efectivamente bloquea la respuesta no deseada del kernel, pero no mis propios paquetes. Si el puerto de mi programa está escuchando en el 9999 es entonces la regla de iptables se parece a esto:
iptables -t filter -I OUTPUT -p tcp --sport 9999 --tcp-flags RST RST -j DROP
Sé que es una pregunta de hace 4 años, pero su sugerencia parece bastante interesante, así que decidí pedirle una aclaración. La pregunta es: ¿Hay algún problema con el enrutador mientras enruta el paquete de respuesta a cierta máquina con la dirección MAC del dispositivo incorrecto? ¿El paquete será filtrado por el firewall o antivirus de hoy en día? –
Los switches pueden filtrar un MAC falso si están configurados para la seguridad del puerto. Es posible que haya ACL en la capa MAC, pero normalmente no hay nada que le impida falsificar MAC. Solo necesita asegurarse de que su tarjeta de red acepte respuestas a este mac falsificado (agregando el mac a la tabla de paquetes aceptados o poniéndolo en modo promisc). Esta es una mala idea para hacer esto si no está autorizado. – eckes