permite ssh de entrada com o cliente openvpn

Question

Eu configurei um cliente OpenVPN no meu roteador doméstico. No momento em que o túnel sobe, não consigo mais pingar meu roteador pela Internet usando seu WAN_IP. Eu gostaria de permitir certas conexões de entrada (ping, ssh) através da interface WAN enquanto o túnel vpn está ativo. Eu li um pouco sobre isso e entendo que preciso de roteamento baseado em origem.

Eu tentei implementar isso, mas não está funcionando. Aqui está o que eu fiz:

# ip rule list
0:      from all lookup local 
32765:  from all fwmark 0x1 lookup 128 
32766:  from all lookup main 
32767:  from all lookup default
# ip route list table 128
default via WAN_IP dev vlan2
# iptables -t mangle -nvL PREROUTING
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 CONNMARK   all  --  br0    *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore 
    0     0 CONNMARK   all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           CONNMARK set 0x1
# iptables -t mangle -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore

Meu pensamento foi o seguinte. Por favor, corrija-me se eu não entendi alguma coisa:

• Quando um pacote chega na vlan2 (a iface da WAN), PREROUTING: 2 define uma marca de conexão de 0x1
• O pacote não tem marca de pacote neste momento (está correto?)
• O pacote tem o roteador como destino, portanto ele será recebido. Se isso foi DNATed, o ponto anterior seria crucial porque a tabela 128 está faltando coisas da LAN.
• Um pacote de resposta é gerado localmente.
• OUTPUT: 1 definirá uma marca de pacote de 0x1 usando a marca de conexão no pacote de resposta
• PREROUTING: 1 faria o mesmo para conexões DNAT na LAN (br0)
• O pacote de resposta com a marca 0x1 será roteado usando a tabela 128.

Infelizmente isso não está funcionando e gostaria de entender por quê. De um servidor remoto, se eu fizer ping no WAN_IP, não vejo nenhuma resposta. Também ativei o acesso remoto ssh no roteador e não consigo abrir a porta do computador remoto com telnet WAN_IP SSH_PORT , portanto, isso não é apenas um problema icmp. Como alguém depura esses problemas?

Atualizar : eu verifiquei rp_filter e ele foi definido como 1. Eu tentei defini-lo como 0, e agora tudo funciona como esperado (2 não funcionou também). Como esse é um roteador voltado para a Internet, estou pensando que nenhum RPF pode não ser uma ótima ideia. Do pouco que eu entendo, quando RPF estrito é executado no pacote inicial, o kernel observa a rota de volta para REMOTE_IP é através de TUN_IF, enquanto o pacote chega em WAN_IF, então é descartado. Isto está certo? Eu tentei MARK set 0x1 && CONNMARK save como mangle PREROUTING, esperando que o kernel visse a marca durante o RPF, mas isso não acontece.

    

Answer 1

Não consigo ver por que você precisa usar o iptables para isso. Este é um caso simples de PBR. Configure duas tabelas de roteamento, a configuração main pelo OpenVPN e theother que não envolve a VPN, então adicione a regra

  ip rule from IP.Of.Your.Router table theother

e você está feito.

    

Answer 2

O problema é que o gateway padrão é alterado pelo OpenVPN e que interrompe qualquer conexão que esteja chegando na interface não-VPN. O Linux enviará respostas aos pacotes que chegaram na interface real da interface VPN! Você precisa configurar 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 a eth0 seja feita, mesmo que a eth0 não seja mais a interface de gateway padrão, os pacotes de resposta para a conexão voltarão à 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.