Dividir encapsulamento de túnel de uma porta específica sobre o OpenVPN no Ubuntu Server 12.04

Question

Então eu sei que há outra pergunta aqui que eu usei como guia, pois foi super útil! ( Configurar roteamento e iptables para nova conexão VPN para redirecionar ** apenas ** as portas 80 e 443 ) Somente minha meta é um pouco diferente. Estou executando uma instalação sem cabeçalho do Ubuntu Server 12.04 que está sendo usada para uma variedade de propósitos diferentes ... Eu gostaria que todo o tráfego viajasse sem proibições através do meu ISP, exceto pelo meu tráfego de transmissão. Eu tenho uma VPN que eu assino que me permite acesso para o qual eu só quero direcionar o tráfego de uma única porta para. No momento, estou usando uma versão modificada do código do link acima. Meu código atual está abaixo:

#!/bin/sh

sleep 200

DEV1=eth0
IP1='ifconfig|perl -nE'/dr:(\S+)/&&say$1'|grep 192.'
GW1=10.0.1.1
TABLE1=open
TABLE2=vpn
DEV2=tun0
IP2='ifconfig|perl -nE'/dr:(\S+)/&&say$1'|grep 10.'
GW2='route -n | grep 'UG[ \t]' | awk '{print $2}''

ip route flush table $TABLE1
ip route flush table $TABLE2
ip route show table main | grep -Ev ^default | while read ROUTE ; do
    ip route add table $TABLE1 $ROUTE
    ip route add table $TABLE2 $ROUTE
done
ip route add table $TABLE1 $GW1 dev $DEV1 src $IP1
ip route add table $TABLE2 $GW2 dev $DEV2 src $IP2
ip route add table $TABLE1 default via $GW1
ip route add table $TABLE2 default via $GW2

echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo "2" > /proc/sys/net/ipv4/conf/tun0/rp_filter

ip rule add from $IP1 lookup $TABLE1
ip rule add from $IP2 lookup $TABLE2
ip rule add fwmark 1 lookup $TABLE1
ip rule add fwmark 2 lookup $TABLE2

iptables -t nat -A POSTROUTING -o $DEV1 -j SNAT --to-source $IP1
iptables -t nat -A POSTROUTING -o $DEV2 -j SNAT --to-source $IP2

iptables -t nat -A PREROUTING           -m state --state ESTABLISHED,RELATED          -j CONNMARK --restore-mark
iptables        -A OUTPUT               -m state --state ESTABLISHED,RELATED          -j CONNMARK --restore-mark
iptables -t nat -A PREROUTING -i $DEV1  -m state --state NEW                          -j CONNMARK --set-mark 1
iptables -t nat -A PREROUTING -i $DEV2  -m state --state NEW                          -j CONNMARK --set-mark 2
iptables -t nat -A PREROUTING           -m connmark --mark 1                          -j MARK --set-mark 1
iptables -t nat -A PREROUTING           -m connmark --mark 2                          -j MARK --set-mark 2
iptables -t nat -A PREROUTING           -m state --state NEW -m connmark ! --mark 0   -j CONNMARK --save-mark

iptables -t mangle -A PREROUTING -i $DEV2 -m state --state NEW -p tcp --dport  44447 -j CONNMARK --set-mark 2
iptables -t mangle -A PREROUTING -i $DEV2 -m state --state NEW -p udp --dport 44447 -j CONNMARK --set-mark 2

route del default
ip route del 0.0.0.0/1
ip route del 128.0.0.0/1
route add default gw $GW1 eth0

Eu levei em conta os comentários do autor original, modifiquei a minha configuração IP e as necessidades de porta ... estendi o sono para garantir que a configuração do OpenVPN tivesse ocorrido ... E também excluí duas rotas que acredito terem sido adicionadas por meu provedor de VPN para um fallback caso a rota padrão falhe ... Agora tudo parece ficar bem, exceto algumas coisas ...

1. traceroutes falham ... completamente ...

    $ traceroute yahoo.com
    traceroute to yahoo.com (206.190.36.45), 30 hops max, 60 byte packets
     1  * * *
     2  * * *
     3  * * *
     4  * * *
     5  * * *

2. ping resulta em 100% de perda de pacotes

    $ ping google.com
    PING google.com (173.194.43.46) 56(84) bytes of data.
    ^C
    --- google.com ping statistics ---
    119 packets transmitted, 0 received, 100% packet loss, time 118945ms

Eu não sei o que está causando isso ???

$ nslookup
> google.com
Server:     10.0.1.1
Address:    10.0.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 173.194.43.46
Name:   google.com
Address: 173.194.43.38
Name:   google.com
Address: 173.194.43.35
Name:   google.com
Address: 173.194.43.41
Name:   google.com
Address: 173.194.43.39
Name:   google.com
Address: 173.194.43.34
Name:   google.com
Address: 173.194.43.36
Name:   google.com
Address: 173.194.43.37
Name:   google.com
Address: 173.194.43.32
Name:   google.com
Address: 173.194.43.40
Name:   google.com
Address: 173.194.43.33

tabela de rotas abaixo:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         Rolands-AirPort 0.0.0.0         UG    0      0        0 eth0
default         Rolands-AirPort 0.0.0.0         UG    100    0        0 eth0
10.0.1.0        *               255.255.255.255 UH    0      0        0 eth0
10.0.1.0        *               255.255.255.0   U     0      0        0 eth0
10.4.0.1        10.4.49.21      255.255.255.255 UGH   0      0        0 tun0
10.4.49.21      *               255.255.255.255 UH    0      0        0 tun0
hosted-by.lease Rolands-AirPort 255.255.255.255 UGH   0      0        0 eth0

Qualquer ajuda seria muito apreciada!

    

Answer 1

Bem, eu tenho o meu trabalho em volta ... Eu não sei porque eu não fui capaz de fazer isso funcionar, mas basicamente o que eu descobri foi que mesmo com o meu roteamento configurado desta forma, a natureza do bittorrent levou meu ISP desde que o IP público seja anunciado ... o que é um grande problema para a conectividade. Para corrigir o meu problema, parei o daemon de transmissão e alterei o arquivo /etc/transmission-daemon/settings.json para ligar o endereço ipv4 da interface tun0. Esta não é uma solução ideal, pois não é dinâmica. No entanto, o endereço IP da minha VPN é estático o suficiente para que isso não seja um problema. Se alguém tiver uma resposta melhor, por favor me avise!

observe que os problemas de 100% de perda de pacotes com ping e sem traceroute disponíveis foram corrigidos removendo manualmente as rotas enviadas pelo provedor de VPN (dentro do script).

Forçar o tráfego de transmissão através da VPN foi uma questão de ajustar uma configuração dentro do cliente para ligar o endereço IP da interface tun0. Esta não é uma solução adequada, mas funciona, no entanto. Eu continuo usando o script para que a interface padrão não seja a VPN.