Olá a todos,
Como praticamente todos os entusiastas de homelabbing em Portugal já sentiram, estamos muitas vezes presos a um IP dinâmico, atribuído pelo ISP.
Isto só por si não é problemático. Um cliente de dynamic dns (feito por vós ou off-the-self) e o problema fica resolvido.
Podem igualmente usar um reverse proxy em apache ou nginx na vossa VPS e fazerem o routing do trafego através de uma VPN.
Mas e se quiserem reter o source IP original, ou se o protocolo que estejam a utilizar não suporte reverse-proxying?
Podem não querer divulgar o IP publico de saída da vossa rede de casa!
Existe uma solução bem mais imaginativa, fazendo uma ponte Layer2 entre a vossa VPS e vossa pfsense de perímetro.
Isto alem de permitir que todo o trafego passe encriptado, e irá igualmente permitir que tenham os IP’s públicos que desejem desde que a vossa VPS os tenha (ao contrário do vosso pacote fornecido pelo operador de Internet).
No meu caso, o meu provider – IPDroid – vende ip’s extras para VPS por um custo bastante apelativo.
É uma hipótese bastante interessante para quem utiliza acessos em NAT 3G (por exemplo o MEO).
Nos vossos routers 3G validem se o IP externo do vosso acesso 3G não está com IP de gama privada (RFC 1918). Este IP como sabem não é routeavel logo não sendo acessível desde a internet para correr serviços.
Comecemos então com a configuração do lado da VPS:
port 50000
proto tcp
dev tap0
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
client-config-dir ccd
keepalive 10 120
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log log_openvpn.log
log-append log_openvpn.log
verb 4
mute 5
mssfix 1400
tcp-queue-limit 256
tun-mtu-extra 32
txqueuelen 15000
A parte importante aqui é o device tap. Este tipo de device faz que o engine da openVPN, funcione em bridge mode.
Em seguida será necessário configurar a configurar a interface de frontend da VPS:
# The loopback network interface
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
# Configuração Tipica IPDROID.PT
address IP_PUBLICO_DA_VPS
netmask 255.255.255.240
post-up /sbin/ip route add 89.26.247.225 dev br0
post-up /sbin/ip route add default via 89.26.247.225
pre-down /sbin/ip route del default via 89.26.247.225
pre-down /sbin/ip route del 89.26.247.225 dev br0
dns-nameserver 8.8.8.8
# NOTA: Parte que faz o bridge entre o tap device e a ethernet em si.
pre-up openvpn –mktun –dev tap0
bridge_ports eth0 tap0
bridge_fd 3
Nota: Esta configuração foi feita para Debian. Sim é possível fazer a mesma configuração em Centos/RHEL/SuSE, modificando o ifup-post que está na diretoria /etc/sysconfig/network-scripts.
Em seguida, e para finalizar a configuração será necessário configurar o acesso do lado da pfsense, como se fosse novo cliente openvpn, o que por si é bastante fácil e já foi abordado anteriormente no blog.
Resumidamente devemos adicionar as CA’s/certs/keys geradas na VPS á pfsense para este túnel.
Podem fazer o percurso inverso, aproveitando a CA da pfsense, certificados e keys mas isto irá vos obrigar a copy/paste que tendencialmente acaba por correr mal.
Nota: Não se esqueçam de configurar o vosso device para tap e não para tun.
Em seguida ir a Interface Assignments e criar uma interface virtual associando a interface openvpn que acabaram de configurar como network port.
Escolhem um dos IP’s públicos da vossa VPS e atribuam ele como o IP da vossa nova interface.
Em seguida, vão a Firewall, Virtual IP’s e adicionem o mesmo IP.
Repetir por todos os ip’s públicos que tenham publicado na vossa VPS e que queiram fazer tunneling para a vossa pfsense.
Finalmente voltem a vossa pagina de configuração de interface e coloquem a gateway. Deverá ser a gateway que tem agora na vossa VPS. Muita atenção para NÃO colocarem esta nova gateway como default gateway.
Nota: Caso a vossa pfsense se queixe (como foi no meu caso) podem selecionar na secção de gateway config a opção Use non-local gateway through interface specific route
Concluindo, esta é uma forma extremamente imaginativa de se ter mais que um IP publico em casa, embora a utilização por uma VPS remota seja suficiente para a maioria dos utilizadores.
Permite ainda a quem use acessos 3G/4G nos seus homelabs, que possa ter serviços públicos expostos desde deles, mesmo quando a ligação está feita em NAT.
Existe apenas uma salvaguarda que tem de ser feita: Este método usa openvpn com os seus problemas habituais de falta de performance em grande carga, especialmente com CPU’s mais modestos. Beware!
Como sempre caso tenham duvidas já sabem onde me encontrar!
Até a próxima!
Nuno
Referencias:
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-16-04
http://users.ox.ac.uk/~clas0415/assets/Setting-up-pfSense-as-a-Stateful-Bridging-Firewall-with-commodity-hardware.pdf
