Eu configurei totalmente (remotamente) um servidor dedicado Debian GNU/Linux hospedado em capacidade profissional e tenho uma pergunta sobre roteamento de rede (que AFAICT se encaixa precisamente no FAQ de serverfault).
Esse servidor dedicado possui um IP IPv4 estático e uma rota muito simples:
route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
94.xx.yy.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 94.xx.yy.254 0.0.0.0 UG 0 0 0 eth0
Tenho apenas um IP estático e há muitos outros servidores dedicados na mesma sub-rede com os quais não posso mexer.
Esse servidor está hospedando/servindo o webapp principal da nossa empresa (Apache + Tomcat) e também executando o Squid. Eu mesmo fiz toda a configuração. Assim que o orçamento permitir, moverei o Squid para outro servidor.
Por enquanto, gostaria de adicionar o OpenVPN a esse servidor (de preferência usando tun, não tap) e quero saber o que precisa ser feito para ter certeza de que minhas interfaces não entrarão em conflito com os outros servidores dedicados.
Não entendo como a configuração deve ser feita e estou confuso sobre como será a rota.
Para me ajudar a entender o "quadro geral", alguém poderia dar um exemplo preciso de:
- endereço IP local de um cliente OpenVPN
- IP do gateway que esse cliente OpenVPN deve usar
- a saída da rota do servidor OpenVPN
Basicamente estou um pouco perdido e antes de começar gostaria de entender como é feito o roteamento no servidor OpenVPN.
Pelo que entendi, os clientes OpenVPN devem estar na mesma rede que o servidor OpenVPN (usando, digamos, uma rede 10.0.0.0/8), mas estou enfrentando um obstáculo mental ao tentar descobrir como os clientes irão use a interface 'tun' para acabar usando o gateway 94.xx.yy.254.
Responder1
Suponha que o cliente VPN tenha as seguintes configurações de IP:
IP eth0: 192.168.1.100
Default gateway: 192.168.1.1
Portanto, todo o tráfego não local sairá por 192.168.1.1. Se houver tráfego para outro host na LAN, ele irá apenas para esse host.
O OpenVPN é inicializado, o cliente obtém uma nova interface tun0 e então vemos algo como:
IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 192.168.1.1
VPN routing: 10.8.0.1 for the network 10.8.0.0/24
Isso pressupõe que o servidor OpenVPN não esteja enviando nenhuma rota adicional. Portanto, um pacote de rede indo para, digamos, 8.8.8.8, ainda passará pelo gateway padrão da LAN, 192.168.1.1. Um pacote indo para, digamos, 10.8.0.204, atravessará o túnel OpenVPN até o servidor OpenVPN em 10.8.0.1 para roteamento adicional.
Se o servidor OpenVPN enviar uma rota para sua LAN, digamos, 172.16.0.0/24, o roteamento VPN acima poderá ser semelhante a:
VPN routing: 10.8.0.1 for the network 10.8.0.0/24
10.8.0.1 for the network 172.16.0.0/24
Assim, da mesma forma, um pacote para 172.16.0.24 irá para 10.8.0.1 para roteamento adicional.
Se o servidor OpenVPN também estiver pressionando a configuração "redirect-gateway def1", o gateway padrão será diferente nos clientes VPN. Você verá algo como:
IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 10.8.0.1
(other gateway with lower priority): 192.168.1.1
Static route: 94.xx.yy.zz uses 192.168.1.1
Onde 94.xx.yy.zz é o endereço IP público do seu servidor OpenVPN.
Neste caso, o tráfego diretamente para o seu servidor OpenVPN passará pelo gateway padrão da LAN 192.168.1.1. O tráfego local para 192.168.1.0/24 irá apenas para os hosts conforme esperado. Qualquer outro tráfego usará 10.8.0.1; o tráfego não local que não vai diretamente para o IP público do servidor OpenVPN atravessará o túnel VPN e sairá de 94.xx.yy.254.
Você poderá ver outra rota padrão na tabela de roteamento que mantém 192.168.1.1 como gateway, mas terá uma prioridade menor que 10.8.0.1. Acho que isso é mais um espaço reservado do cliente OpenVPN, para que ele saiba como definir a rota padrão, assim que a VPN for desligada. Não se preocupe com essa entrada.