Это моя настройка ifconfig:
eth1 Link encap:Ethernet HWaddr 54:04:a6:49:99:16
inet addr:192.168.0.12 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::5604:a6ff:fe49:9916/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33325389 errors:0 dropped:0 overruns:0 frame:0
TX packets:19876569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:38511610122 (38.5 GB) TX bytes:5030880286 (5.0 GB)
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:1532251 errors:0 dropped:0 overruns:0 frame:0
TX packets:1532251 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:128544929 (128.5 MB) TX bytes:128544929 (128.5 MB)
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.6 P-t-P:10.8.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:113 errors:0 dropped:0 overruns:0 frame:0
TX packets:1663663 errors:0 dropped:489668 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:14523 (14.5 KB) TX bytes:1140762511 (1.1 GB)
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.9.0.6 P-t-P:10.9.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:1623870 errors:0 dropped:570939 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:828 (828.0 B) TX bytes:1130753499 (1.1 GB)
wlan0 Link encap:Ethernet HWaddr 00:21:00:e6:c8:aa
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Итак, у меня есть эта настройка IP-маршрутизации:
default via 192.168.0.1 dev eth1 proto static
10.8.0.0/24 via 10.8.0.5 dev tun0
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.9.0.0/24 via 10.9.0.5 dev tun1
10.9.0.5 dev tun1 proto kernel scope link src 10.9.0.6
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.12 metric 1
192.168.1.0/24 via 10.8.0.5 dev tun0
Работает как задумано. Я могу пинговать машины через оба туннеля (openvpn).
Однако когда я добавляю
sudo ip route add 0.0.0.0/1 via 10.9.0.5 dev tun1
sudo ip route add 128.0.0.0/1 via 10.9.0.5 dev tun1
все ломается. Я больше не могу пинговать машины через туннели.
Я действительно не понимаю, почему. Поскольку у меня есть маршрут с более высоким префиксом, определяемый как
10.8.0.0/24 via 10.8.0.5 dev tun0
почему новый маршрут с «нижним префиксом» не позволяет мне пинговать 10.8.0.1?
Для контекста я запускаю сервер openvpn, к которому этот клиент подключается и получает IP-адрес 10.8.0.6. После этого он подключается к другому серверу openvpn (10.8.0.10), который подключен к тому же «исходному» серверу (10.8.0.1). Первый сервер просто помещает меня в ту же подсеть, что и второй сервер (второй сервер не имеет статического IP-адреса и не может быть перенаправлен на порт). Два маршрута с низким префиксом, которые я добавляю, являются частью опции «redirect-gateway», поскольку я пытаюсь перенаправить весь трафик через второй сервер.
РЕДАКТИРОВАТЬ:
Добавляю все файлы конфигурации. (Я опущу нерелевантные настройки или настройки по умолчанию)
альфа server.conf
port 443
proto udp
dev tun
server 10.8.0.0 255.255.255.0
client-to-client
# broadcast beta's subnet
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
beta client.conf (используется для подключения к альфа-серверу)
client
dev tun
proto udp
remote [alpha IP] 443
beta server.conf (трафик должен проходить через этот сервер)
port 444
proto udp
dev tun
server 10.9.0.0 255.255.255.0
client-to-client
push "redirect-gateway local def1"
push "dhcp-option DNS 8.8.8.8"
основной альфа client.conf
client
dev tun
proto udp
remote [alpha IP] 443
основная бета client.conf
client
dev tun
proto udp
remote 10.8.0.10 444
РЕДАКТИРОВАТЬ 2:
Я попытался использовать обратный SSH-туннель на альфа-сервере вместо промежуточного сервера openvpn, но у меня возникла точно такая же проблема.
Я туннелировал из беты вот так
ssh -Nf -R \*:444:localhost:444 root@[alpha IP]
И изменил основной client.conf для подключения к [alpha IP]: 444 вместо 10.8.0.10.
Конфигурация отлично работала без шлюза перенаправления, но как только шлюз перенаправления добавил маршруты 0.0.0.0/1 и 128.0.0.0/1, я больше не мог пинговать никуда.
Вы маршрутизируете внешнюю конечную точку своих туннелей на адрес туннеля. Это не сработает. Если вы добавляете определенные маршруты для конечных точек туннеля через eth1, это работает.