Não é possível adicionar rota estática no meu Ubuntu, SIOCADDRT: A rede está inacessível

Question

Estou tentando adicionar uma rota estática no meu VPS a um cliente que está do outro lado do túnel VPN para o meu VPS e encaminha seu tráfego pelo túnel.

Esta é a configuração do meu destino para a qual estou planejando adicionar uma rota. O Raspi atua como um roteador que está conectado a um AP e o NAS está conectado ao Raspi e redireciona seu tráfego através do túnel VPN:

                                        +--------------------------------+
                                        |            Raspi               |
                      (192.168.0.101/24)|                                |(192.168.1.1/24)
 (192.168.0.1/24) AP<>=================={wlan0                       eth0}================<>NAS (192.168.1.102/24)
                                        |   \                        /   |
                                        |    +----------------------+    |
                                        |    |     iptables and     |    |
                                        |    |    routing engine    |    |
                                        |    +-----------+----------+    |
                                        |                |               |
                                        |             {tun0}             |
                                        |            10.8.0.6            |
                                        +--------------------------------+

Estou tentando fazer route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.6 , para me comunicar com meu NAS por trás do Raspi, mas recebo SIOCADDRT: Network is unreachable .

Estas são as informações do lado do servidor:

$ ifconfig -a

eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:217.B.C.D  Bcast:217.B.C.D  Mask:255.255.255.255
          inet6 addr: XXXX::XXX:XXXX:XXXX:XXXX/XX Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1598 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:176137 (176.1 KB)  TX bytes:165179 (165.1 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:460 (460.0 B)  TX bytes:460 (460.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:169 errors:0 dropped:0 overruns:0 frame:0
          TX packets:183 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:14825 (14.8 KB)  TX bytes:15071 (15.0 KB)

$ netstat -anr

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.255.255.1    0.0.0.0         UG        0 0          0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.255.255.1    0.0.0.0         255.255.255.255 UH        0 0          0 eth0

lista de rotas $ ip

default via 10.255.255.1 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
10.255.255.1 dev eth0  scope link

Informações adicionais:

Se você está se perguntando como eu obtive o redirecionamento de tráfego entre as interfaces, aqui está o meu post descrevendo como eu consegui tudo até este ponto usando o iptables:

Redirecionar o tráfego da interface de rede secundária junto com o encaminhamento de porta para tun0 (OpenVPN) usando o iptables

Bloco netwrok do cliente (no caso de topologia p2p ):

10.8.0.4 : Network address
10.8.0.5 : Virtual remote endpoint; Non pingable; Only used for routing
10.8.0.6 : Client IP address
10.8.0.7 : Network broadcast address

UPDATE 1:

Alterei a configuração do meu servidor VPN para topology subnet e ifconfig-push 10.8.0.6 255.255.255.0 no arquivo ccd correspondente para o cliente VPN para colocar o servidor e cliente VPN na sub-rede /24 em vez de /32 e, em seguida adicione as rotas. Desta vez, route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.6 ou route add -net 192.168.1.0 netmask 255.255.255.0 dev tun0 não retornou nenhum erro, mas ainda não há ping 192.168.1.102 . netstat -anr alterado (no caso de route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.6 ).

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.255.255.1    0.0.0.0         UG        0 0          0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
10.255.255.1    0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.1.0     10.8.0.6        255.255.255.0   UG        0 0          0 tun0

    

Answer 1

Eu li as instruções em:

link

E adicionei route 192.168.1.0 255.255.255.0 ao server.conf no meu VPS e também iroute 192.168.1.0 255.255.255.0 ao arquivo ccd correspondente para o cliente. E então eu usei o comando route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.6 e foi isso! Eu poderia pingar meu cliente 192.168.1.102 por trás do meu cliente OpenVPN do meu VPS: D

P.S: Ainda estou no modo subnet topology . Eu não tentei no normal p2p topology , mas acho que deve funcionar bem.

    

Answer 2

Para esclarecer um pouco, isso é algo que foi extremamente difícil para mim entender:

• Na máquina que está executando o software cliente OpenVPN, as rotas devem ser criadas pelo OpenVPN em resposta às diretivas route (no "i") em seu arquivo de configuração. Isso é para garantir que o tráfego seja roteado através do dispositivo virtual tunX e que o OpenVPN esteja ciente disso. Se o OpenVPN estiver agindo como um roteador para a sub-rede local à qual está conectado, as rotas serão necessárias para "capturar" o tráfego de entrada que está sendo "enviado para ele como um gateway" e fazer com que ele seja oferecido ao OpenVPN para entrega . (Se o sistema operacional não o rotear através desse dispositivo virtual, o OpenVPN nunca o verá.)
• Se o endereço de destino não é aquele que o OpenVPN já conhece ... é uma sub-rede remota diferente do endereço local em ambos os lados ... então iroute (com um "i") é necessário para informar OpenVPN da existência da sub-rede e para dizer para qual controle remoto enviar tráfego. (Se isso não acontecer, você verá no log do OpenVPN que ele descartou o pacote por essa mesma razão).
• Todo o roteamento de tráfego deve ser "como é feito para qualquer roteador TCP / IP". Cada e todo "hop" deve fazer a coisa certa. ( traceroute é seu amigo.) Além disso, o tráfego originado em em uma caixa que está executando um cliente OpenVPN será percebido como tendo um endereço IP distribuído pelo OpenVPN para essa finalidade, geralmente 10.8.0.x , então este intervalo de endereços deve ser roteado corretamente (em qualquer lugar ...) também. Se o túnel for conectado com sucesso, mas você não puder se comunicar, "você tem um problema de roteamento TCP / IP", da mesma forma que faria com qualquer outro tipo de dispositivo roteador.

Espero que esses comentários adicionais sejam úteis para você.