Conecte meu servidor doméstico, executando um servidor OpenVPN, a uma VPN externa


0

Após a situação.

Um dos meus servidores domésticos está executando um servidor OpenVPN e um servidor OpenSSH (e outras coisas) , ambos acessíveis remotamente.

Quando não estou em casa, geralmente conecto ao servidor por VPN e abro algumas sessões SSH por meio do IP público do servidor.

Desejo conectar meu servidor doméstico a uma VPN externa, para que todo o tráfego (de saída) que atravessa meu servidor seja encapsulado na VPN externa também.

|MobilePhone|---VPN ----|
                        |
|Other Dev|-----SSH ----|----VPN---->| Homeserver | --- VPN ---> | External Provider |
                        |               ^
|Laptop|--SSH/NFS/VPN---|               |
                                        |
                                        |
|Laptop|--------SSH---------------------|

Eu ainda quero poder fazer o SSH no meu servidor por meio do seu (antigo) IP público. Meu roteador ainda está conectado diretamente ao meu ISP, portanto, qualquer tráfego de entrada deve ser prevenido diretamente para o servidor, então acho que isso deve ser possível.

Ingênuo como sou, pensei, poderia funcionar se eu conectar meu servidor à VPN externa via tun1 (tun0 é usado pelo servidor) e estou pronto. A configuração do cliente da VPN externa foi nobinddefinida, portanto, também não deve haver conflitos nas portas.

Eu ainda conseguia ver a saída do openvpn connect. No entanto, pouco tempo depois disso, todas as minhas conexões caíram.

* Agora, não consigo me conectar à minha VPN nem SSH nela. O apache também não é mais acessível. Eu acho que nada seria

Meu roteador ainda responde a pings em seu endereço IP público.

Eu acho que a conexão à VPN assumiu a interface de rede dos meus servidores ou algo nesse sentido. Portanto, deve ser um problema de roteamento.

Mas não tenho certeza do que exatamente está acontecendo lá e que coisas eu precisaria mudar para que isso funcionasse.

Gostaria de entender por que isso não está funcionando da maneira que tentei.

Sobre o que preciso aprender para configurar corretamente esse cenário?

Notas :

  • Pensei nos pacotes que retornavam. Mas eu pensei que, de alguma forma, posso configurar uma rota, de modo que todos os pacotes provenientes do IP interno dos meus roteadores sejam enviados de volta ao roteador em vez de através da VPN?
  • Algo como ip route add 192.168.0.0/24 via 192.168.0.1 dev eth1?

Atualizar

Consegui dar um passo adiante adicionando as seguintes linhas ao /etc/network/interfaces

up ip rule add from 192.168.0.0/24 table 128 || true
up ip route add table 128 to 192.168.0.0/24 dev eth0 || true
up ip route add table 128 default via 192.168.178.1 || true

Isso me permitiu acessar o apache e o SSH no meu servidor via seu IP público original, mesmo quando o servidor está conectado a uma VPN externa.

Eu acho que isso acontece com o que eu tinha em mente, todos os pacotes originários da minha LAN ou roteador são roteados pelo eth0 usando o meu roteador como gateway padrão, em vez do adaptador tun1 da VPN externa.

Por enquanto, tudo bem.

O problema que estou tendo agora é que, quando meu laptop está conectado ao servidor OpenVPN em execução no meu servidor doméstico, todas as conexões atingem o tempo limite.

Eu acho que o problema é semelhante ao problema original. Os pacotes originários do meu laptop, conectados via VPN (172.16.0.10), não são roteados de volta para o laptop, pois os pacotes retornados serão enviados pelo gateway padrão, que é a VPN externa à qual meu servidor está conectado.

Eu brinquei com a tabela de roteamento tentando rotear qualquer coisa vinda de 172.16.0.0 de volta para 172.16.0.xx via tun0. Eventualmente, estraguei a tabela de roteamento e agora qualquer solicitação expira quando meu laptop está conectado à VPN dos meus servidores, independentemente de meu servidor estar conectado à VPN externa ou não.

Limpei a tabela de roteamento e reiniciei o servidor, na esperança de corrigir pelo menos isso novamente.

Não tenho certeza se pode ser um problema que meu laptop também esteja conectado à minha LAN (192.168.178.xx).


Seus serviços como SSH e HTTP não funcionarão com o seu IP público real. Se você pensar bem, os pacotes recebidos chegarão ao servidor, mas os pacotes retornados ao seu cliente serão encaminhados pela VPN e parecerão provenientes de um IP completamente diferente.
heavyd

A reinicialização corrigiu os problemas. O SSH e o HTTP funcionam quando o servidor está protegido por uma VPN externa, mas ainda não tenho idéia de como fazer as coisas funcionarem quando meu laptop, por sua vez, está conectado à VPN dos meus servidores.
C5H8NNaO4

1
Você precisa SNAT dos pacotes provenientes do seu laptop e sair pela "outra" VPN. Algo assim deve fazê-lo: #iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
András Korn

@ AndrásKorn Uau, muito obrigado, isso fez o truque! Isso ajudou muito, isso me manteve ocupado nas últimas 5 horas. Deseja agrupar isso em uma resposta? Ainda preciso ler isso antes de poder incluir isso em uma resposta.
C5H8NNaO4

@ C5H8NNaO4, claro, lá vai você. Ainda bem que pude ajudar.
András Korn 22/01

Respostas:


1

Seu problema é que os pacotes enviados pelo seu notebook são enviados através do link VPN do servidor doméstico, usando o endereço de origem original (ou seja, o da tuninterface do laptop , provavelmente). Esses pacotes devem ser descartados pelo seu provedor de VPN, mas mesmo se não estiverem, os pacotes de resposta não encontrarão o caminho para o laptop.

A solução é garantir que os pacotes de resposta também passem pelo seu servidor doméstico; Para isso, elas devem parecer respostas enviadas ao seu servidor doméstico. Portanto, você precisa reescrever o endereço de origem nos pacotes que saem da tun1interface do servidor doméstico para o IP dessa interface, usando, por exemplo,

iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

Usando tcpdump -nlvvv -i tun1você pode verificar o que o comando iptables fez com o tráfego de saída. Se você tivesse usado o tcpdump para analisar o tráfego em primeiro lugar, provavelmente teria percebido imediatamente o que estava errado. :)


Muito obrigado. - tcpdumpvai ser muito útil no futuro, eu acho que eu deveria ler alguns manuais :)
C5H8NNaO4
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.