Login SSH remoto não funciona

Question

Eu tenho um PC atrás de um roteador com porta de configuração de encaminhamento Port 22 para SSH que funciona perfeitamente - eu posso fazer o login e tudo mais. O que estou tentando fazer é deixar este PC se conectar a uma VPN e permitir apenas o tráfego na rede local ou através da conexão VPN (para acesso à Internet). Isso também está funcionando muito bem. Assim que a conexão VPN é interrompida, o PC não tem conexão com a Internet. Agora eu estou fazendo isso com IPTABLES, o problema é que eu não consigo obter entrada SSH para trabalhar a partir de fontes externas através do encaminhamento de porta do roteador. Eu sou capaz de SSH para o pc de dentro da rede local.

Veja o que tentei:

# Allow traffic to VPN SERVER
sudo iptables -A INPUT -s $REMOTE_IP -j ACCEPT

# Allow ssh traffic
iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT    
iptables -A OUTPUT -o eth1 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

# Allow local traffic.
sudo iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -s 172.16.0.0/12 -j ACCEPT
sudo iptables -A INPUT -s 192.168.0.0/16 -j ACCEPT

# Disallow everything else.
sudo iptables -A INPUT ! -i tun+ -j DROP

# Allow traffic from VPN SERVER.
sudo iptables -A OUTPUT -d $REMOTE_IP -j ACCEPT

# Allow local traffic.
sudo iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
sudo iptables -A OUTPUT -d 172.16.0.0/12 -j ACCEPT
sudo iptables -A OUTPUT -d 192.168.0.0/16 -j ACCEPT

# Disallow everything else.
sudo iptables -A OUTPUT ! -o tun+ -j DROP

sudo openvpn --config client.cfg --auth-user-pass client.cred --daemon

Aqui está minha saída iptables -vL -n: (substitui o servidor vpn por XX.XX.XX.XX)

Chain INPUT (policy ACCEPT 25674 packets, 4792K bytes)
 pkts bytes target     prot opt in     out     source               destination         
78848   11M ACCEPT     all  --  *      *       XXX.XXX.XXX.XXX      0.0.0.0/0           
 3176  318K ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW,ESTABLISHED 
    0     0 ACCEPT     all  --  *      *       10.0.0.0/8           0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       172.16.0.0/12        0.0.0.0/0           
 2517  231K ACCEPT     all  --  *      *       192.168.0.0/16       0.0.0.0/0           
   35 12374 DROP       all  --  !tun+  *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 32187 packets, 4374K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3681 2443K ACCEPT     tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0           tcp spt:22 state ESTABLISHED 
70697   10M ACCEPT     all  --  *      *       0.0.0.0/0            XXX.XXX.XXX.XXX      
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            10.0.0.0/8          
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.16.0.0/12       
   27  5787 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.0.0/16      
 2265  150K DROP       all  --  *      !tun+   0.0.0.0/0            0.0.0.0/0

E sim, se eu fizer um ifconfig, eu só tenho uma eth1 e não uma eth0, então não é isso.

Aqui também é a saída do netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         XX.XXX.242.128  128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth1
XX.XXX.193.107  192.168.1.1     255.255.255.255 UGH       0 0          0 eth1
XX.XXX.242.0    0.0.0.0         255.255.255.0   U         0 0          0 tun0
128.0.0.0       XX.XXX.242.128  128.0.0.0       UG        0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

    

Answer 1

Como penguin359 disse corretamente, o problema é que os pacotes de retorno serão roteados pela VPN, em vez de pelo roteador local, de onde veio a conexão de entrada. O SNAT no roteador é uma solução, mas se isso não for viável, você poderá usar o roteamento avançado em seu PC.

Você precisará adicionar essas regras avançadas de roteamento, além das regras existentes do iptables:

ip rule add from 192.168.1.X table 128
ip route add table 128 to 192.168.1.0/24 dev eth1
ip route add table 128 default via 192.168.1.1

Substitua 192.168.1.X pelo endereço IP da LAN do seu PC. 192.168.1.1 é o roteador da sua LAN e 192.168.1.0/24 é a sub-rede da sua LAN.

O primeiro comando cria uma regra que faz com que qualquer pacote com um endereço de origem de 192.168.1.X use uma tabela de roteamento especial que tenha o número 128. Os próximos dois comandos criam a tabela de roteamento 128, em que o gateway padrão é o seu roteador (e não o seu servidor VPN, como na tabela de roteamento principal).

Os únicos pacotes que terão um endereço de origem 192.168.1.X serão pacotes respondendo a conexões de entrada do seu roteador (isto é, conexões SSH encaminhadas pela porta) e pacotes destinados à sua LAN. Estes são exatamente os pacotes que você não quer usar sua VPN. Todos os outros pacotes de saída terão um endereço de origem diferente e usarão a tabela de roteamento principal que os encaminha pela sua VPN.

    

Answer 2

Para esclarecer, enquanto a VPN está em execução, o SSH de fontes externas está corrompido, mas antes de executar a VPN, o SSH de todas as fontes estava funcionando. O problema se resume à tabela de roteamento. Como você mostra acima, a rota padrão ( 0.0.0.0 ) vai para tun0 . Eu não entendo o que há com a divertida máscara de rede de 128.0.0.0 , mas isso faria com que qualquer endereço externo começando com 1-126 usasse tun0 . Não importa de onde os pacotes de entrada vêm para o SSH, os pacotes de saída só irão para onde corresponderem na tabela de roteamento. Eu fiz configurações extravagantes como esta eu mesmo. A solução padrão que eu uso para esse tipo de problema é usar regras SNAT de entrada que alteram o endereço de origem do pacote de entrada para o endereço IPv4 interno do roteador. Isso fará com que ele apareça como uma conexão interna com o PC e ele será roteado de volta para o roteador, já que ele reside em um destino local na tabela de roteamento acima. O roteador irá então inverter o SNAT e enviá-lo de volta para a natureza para ser detectado e cutucado por todos os hackers nefastos que estão por aí. Isto é SNAT deve existir como uma regra iptables no roteador, não no PC dentro da rede. Se você está apenas usando algo como um roteador Linksys WRT padrão, pode ser necessário instalar o OpenWRT ou similar nele para obter esse tipo de controle sobre a regra do firewall / NAT.