Meta : Para replicar a funcionalidade que tenho com o StrongVPN no meu próprio Debian VPS. Com o StrongVPN, aparentemente, todas as portas no IP público fornecido são encaminhadas para o cliente, ou seja, por exemplo, o ssh: 22 de 'fora' se conecta ao meu roteador. Também upnp / NATPMP etc nos clientes do meu roteador apenas trabalho (skype, de volta ao meu mac). A ressalva é que o servidor precisará 'manter' o recebimento de tráfego em certas portas (22, 80, etc) para manter a funcionalidade, portanto, eles precisarão 'recortar' de qualquer configuração de encaminhamento via IPtables.
Servidor : Eu tenho um VPS, o mais recente Debian rodando OpenVPN e bind9. Eu tenho um NIC e um IP público. Este servidor também executa o apache, e eu precisarei de acesso a ele via ssh para configuração.
Cliente : um roteador executando o OpenWRT. Eu tenho essa configuração para usar StrongVPN atualmente. Eu quero passar para o meu próprio VPS.
Requerido : ajuda na geração de um conjunto adequado de regras para o iptables.
Eu tenho uma configuração básica do OpenVPN estabelecida abaixo, assim como os princípios das regras do iptable.
client.conf:
remote 46.aaa.xxx.yyy 1194 udp
dev tun
ifconfig 172.19.233.2 172.19.233.1
secret static.key
redirect-gateway def1
server.conf:
dev tun
proto udp
port 1194
ifconfig 172.19.233.1 172.19.233.2
secret /etc/openvpn/static.key
ifconfig:
eth0 Link encap:Ethernet HWaddr 52:XXXXXXXXXXXX
inet addr:46.aaa.xxx.yyy Bcast:46.aaa.xxx.xxx Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34338527 errors:0 dropped:20 overruns:0 frame:0
TX packets:747507 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2697230329 (2.5 GiB) TX bytes:577951758 (551.1 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18947 errors:0 dropped:0 overruns:0 frame:0
TX packets:18947 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2143690 (2.0 MiB) TX bytes:2143690 (2.0 MiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.19.233.1 P-t-P:172.19.233.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:164495 errors:0 dropped:0 overruns:0 frame:0
TX packets:166083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:54062402 (51.5 MiB) TX bytes:162532235 (155.0 MiB)
iptables-save:
# Generated by iptables-save v1.4.14 on Mon Mar 30 21:47:41 2015
*nat
:PREROUTING ACCEPT [2:344]
:INPUT ACCEPT [1:172]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING ! -d 172.19.233.0/24 -s 172.19.233.0/24 -j MASQUERADE
COMMIT
# Completed on Mon Mar 30 21:47:41 2015
# Generated by iptables-save v1.4.14 on Mon Mar 30 21:47:41 2015
*raw
:PREROUTING ACCEPT [413:36237]
:OUTPUT ACCEPT [190:21548]
COMMIT
# Completed on Mon Mar 30 21:47:41 2015
# Generated by iptables-save v1.4.14 on Mon Mar 30 21:47:41 2015
*filter
:INPUT DROP [5239:662523]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [11365:1381174]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22,53,80,123,443,1194 -j ACCEPT
-A INPUT -p udp -m multiport --dports 53,123,1194 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
-A OUTPUT -o eth+ -j ACCEPT
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Mon Mar 30 21:47:41 2015
Atualizar
Em vez de Masquerading, a linha a seguir ajuda no tráfego da VPN para a Internet:
iptables -t nat -A POSTROUTING ! -d 172.19.233.0/24 -j SNAT --to-source 46.aaa.xxx.yyy
Para que o tráfego flua da Internet para o cliente VPN, o funcionamento abaixo parece funcionar:
iptables -t nat -A PREROUTING -p tcp -m multiport ! --dports 22,53,80,123,443,1194 -j DNAT --to-destination 172.19.233.2
iptables -t nat -A PREROUTING -p udp -m multiport ! --dports 53,123,1194 -j DNAT --to-destination 172.19.233.2
Estas linhas espelham as portas aceitas no INPUT na tabela de filtros. Em seguida, alterar o cliente VPN para escutar em portas alternativas para ssh / http, etc. significa tráfego para, por exemplo, 46.aaa.xxx.yyy: 2222 para o cliente.
Mas não tenho certeza se isso é adequado para serviços como o Skype / BTMM que exigem algumas portas abertas.