Quiero implementar una Raspberry Pi en mi cabaña de fin de semana. El Raspberry Pi está allí para registrar las temperaturas y enviarlas a un servidor remoto que tiene una ip fija, guarda los datos y los muestra en un sitio web simple.

Sin embargo, puede surgir la situación de que quiero cambiar algo en la Raspberry Pi. Por ejemplo, actualizaciones del sistema o un cambio en el programa que envía los datos al servidor o lo que sea.

Con la configuración propuesta, no podría conectarme a Raspberry Pi desde fuera de su LAN.

NOTA: No quiero cambiar la red, y el enrutador existente no tiene la capacidad de reenvío de puertos, dynDNS o VPN.

Recientemente leí sobre la perforación de agujeros UDP. La idea básica es que el cliente envía un paquete UDP a una dirección de servidor conocida (es decir, con una IP pública o dynDNS habilitado). El cliente B que desea conectarse al cliente A le pide al servidor la IP pública y el número de puerto del cliente A.

Luego puede conectarse al cliente A directamente en su IP pública y puerto que es dinámico. Debido a que el cliente A se conectó por primera vez al servidor en el puerto ahora utilizado, el NAT reenviará los paquetes al cliente A.

Espero haber resumido la idea correctamente, más o menos ...

Todo esto suena bien, pero el problema es que esto no está garantizado para funcionar con una conexión TCP, ya que el enrutador puede "entender" el apretón de manos de la conexión TCP y, si no está configurado correctamente, no se reenviará los paquetes.

Entonces, ¿cómo puedo abrir una sesión SSH del cliente B al cliente A, sin el cliente A sentado detrás de un enrutador con dynDNS, una IP pública fija o la capacidad de reenvío de puertos? El uso de un servidor central con un IP público, fijo o nombre de dominio sería posible difícil.

pwnat

"... no es trivial iniciar una conexión con un par detrás de NAT " .

"... casi todas las implementaciones de NAT se niegan a reenviar el tráfico entrante que no corresponde a una solicitud saliente coincidente reciente "

".. La pwnatherramienta es una implementación autónoma de GNU / Linux de transversal NAT autónomo. Después de contactar al servidor detrás de NAT, establece un canal con semántica TCP, utilizando paquetes UDP. Es compatible tanto con el cliente como con el servidor detrás de NAT (si uno de los NAT permite la transmisión de mensajes ICMP falsos [personalizados] ). Esta implementación está dirigida a los usuarios finales " .

  
uso: ./pwnat <-s | -c> <args>

  -c modo cliente
    <args>: [ip local] <puerto local> <host proxy> [puerto proxy (def: 2222)] <host remoto> <puerto remoto>

  -s modo servidor
    <args>: [ip local] [puerto proxy (def: 2222)] [[host permitido]: [puerto permitido] ...]

  -6 usa IPv6  
  -v muestra la salida de depuración (hasta 2)  
  -h mostrar ayuda y salir  

Ejemplos:  

    Lado del servidor que permite a cualquier persona proxy:
      ./pwnat -s

    Cliente que desea conectarse a google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Luego, vaya a http: // localhost: 8000 para visitar google.  

"La idea clave para que el servidor para obtener la dirección IP del cliente es para el servidor para enviar periódicamente un mensaje a una dirección fija, conocida IP. El enfoque más simple usa mensajes ICMP ECHO REQUEST a una dirección IP no asignada, tal como 1.2.3.4 . Dado que 1.2.3.4 no está asignado, la SOLICITUD ICMP no será enrutada por enrutadores sin una ruta predeterminada " .

"Como resultado de los mensajes enviados a 1.2.3.4, el NAT permitirá el enrutamiento de las respuestas, en respuesta a esta solicitud. El cliente que se conecta entonces falsificará dicha respuesta. Específicamente, el cliente transmitirá un mensaje ICMP indicando TTL_EXPIRED. cualquier mensaje podría ser transmitido legítimamente por cualquier enrutador de Internet y no se espera que la dirección del remitente coincida con la IP de destino del servidor " .

" El servidor escucha las respuestas ICMP (falsas) y, una vez recibido, inicia una conexión con la dirección IP del remitente especificada en la respuesta ICMP. Si el cliente está usando una dirección IP globalmente enrutable, esto no tiene ningún problema y se pueden usar tanto TCP como UDP. establecer una conexión bidireccional si el cliente escucha en un puerto previamente acordado " .

"(En los casos en que no haya un puerto acordado previamente, en la mayoría de los casos se puede comunicar un número de puerto como parte de la carga útil de ICMP ECHO RESPONSE)".

Fuente: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat

Aquí hay un par de soluciones:

Puede configurar su Raspberry Pi para conectarse nuevamente a un servidor OpenVPN y tendrá acceso a él todo el tiempo.

Puedes echar un vistazo a PageKite. Verifique https://pagekite.net/wiki/Howto/SshOverPageKite/

Es una solución algo sucia pero fácil, pero ¿qué pasa con el uso de netcat? En Raspberry Pi puedes crear un script que repita el comando:

nc <public_ip> <port1> | sh | nc <public_ip> <port2>  

En su host local, haga:

nc -l <port1>

Y:

nc -l <port2>  

Podrá escribir un comando en la primera instancia y ver la respuesta en la segunda.