Como usar o furo UDP para um túnel / sessão SSH

18

Eu quero implantar um Raspberry Pi na minha casa de fim de semana. O Raspberry Pi está lá para registrar as temperaturas e enviá-las para um servidor remoto que possui um ip fixo, salva os dados e os exibe em um site simples.

No entanto, a situação pode surgir que eu quero mudar alguma coisa no Raspberry Pi. Por exemplo, atualizações do sistema ou uma alteração no programa que envia os dados para o servidor ou o que quer que seja.

Com a configuração proposta, eu não conseguiria me conectar ao Raspberry Pi de fora da LAN.

OBSERVAÇÃO: Eu não quero alterar a rede, e o roteador existente não tem a capacidade de encaminhamento de porta, dynDNS ou VPN.

Li recentemente sobre perfuração UDP. A idéia básica é que o cliente envia um pacote UDP para um endereço de servidor conhecido (ou seja, com um IP público ou dynDNS habilitado). O cliente B que deseja se conectar ao cliente A solicita ao servidor o IP público e o número da porta do cliente A.

Ela pode se conectar ao cliente A diretamente no IP público e na porta, que é dinâmica. Como o cliente A primeiro se conectou ao servidor na porta agora usada, o NAT encaminhará os pacotes ao cliente A.

Espero ter resumido a ideia corretamente, mais ou menos…

Tudo isso soa legal, mas o problema é que isso não é esquecido de trabalhar com uma conexão TCP, pois o roteador é capaz de “entender” o handshake da conexão TCP e, se não for construído corretamente, não encaminhará os pacotes.

Então, como posso abrir uma sessão SSH do cliente B para o cliente A, sem o cliente A sentado atrás de um roteador com dynDNS, um IP público de correção ou a capacidade de encaminhamento de porta? O uso de um servidor central com um endereço IP ou nome de domínio público seria difícil.

    
por Christian 03.03.2015 / 21:18

3 respostas

5

pwnat

"..it is not trivial to initiate a connection to a peer behind NAT."

"..almost all NAT implementations refuse to forward inbound traffic that doesn't correspond to a recent matching outbound request."

"..The pwnat tool is a GNU/Linux-only, stand-alone implementation of autonomous NAT traversal. After contacting the server behind the NAT, it establishes a channel with TCP semantics, using UDP packets. It supports both client and server behind NAT (if one of the NATs allows the fake [custom] ICMP messages to be transmitted). This implementation targets end-users."

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

  -c    client mode
    <args>: [local ip] <local port> <proxy host> [proxy port (def:2222)] <remote host> <remote port>

  -s    server mode
    <args>: [local ip] [proxy port (def:2222)] [[allowed host]:[allowed port] ...]

  -6    use IPv6  
  -v    show debug output (up to 2)  
  -h    show help and exit  

Examples:  

    Server side allowing anyone to proxy:
      ./pwnat -s

    Client wanting to connect to google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Then, browse to http://localhost:8000 to visit the google!  

"The key idea for enabling the server to learn the client’s IP address is for the server to periodically send a message to a fixed, known IP address. The simplest approach uses ICMP ECHO REQUEST messages to an unallocated IP address, such as 1.2.3.4. Since 1.2.3.4 is not allocated, the ICMP REQUEST won't be routed by routers without a default route."

"As a result of the messages sent to 1.2.3.4, the NAT will enable routing of replies, in response to this request. The connecting client will then fake such a reply. Specifically, the client will transmit an ICMP message indicating TTL_EXPIRED. Such a message could legitimately be transmitted by any Internet router and the sender address is not expected to match the server’s target IP."

"The server listens for (fake) ICMP replies and upon receipt, initiates a connection to the sender IP specified in the ICMP reply. If the client is using a globally routable IP address, this is entirely unproblematic and both TCP or UDP can be used to establish a bi-directional connection if the client listens on a pre-agreed port."

"(In cases where there is no pre-agreed port, a port number can in most cases be communicated as part of the payload of the ICMP ECHO RESPONSE)."

Fonte: link
link

    
por 20.12.2015 / 05:19
1

Aqui estão algumas soluções:

Você pode configurar seu Raspberry Pi para se conectar a um servidor OpenVPN e terá acesso a ele o tempo todo.

Você pode dar uma olhada no PageKite. Verifique o link

    
por 10.10.2015 / 06:37
0

É uma solução um tanto suja mas fácil, mas e o uso do netcat? No Raspberry Pi você pode criar um script que faça um loop no comando:

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

No seu host local, faça:

nc -l <port1>

E:

nc -l <port2>  

Você poderá digitar um comando na primeira instância e ver a resposta na segunda.

    
por 15.04.2015 / 00:00