Permitindo o SSH em um servidor com um cliente OpenVPN ativo

Question

Eu tenho um VPS rodando o CentOS 7 ao qual me conecto com o SSH. Eu gostaria de executar um cliente OpenVPN no VPS para que o tráfego da Internet seja roteado através da VPN, mas ainda permitir que eu me conecte ao servidor via SSH. Quando eu inicio o OpenVPN, minha sessão SSH é desconectada e não consigo mais me conectar ao meu VPS. Como posso configurar o VPS para permitir que as conexões SSH (porta 22) de entrada sejam abertas no IP real do VPS (104.167.102.77), mas ainda direcionar o tráfego de saída (como de um navegador da Web no VPS) através da VPN? p>

O serviço OpenVPN que uso é o PrivateInternetAccess, e um exemplo do arquivo config.ovpn é:

client
dev tun
proto udp
remote nl.privateinternetaccess.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.pem

ip addr do VPS:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens33:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:be:16:f7 brd ff:ff:ff:ff:ff:ff
    inet 104.167.102.77/24 brd 104.167.102.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:febe:16f7/64 scope link
       valid_lft forever preferred_lft forever
4: tun0:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.172.1.6 peer 10.172.1.5/32 scope global tun0
       valid_lft forever preferred_lft forever

Roteador IP do VPS:

0.0.0.0/1 via 10.172.1.5 dev tun0
default via 104.167.102.1 dev ens33  proto static  metric 1024
10.172.1.1 via 10.172.1.5 dev tun0
10.172.1.5 dev tun0  proto kernel  scope link  src 10.172.1.6
104.167.102.0/24 dev ens33  proto kernel  scope link  src 104.167.102.77
109.201.154.177 via 104.167.102.1 dev ens33
128.0.0.0/1 via 10.172.1.5 dev tun0

    

Answer 1

Estou tendo um problema parecido com isso e estou tentando corrigir o problema descrito em este post no fórum .

A ideia é que, atualmente, quando você se conecta ao seu endereço IP público, os pacotes de retorno estão sendo roteados pela VPN. Você precisa forçar esses pacotes a serem roteados pela sua interface pública.

Estes comandos de rota farão o seguinte:

ip rule add from x.x.x.x table 128

ip route add table 128 to y.y.y.y/y dev ethX

ip route add table 128 default via z.z.z.z

Onde x.x.x.x é seu IP público, y.y.y.y / y deve ser a sub-rede de seu endereço IP público, ethX deve ser sua interface pública de Ethernet e z.z.z.z deve ser o gateway padrão.

Note que isso não funcionou para mim (usando o Debian e o PrivateInternetAccess), mas pode ajudá-lo.

    

Answer 2

Isso pode ser um pouco tarde, mas ...

O problema é que o gateway padrão é alterado pelo OpenVPN, e isso quebra sua conexão SSH atual, a menos que você configure as rotas apropriadas antes de iniciar o OpenVPN.

O que segue funciona para mim. Ele usa iptables e ip (iproute2). Abaixo, é assumido que a interface de gateway padrão antes de o OpenVPN ser iniciado é "eth0". A idéia é garantir que quando uma conexão com eth0 é feita, mesmo que eth0 não seja mais a interface de gateway padrão, os pacotes de resposta para a conexão retornam a eth0 novamente.

Você pode usar o mesmo número para a marca de conexão, marca de firewall e tabela de roteamento. Eu usei números distintos para tornar as diferenças entre eles mais aparentes.

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412

===

ATUALIZAÇÃO:

O acima funciona bem para mim no Debian Jessie. Mas em um sistema Wheezy mais antigo acabei de descobrir que preciso adicionar "via" à entrada da tabela de roteamento:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412

Existe "12.345.67.89" que deve ser o gateway não-VPN original.

    

Answer 3

Com base na resposta do @MrK, escrevi aqui alguns códigos simples para tornar mais rápido o trabalho, para que você não precise verificar interfaces / IP:

ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')

Eu testei este script em 4 dos meus VPS e está funcionando perfeitamente.

    

Answer 4

hmm soa como sobreposição de sub-redes ip .... sem saber mais sobre o seu esquema ip, além do ip público para o seu vnn ternmination como nl.privateinternetaccess.com, não é possível dizer com certeza.

assim, por exemplo, se a sub-rede remota do outro lado do nl.privateinternetaccess.com for 10.32.43.0/24, e sua instância estiver em um aws vpc cuja sub-rede é 10.32.44.0/24. mas seu cliente de ssh de origem mora em 10.32.43.0/24 (seu lado de aws vpc), ele não funcionará, já que o tráfego de retorno ssh será empurrado erroneamente sobre vpn para a holanda.

forneça informações completas de ip / sub-rede para mais ajuda com isso.

...

ok, então ... parece que sua rota padrão está no túnel, depois que você se conecta a nl:

0.0.0.0/1 via 10.172.1.5 dev tun0

para que você possa mudar isso depois de se conectar. Muitas vezes os servidores vpn lhe dão rotas falsas. especialmente no corpo desleixado. neste caso, eles estão empurrando uma rota padrão para você, então todo o tráfego da caixa vps vai para nl. altere a rota padrão para 104.167.102.x ou qualquer que seja o seu gateway de sub-rede em seu provedor vps.

    

Answer 5

Quando você aumenta a VPN, seu gateway padrão é substituído. Isso significa que qualquer tráfego gerado ou encaminhado através de sua caixa será encaminhado para o gateway da VPN.

Uma solução simples é filtrar todo o tráfego que você não deseja rotear através da VPN e fazer outra coisa com ele. Uma possibilidade é pegar o tráfego gerado na sua caixa com o seu endereço de origem local e encaminhá-lo através do seu gateway local. Isso permite que serviços como o SSH funcionem corretamente.

Faremos isso aqui. Primeiro, crie uma nova tabela de roteamento e adicione uma rota padrão que roteie tudo pelo seu gateway local:

# <table> is any number between 2 and 252.
# Check /etc/iproute2/rt_tables for more info.
ip route add default via <gateway> table <table>
ip route add <lan-addr> dev <device> table <table>

Em seguida, crie uma nova regra de filtro de pacotes que marque todo o tráfego que sai de sua caixa de um determinado endereço de origem com algum identificador.

# <mark> is any number.
iptables -tmangle -AOUTPUT -s<local-addr> -jMARK --set-mark <mark>

Por fim, crie uma política de roteamento que escolha todo o tráfego marcado acima e o direcione usando a tabela gerada acima.

ip rule add fwmark <mark> table <table>

Mais uma vez, os valores de <mark> e <table> são identificadores arbitrários de sua própria escolha.

    

Answer 6

Para mim, com a execução do servidor OpenVPN no pfSense, fui desmarcar a configuração "Forçar todo o tráfego IPv4 gerado pelo cliente pelo túnel".