Хороший и сложный вопрос.
Во-первых, общий принцип: в таблицах маршрутизации, если у вас есть несколько правил, которые применяются к одному и тому же пункту назначения, используется наиболее конкретное правило . Например, глядя на ваш второй RT, предположим, что вы хотите пропинговать Google DNS 8.8.8.8. Применяются как первая, так и вторая строки, но первая строка немного более конкретна, поскольку имеет более ограничивающую маску, чем вторая: первая строка применяется ко всем IP-адресам в диапазоне
0.0.0.0 -> 127.255.255.255 в то время как второе правило применяется ко всем IP-адресам полной остановки, т. е. в диапазоне
0.0.0.0 -> 255.255.255.255 Следовательно, используется первое правило, которое является более узким / более ограничительным / более конкретным: пинг 8.8.8.8 должен проходить dev tun0через IP-адрес 10.172.1.5.
Второй момент: ваш второй RT содержит два одноадресных маршрута : они указаны Hв четвертом столбце. Наличие одноадресных маршрутов становится понятнее, если вместо устаревшей команды route/netstatиспользовать новую команду:
$ ip route show (что вы всегда должны делать), потому что здесь одноадресные маршруты обозначаются ссылкой области выражения .
Это ключ к пониманию (открытой) VPN-маршрутизации. В руководстве говорится:
область действия SCOPE_VAL
область назначения, охватываемая префиксом маршрута. SCOPE_VAL может быть числом или строкой из файла / etc / iproute2 / rt_scopes. Если этот параметр пропущен, ip предполагает глобальную область действия для всех шлюзовых маршрутов одноадресной передачи, ссылку области действия для прямых маршрутов одноадресной передачи и широковещания и хост области действия для локальных маршрутов.
Что такое одноадресный маршрут ?
Статический одноадресный маршрут - это настроенное вручную сопоставление IP-адреса с назначением следующего перехода, которое, следовательно, называется конкретным маршрутом назначения ... Добавьте статические маршруты, когда вы хотите вместо этого маршрутизировать трафик, предназначенный для конкретной сети / хоста, через другой следующий переход. маршрута по умолчанию.
Другими словами: если бы это правило не существовало, то, поскольку пинг 8.8.8.8 проходит через 10.172.1.5 (в вашем случае), но на tun0 нет шлюза по умолчанию, пакет будет передан в интерфейс eth0, где есть шлюз по умолчанию, и будет выходить из этого. Но это то, что происходит нормально, и у вас не будет (открытого) VPN. Вместо этого есть одноадресное правило, и оно настолько ограничительно, насколько это возможно: оно вынуждает вас, независимо от того, кому адресован пакет, связаться с 10.172.1.1 в качестве следующего перехода.
Хорошо, что теперь: как мы можем связаться с 10.172.1.1? dev tun0не имеет такого правила, поэтому пакет переносится eth0в надежде на удачу. Теперь, какое из оставшихся правил мы можем применить для пересылки нашего пакета ping? Дело в том, что eth0также есть одноадресный маршрут,
168.1.6.15 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1 что вынуждает его отправлять пакет в качестве следующего перехода на 168.1.6.15. И с тех пор это больше не наша ответственность.
Мы можем суммировать этот логический процесс следующим образом:
Пакет до 8.8.8.8 ---> dev tun0 ---> 10.172.1.5 ---> 168.1.6.15
(Rule #1) (Rule #3) (Rule #6)
Слабые концы :
Одно из оставшихся правил, правило № 5
128.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0 дополняет правило № 1
0.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0 Вместе они предоставляют правила по умолчанию для всех IP-адресов в мире, но, поскольку каждый из них несколько более строг, чем правило № 2
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1 они имеют приоритет над ним и используются для маршрутизации всего вашего интернет-трафика через OpenVPN. Фактически, вышеприведенное правило является избыточным, и оно было удалено в более старой версии OpenVPN. Но теперь он оставлен на месте, потому что он в основном никогда не вызывается, и это облегчает повторную установку RT # 1, когда OpenVPN сносится.
Правило № 7 является обычным правилом локальной сети. Вам не хватает правила, как
10.172.1.0/24 dev tun0 proto kernel scope link src 10.172.1.5 это то, что вам необходимо для связи с ПК в удаленной локальной сети. Скорее всего, это связано с тем, что вы используете в качестве сервера OpenVPN платный сервис, который не собирается предоставлять вам доступ к другим локальным машинам. Если бы вместо этого этот OpenVPN был тем, который вы подключаете к своей домашней локальной сети, например, в дороге, то вам определенно хотелось бы иметь возможность связываться с другими устройствами в вашей локальной сети, и у вас было бы одно такое правило.
Наконец, Правило № 4
10.172.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 совершенно загадочно для меня: у меня его нет ни в одном из моих (многочисленных) OpenVPN, и, насколько я понимаю, он мне кажется абсолютно ненужным.