Regras de IP e Confusão de Tabelas

1

Depois de usar o openVPN, tenho um novo dispositivo TUN. Também segui algumas etapas on-line para permitir transmissões de entrada para o meu servidor, no entanto, não entendo como está funcionando.

ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:e2:97:22 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.129/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::de8d:8f16:39a0:8bb9/64 scope link 
       valid_lft forever preferred_lft forever

3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:b7:c2:77 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6877:4a6e:7067:da26/64 scope link tentative 
       valid_lft forever preferred_lft forever

4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.8.118 peer 10.8.8.117/32 scope global tun0
       valid_lft forever preferred_lft forever

regras de ip:

0:  from all lookup local 
32765:  from 192.168.0.129 lookup 128 
32766:  from all lookup main 
32767:  from all lookup default

128 tabelas:

default via 192.168.0.1 dev eth0 
10.8.8.117 dev eth0  scope link 

tabela principal:

0.0.0.0/1 via 10.8.8.117 dev tun0 
default via 192.168.0.1 dev eth0  metric 202 
10.8.8.1 via 10.8.8.117 dev tun0 
10.8.8.117 dev tun0  proto kernel  scope link  src 10.8.8.118 
128.0.0.0/1 via 10.8.8.117 dev tun0 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.129  metric 202 
198.148.86.170 via 192.168.0.1 dev eth0 

tabela local:

local 10.8.8.118 dev tun0  proto kernel  scope host  src 10.8.8.118 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.0.0 dev eth0  proto kernel  scope link  src 192.168.0.129 
local 192.168.0.129 dev eth0  proto kernel  scope host  src 192.168.0.129 
broadcast 192.168.0.255 dev eth0  proto kernel  scope link  src 192.168.0.129 

Alguém pode explicar que rota um pacote levaria através disso? Estou principalmente confuso sobre a Tabela 128. Sem essa regra e tabela, não consigo conectar-me ou conectar-me ao servidor da minha máquina fora de nossa rede quando a VPN está em execução. Como adicionar essas duas regras me permite fazer isso? O que eles estão dizendo?

    
por jeebs 12.01.2017 / 18:20

1 resposta

0

Em um mundo sem NAT, sem firewalls com informações de estado e com cada interface tendo endereços com IPs publicamente roteáveis, isso não seria necessário. Mas nós não vivemos nesse mundo. Vivemos em um mundo onde uma conexão típica geralmente passa por vários firewalls e dispositivos NAT.

Basicamente, você está tendo um problema de roteamento assimétrico .

Asymmetric routing is not a problem by itself, but will cause problems when Network Address Translation (NAT) or firewalls are used in the routed path.

Quando um dispositivo cliente faz uma conexão ssh com seu host, ele terá o ip / porta de destino ip / porta src nos cabeçalhos tcp / ip. Os pacotes de resposta terão o ip / porta src da interface do ssh que será usada para responder e o endereço / porta de destino do host remoto. No seu exemplo aqui, você tem duas maneiras que os pacotes recebidos podem chegar até você, e a rota de saída padrão é diferente do endereço de entrada que será usado. Sem as regras adicionadas, o pacote de resposta é enviado, ele terá um ip / porta src diferente do que o firewall do cliente ssh estava esperando com base no que foi usado com o pacote de saída que foi enviado. Como o destino no pacote de saída não é o mesmo da fonte na resposta, ele pode ser rejeitado por um firewall ou pode não corresponder a algo em sua tabela de estado NAT.

As regras que você coloca em prática basicamente forçam o sistema de entrada a responder a partir da interface na qual ele recebeu a solicitação, significando que todos os endereços corresponderão corretamente, e os pacotes serão permitidos através de qualquer firewall.

    
por 12.01.2017 / 19:41