VPN site a site com CGNAT
Desculpe se postei isso no lugar errado. Deixe-me saber se devo mover isso para outro site SE. Continue com a história ...
Meu ISP doméstico às vezes (mas não de forma consistente) nos força por meio de um CGNAT, no entanto, eu preciso de acesso remoto aos dispositivos locais de maneira confiável (contanto que haja conectividade com a Internet em primeiro lugar; nenhuma maneira de evitar esse requisito :)) . Antes de trocar de ISP (o antigo ISP sempre me deu o mesmo endereço IPv4 público), eu poderia simplesmente usar o OpenVPN e pronto.
Agora que o CGNAT é uma possibilidade real, o OpenVPN não é mais uma maneira confiável de me conectar remotamente aos recursos da minha LAN. Portanto, estou procurando outra solução confiável o suficiente (ela me permitirá várias coisas que são meio necessárias - acessar câmeras de segurança remotamente - e útil - reverter servidor SSH para meu local de trabalho).
Agora para a configuração:
- Em casa, tenho um Raspberry Pi. Modelo 3 B + se for importante (eu ficaria surpreso, mas fornecendo-o para ser completo). Está atrás de um roteador meu que se conecta ao ISP (PPPoE). Ele tem acesso total aos recursos da LAN. Eu tenho um IPv4 fixo privado (embora agora com o problema CGNAT eu esteja pensando em remover o requisito "fixo"; provavelmente não é tão útil quanto antes tê-lo corrigido de qualquer maneira) e um endereço IPv6 automático (SLAAC, sem extensões de privacidade) roteado publicamente . Não há garantias de que irei obter o mesmo / 64 de reconectar para reconectar (e, portanto, os endereços IP irão variar com o tempo).
- Fora do local, tenho um host AWS EC2 (o menor, que é "gratuito", mas acho que não será realmente gratuito). Tenho o IPv4 e o IPv6 elásticos configurados no host, com a configuração adequada do gateway (perdi muito tempo, mas consegui fazer no final). Então, tecnicamente, eu poderia me conectar daqui ao Pi via IPv6 (assumindo que haja um serviço DNS dinâmico adequado que o Pi possa usar para IPv6) ou de Pi ao host AWS em IPv4 e IPv6.
- No trabalho, tenho uma rede altamente protegida, para a qual desejo apenas fazer SSH reverso. Provavelmente, posso apenas usar a instância AWS como um host de salto e resolvê-lo muito rapidamente. Quer dizer, posso executar o servidor SSH na instância AWS na porta 443 de qualquer maneira. Portanto, não é um problema real (a porta 22 está bloqueada pelo firewall de trabalho :()
Preciso de ajuda dupla:
- Primeiro, como configurar a conexão direta do meu Raspberry Pi para o host AWS para que o host AWS tenha acesso direto a todos os meus recursos de LAN (eventualmente personalizável por minhas regras de firewall no Raspberry Pi)
- Em segundo lugar, como garantir que esse suporte iniciará automaticamente toda vez que o Pi for reiniciado (tendo a reiniciá-lo com frequência suficiente, e quedas de energia causarão reinicializações não intencionais também).
Observe que eu tenho uma solução alternativa, mas é realmente uma droga. Envolve reiniciar meu roteador por meio do serviço de nuvem TP-Link várias vezes sempre que obtenho um endereço IP CGNAT até obter um público. Então meu ISP é útil o suficiente para fornecer um serviço de DNS dinâmico adequado para que eu possa resolver para meu endereço público (OU meu endereço privado, se eu obtiver CGNAT; isso não é tão útil assim). Eu quero ser capaz de esquecer essas soluções alternativas, realmente.
Respostas
Na verdade, eu descobri sozinho no final. Segui os tutoriais usuais:
- Primeiro, instale o OpenVPN no servidor (instância EC2) e no cliente (Raspberry Pi atrás do CGNAT) e também instale o Easy-RSA apenas no servidor.
- Em seguida, gere algumas coisas usando Easy-RSA (informações retiradas diretamente dos tutoriais nas páginas da comunidade OpenVPN):
- Em primeiro lugar, configure as variáveis no arquivo "vars". Os padrões funcionam bem, mas é recomendável alterá-los de qualquer maneira.
- Copie openssl-1.0.0.cnf para openssl.cnf (outras versões também podem funcionar).
- Execute ./clean-all (isso apagará todas as chaves preexistentes e configurações extras, para começar de uma tela em branco).
- Execute ./build-ca (isso irá gerar keys / ca.crt e keys / ca.key; o último deve ser protegido - você pode destruí-lo assim que tiver certeza de que não precisa atualizar a configuração para adicionar mais clientes. O primeiro é o certificado que deve permanecer)
- Execute ./build-key-server para gerar um par de chaves do servidor. Apenas o servidor exige isso.
- Execute ./build-key para gerar as chaves para os clientes. Execute-o uma vez por cliente. Só executei uma vez no total, para o meu cliente "raspberrypi". Os arquivos gerados precisarão ser copiados no lado do cliente.
- Copie os arquivos para onde eles pertencem:
- keys / ca.crt é necessário para o servidor e o cliente.
- keys / ca.key é necessário se você deseja adicionar clientes adicionais e é a principal coisa que você deseja proteger. Se você não precisa de flexibilidade extra, é recomendado que você execute o comando "shred" nele ou mova-o para um sistema seguro conhecido (que pode ser bloqueado pelo que vale a pena)
- keys / raspberrypi. {crt, key} pertencem ao cliente (no meu caso, o cliente é raspberrypi, você digita seu próprio nome específico para o (s) cliente (s)) e deve ser copiado de acordo com os clientes.
- chaves / servidor. {crt, chave} permanecem no servidor. O arquivo .crt é enviado automaticamente em qualquer tentativa de conexão, portanto, não há necessidade de copiá-lo manualmente no cliente.
- A parte Easy-RSA está pronta.
- Configure o OpenVPN no lado do servidor
- A configuração do servidor padrão é adequada, salve algumas alterações:
- As opções ca, cert e key devem ser atualizadas para apontar para os arquivos ca.crt, server.crt e, respectivamente, server.key. O arquivo server.key deve ser protegido (permissões 0400), embora eu não tenha certeza se isso está realmente marcado.
- Eu configurei "sub-rede de topologia". Isso não é estritamente necessário, mas é uma coisa boa.
- Mudei a diretiva "server" para outro intervalo IPv4 privado, para garantir que não entre em conflito com outro servidor OpenVPN (o do meu roteador). Afinal, farei algum roteamento estático posteriormente para que os intervalos não se sobreponham.
- client-config-dir client (defina a subpasta "client" para ser especial e conter configurações específicas do cliente; isso é importante para o roteamento)
- cliente-para-cliente eu continuo, novamente para que o roteamento funcione corretamente.
- Comentei a opção "tls-auth ta.key 0" em ambos os casos; isso gera um aviso, mas não preciso de segurança extra. Posso descomentar no futuro, uma vez que descobrir como funciona. Por motivos de segurança, no entanto, é extremamente recomendável ter essa opção.
- Eu adicionei uma declaração
push "route 172.31.0.0 255.255.240.0"para empurrar a rota para a rede privada do AWS em direção ao meu Raspberry Pi.
- Além disso, para o cliente, você precisa ter um arquivo cliente / raspberrypi (novamente com base no nome do cliente) que contém
iroute 192.168.1.0 255.255.255.0(para que o roteamento funcione da instância AWS em direção ao Pi e à rede doméstica.
- A configuração do servidor padrão é adequada, salve algumas alterações:
- O cliente também precisa ser configurado
- Configure o endereço remoto. Acabei de colocar o endereço IP elástico que tenho em minha instância AWS, porque ele não mudará até que eu mexa com ele.
- Configure as diretivas ca, cert, key (ca para ca.crt, cert para raspberrypi.crt, chave para raspberrypi.key).
- Comente a diretiva tls-auth, assim como no servidor. Isso deve corresponder ao servidor.
- Habilite os serviços SystemD (isso se encarrega de habilitar o túnel na inicialização). No servidor, você
systemctl enable openvpn@server; systemctl start openvpn@serverassume que seu arquivo de configuração é /etc/openvpn/server.conf. Você não pode usar isso para subpastas. No cliente é o mesmo, exceto pelo fato de ser client.conf para o nome do arquivo que você colocaropenvpn@client.
Agora o que me resta é fazer alguns encaminhamentos de porta, que entretanto não são o assunto desta pergunta.