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

No entanto, pode surgir a situação em que 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 for.

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

NOTA: Não quero alterar a rede e o roteador existente não tem capacidade de encaminhamento de porta, dynDNS ou VPN.

Eu li recentemente sobre perfuração UDP. A idéia básica é que o cliente envie um pacote UDP para um endereço de servidor conhecido (ou seja, com um IP público ou dynDNS ativado). 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.

Em seguida, ele pode se conectar ao cliente A diretamente no seu 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 para o cliente A.

Espero ter resumido a idéia corretamente, mais ou menos ...

Isso tudo soa bem, mas o problema é que isso não é garantido para funcionar 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 fixo ou a capacidade de encaminhamento de porta? O uso de um servidor central com um IP público, fixo ou nome de domínio seria muito difícil.

pwnat

"..não é trivial iniciar uma conexão com um par atrás do NAT. "

".. quase todas as implementações de NAT se recusam a encaminhar o tráfego de entrada que não corresponde a uma solicitação de saída correspondente recente. "

"..A pwnatferramenta é uma implementação autônoma de passagem autônoma de NAT , apenas para GNU / Linux . Depois de entrar em contato com o servidor por trás do NAT, ele estabelece um canal com semântica TCP, usando pacotes UDP. Ele suporta cliente e servidor por trás de NAT (se um dos NATs permitir que as mensagens ICMP falsas [personalizadas] sejam transmitidas). Essa implementação é direcionada aos usuários finais. "

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

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

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

  -6 usa IPv6  
  -v mostra saída de depuração (até 2)  
  -h mostra ajuda e sai  

Exemplos:  

    Lado do servidor, permitindo que qualquer pessoa faça proxy:
      ./pwnat -s

    Cliente que deseja se conectar ao google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Em seguida, navegue até http: // localhost: 8000 para visitar o google!  

"A ideia-chave para ativar o servidor para saber o endereço IP do cliente é para o servidor para enviar periodicamente uma mensagem para um endereço fixo conhecido IP. A abordagem mais simples usa mensagens de solicitação de eco ICMP para um endereço IP não alocado, tais como 1.2.3.4 Como o 1.2.3.4 não está alocado, o ICMP REQUEST não será roteado pelos roteadores sem uma rota padrão. "

"Como resultado das mensagens enviadas para 1.2.3.4, o NAT permitirá o roteamento de respostas, em resposta a esta solicitação. O cliente de conexão falsificará essa resposta. Especificamente, o cliente transmitirá uma mensagem ICMP indicando TTL_EXPIRED. a mensagem pode ser legitimamente transmitida por qualquer roteador da Internet e não se espera que o endereço do remetente corresponda ao IP de destino do servidor " .

" O servidor escuta as respostas (falsas) do ICMP e, após o recebimento, inicia uma conexão com o IP do remetente especificado na resposta do ICMP. Se o cliente estiver usando um endereço IP roteado globalmente, isso é totalmente sem problemas e o TCP ou UDP pode ser usado para estabelecer uma conexão bidirecional se o cliente ouvir em uma porta pré-acordada " .

"(Nos casos em que não há porta pré-acordada, na maioria dos casos , um número de porta pode ser comunicado como parte da carga útil da resposta de eco do ICMP)."

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

Aqui estão algumas soluções:

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

Você pode dar uma olhada no PageKite. Verifique https://pagekite.net/wiki/Howto/SshOverPageKite/

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

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

No 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.