Voglio distribuire un Raspberry Pi nel mio cottage per il fine settimana. Raspberry Pi è lì per registrare le temperature e inviarle a un server remoto che ha un IP fisso, salva i dati e li visualizza su un semplice sito Web.

Tuttavia, potrebbe verificarsi la situazione in cui desidero modificare qualcosa sul Raspberry Pi. Ad esempio aggiornamenti di sistema o una modifica del programma che invia i dati al server o altro.

Con la configurazione proposta non sarei in grado di connettermi a Raspberry Pi dall'esterno della sua LAN.

NOTA: non voglio cambiare la rete e il router esistente non ha la possibilità di port forwarding, dynDNS o VPN.

Di recente ho letto sulla perforazione UDP. L'idea di base è che il client invia un pacchetto UDP a un indirizzo server noto (ovvero con un IP pubblico o dynDNS abilitato). Il client B che vorrebbe connettersi al client A richiede al server l'IP pubblico e il numero di porta del client A.

Quindi può connettersi al client A direttamente sul suo IP pubblico e sulla porta che è dinamica. Poiché il client A si è connesso per la prima volta al server sulla porta ora utilizzata, il NAT inoltrerà i pacchetti al client A.

Spero di aver riassunto l'idea correttamente, più o meno ...

Tutto questo suona bene, ma il problema è che questo non è garantito per funzionare con una connessione TCP, poiché il router è in grado di "capire" l'handshake della connessione TCP e se non è costruito correttamente, non verrà inoltrato i pacchetti.

Quindi, come posso aprire una sessione SSH dal client B al client A, senza il client A seduto dietro un router con dynDNS, un IP pubblico fisso o la possibilità di port forwarding? L'uso di un server centrale con un IP pubblico, fisso o nome di dominio sarebbe possibile.

pwnat

"..non è banale avviare una connessione a un peer dietro NAT. "

"... quasi tutte le implementazioni NAT si rifiutano di inoltrare traffico in entrata che non corrisponde a una recente richiesta in uscita corrispondente. "

"..Lo pwnatstrumento è un'implementazione autonoma solo GNU / Linux di attraversamento NAT autonomo. Dopo aver contattato il server dietro il NAT, stabilisce un canale con semantica TCP, usando i pacchetti UDP. Supporta client e server dietro NAT (se uno dei NAT consente la trasmissione di messaggi ICMP falsi [personalizzati] . Questa implementazione è rivolta agli utenti finali. "

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

  -c modalità client
    <args>: [ip locale] <porta locale> <host proxy> [porta proxy (def: 2222)] <host remoto> <porta remota>

  -s modalità server
    <args>: [ip locale] [porta proxy (def: 2222)] [[host consentito]: [porta consentita] ...]

  -6 usa IPv6  
  -v mostra l'output di debug (fino a 2)  
  -h mostra aiuto ed esce  

Esempi:  

    Lato server che consente a chiunque di eseguire il proxy:
      ./pwnat -s

    Cliente che desidera connettersi a google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Quindi, vai a http: // localhost: 8000 per visitare google!  

"L'idea chiave per abilitare il server di per imparare l'indirizzo IP del client è per il server di ad inviare periodicamente un messaggio a un noto indirizzo IP fisso. L'approccio più semplice utilizza i messaggi di richiesta ICMP ECHO a un indirizzo IP non allocato, come ad esempio 1.2.3.4 . Poiché 1.2.3.4 non è assegnato, la RICHIESTA ICMP non verrà instradata dai router senza una route predefinita. "

"Come risultato dei messaggi inviati a 1.2.3.4, il NAT consentirà il routing delle risposte, in risposta a questa richiesta. Il client di connessione falsificherà quindi tale risposta. In particolare, il client trasmetterà un messaggio ICMP indicante TTL_EXPIRED. Tale il messaggio potrebbe essere legittimamente trasmesso da qualsiasi router Internet e non è previsto che l'indirizzo del mittente corrisponda all'IP di destinazione del server. "

" Il server è in attesa di risposte (false) ICMP e alla ricezione, avvia una connessione all'IP mittente specificato nella risposta ICMP. Se il client utilizza un indirizzo IP instradabile a livello globale, questo è del tutto privo di problemi e può essere utilizzato sia TCP che UDP stabilire una connessione bidirezionale se il cliente ascolta su una porta prestabilita. "

"(Nei casi in cui non esiste una porta prestabilita, nella maggior parte dei casi è possibile comunicare un numero di porta come parte del payload di ICMP ECHO RESPONSE)."

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

Ecco un paio di soluzioni:

Puoi configurare Raspberry Pi per riconnetterti a un server OpenVPN e avrai accesso ad esso tutto il tempo.

Puoi dare un'occhiata a PageKite. Controlla https://pagekite.net/wiki/Howto/SshOverPageKite/

È una soluzione un po 'sporca ma semplice, ma per quanto riguarda l'utilizzo di netcat? Su Raspberry Pi puoi creare uno script che esegue il ciclo del comando:

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

Sul tuo host locale, fai:

nc -l <port1>

E:

nc -l <port2>  

Sarai in grado di digitare un comando nella prima istanza e vedere la risposta nella seconda.