Roteie todo o tráfego de rede através de uma conexão openvpn e também aceite solicitações recebidas no endereço IP real dos hosts

1

Estou procurando uma solução para rotear todo o tráfego de um servidor através do OpenVPN, mas mantendo a possibilidade de hospedar aplicativos no servidor que podem ser acessados fora da rede local.

Para ser um pouco mais específico: Existem dois aplicativos hospedados no servidor. Há um aplicativo que liga a porta 80 e outro que liga a porta 8080. Todo o tráfego de e para esses serviços precisa ser direcionado, todo o outro tráfego deve passar pelo túnel VPN.

No momento, as solicitações estão sendo recebidas diretamente, mas não respondidas, quando a VPN está em execução. Todos os serviços podem ser alcançados quando eu desabilitar a VPN:

Como posso configurar o OpenVPN, por exemplo com um script up, para que essas rotas sejam roteadas corretamente?

Uma visão geral das minhas interfaces de rede:

lo Link encap:Local Loopback 
inet addr:127.0.0.1 Mask:255.0.0.0 
inet6 addr: ::1/128 Scope:Host 
UP LOOPBACK RUNNING MTU:65536 Metric:1 
RX packets:537169 errors:0 dropped:0 overruns:0 frame:0 
TX packets:537169 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:0 
RX bytes:147901148 (147.9 MB) TX bytes:147901148 (147.9 MB) 

p4p1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx 
inet addr:192.168.2.201 Bcast:192.168.2.255 Mask:255.255.255.0 
inet6 addr: xxx/64 Scope:Global 
inet6 addr: xxx/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:8062700 errors:0 dropped:180 overruns:0 frame:0 
TX packets:10937639 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:1000 
RX bytes:7942028079 (7.9 GB) TX bytes:12229412785 (12.2 GB) 

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
inet addr:XX P-t-P:XX Mask:255.255.255.255 
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 
RX packets:6382168 errors:0 dropped:0 overruns:0 frame:0 
TX packets:6004894 errors:0 dropped:46397 overruns:0 carrier:0 
collisions:0 txqueuelen:100 
RX bytes:7066816609 (7.0 GB) TX bytes:4808493953 (4.8 GB) 

Tabelas de roteamento antes da conexão com a VPN:

ip route show
default via 192.168.2.254 dev p4p1
192.168.2.0/24 dev p4p1  proto kernel  scope link  src 192.168.2.201

Tabelas de roteamento após a conexão com a VPN:

ip route show
0.0.0.0/1 via 10.124.1.5 dev tun0
default via 192.168.2.254 dev p4p1
10.124.1.1 via 10.124.1.5 dev tun0
10.124.1.5 dev tun0  proto kernel  scope link  src 10.124.1.6
109.201.154.152 via 192.168.2.254 dev p4p1
128.0.0.0/1 via 10.124.1.5 dev tun0
192.168.2.0/24 dev p4p1  proto kernel  scope link  src 192.168.2.201
    
por Laurence 02.05.2016 / 14:19

4 respostas

1

Eu tive o mesmo problema que você teve. Você tem que desabilitar o rp_filter e redirecionar todo o tráfego com a porta de destino 80 e 8080 para a sua interface normal.

Desativar filtragem de caminho inverso

for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
echo 0 > $i
done

Vamos usar a tabela 100. Certifique-se de que não seja usada por mais nada! Nós vamos liberá-lo

ip route flush table 100
ip route del default table 100
ip rule del fwmark 1 table 100
ip route flush cache
iptables -t mangle -F PREROUTING

Crie a tabela para todas as conexões (não o túnel da VPN)

ip route show table main | grep -Ev ^default | grep -Ev tun0 \
| while read ROUTE ; do
ip route add table 100 $ROUTE
done
ip route add default table 100 via 192.168.2.254
ip rule add fwmark 1 table 100 
ip route flush cache

Ignorar a porta 80 e 8080

iptables -t mangle -A PREROUTING -i p4p1 -p tcp -m multiport --dports 80,8080 -j MARK --set-mark 1
    
por 11.05.2016 / 10:22
1

Certamente é (possível) - Policy Based Routing como eles chamam.

Você pode usar a marcação de firewall e aproveitar ip rule .

LARTC é o que você está procurando ler completamente.

    
por 04.05.2016 / 16:13
0

Você pode ignorar ou substituir o push da opção redirect-gateway do servidor. link

Ignoring redirect-gateway

If you are running OpenVPN as a client, and the server you use is using push "redirect-gateway" then your client redirects all internet traffic over the VPN. Sometimes clients do not want this, but they can not change the server's configuration. This page explains how to override redirect-gateway so the client does not need to redirect internet even though the server says to. Method 1: ignore

There are 2 options that can be used to ignore routes pushed by the server:

--route-noexec Don't add or remove routes automatically. Instead pass routes to --route-up script using environmental variables.

--route-nopull When used with --client or --pull, accept options pushed by server EXCEPT for routes and dhcp options like DNS servers. When used on the client, this option effectively bars the server from adding routes to the client's routing table, however note that this option still allows the server to set the TCP/IP properties of the client's TUN/TAP interface.

Method 2: override

Here we will simply add routes that override --redirect-gateway. This will work much like the def1 flag to --redirect-gateway works. This can be different if the server uses the def1 flag to the --redirect-gateway option or not (by checking the log while connecting). Note that net_gateway is an internal variable to openvpn and does not need to be changed to anything. If you do not know if your server uses def1 and do not want to check the logs to figure it out, just assume they DO use def1 and use the 4 routes. That will work no matter what.

def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

If the server DOES NOT use def1 add the following options to the clients config:

route 0.0.0.0 128.0.0.0 net_gateway route 128.0.0.0 128.0.0.0 net_gateway

If the server DOES use def1 or if you do not know, add the following options to the clients config:

route 0.0.0.0 192.0.0.0 net_gateway route 64.0.0.0 192.0.0.0 net_gateway route 128.0.0.0 192.0.0.0 net_gateway route 192.0.0.0 192.0.0.0 net_gateway

Em seguida, o tráfego proveniente de fora passará pelo gateway normal e o tráfego da sub-rede VPN irá para a VPN. Se por trás da sub-rede VPN houver outras redes, você terá que adicionar rotas manualmente.

rota 10.0.0.0 255.255.255.0 vpn_gateway

    
por 08.05.2016 / 04:35
-1

Acredito que a solução certa será Dividir o tunelamento ou é o que farei em uma estação de trabalho cliente, mas sua situação é um pouco diferente, porque existe um servidor: é possível adicionar uma segunda interface de rede?

Nesse caso, você pode rotear todo o seu tráfego de VPN pela primeira interface e, ainda assim, permitir que seu serviço seja atendido pelo segundo.

    
por 02.05.2016 / 15:22