Что на самом деле означают записи в моей таблице маршрутизации?

Question

У меня есть VPN-соединение (реализовано через Open VPN), но я пытаюсь перенаправить трафик на определенные IP-адреса / домены вокруг него, поэтому они просто используют мое незащищенное интернет-соединение. По моим исследованиям, похоже, что лучший способ сделать это с помощью таблиц маршрутизации. Ни один из примеров, которые я нашел, не сработал, поэтому я хотел бы понять, что происходит для более эффективного устранения неполадок.

Когда я запускаю "route" с отключенным VPN, это выглядит довольно разумно:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     1      0        0 eth1

Я подозреваю, что первая строка задает поведение по умолчанию - мы направляемся через шлюз. Если пункт назначения находится где-нибудь в диапазоне 192.168.1. * / Моей внутренней сети, во второй строке указывается шлюз * (я полагаю, это означает использование значения по умолчанию из строки выше - но если бы у меня была сеть, охватывающая несколько октетов, я может использовать это для направления определенных блоков на определенные шлюзы).

Я ожидал, что когда я включу VPN, это останется примерно таким же, но мой шлюз для "по умолчанию" переключится на какой-то волшебный VPN IP.

Если это понимание верно, мне просто нужно добавить IP-адрес, который я хочу обойти VPN, в качестве пункта назначения, мой фактический маршрутизатор (192.168.1.1) в качестве шлюза, и все будет работать хорошо (если синтаксис для этого прост, я бы люблю это видеть).

Однако, как только я включаю VPN, все становится беспорядочным, и я начинаю сомневаться в своих знаниях:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      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
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
168.1.6.15      192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth1

Что здесь происходит? Может кто-нибудь объяснить, что это за дополнительные строки и почему они появляются / исчезают, когда я переключаю vpn?

Спасибо за любые предложения! Я встречал несколько статей "что такое таблица маршрутизации", но я думаю, что они написаны для людей, намного умнее меня - я все еще очень плохо знаком с Linux и хотел бы получить совет от идиота :)

Answer 1

Хороший и сложный вопрос.

Во-первых, общий принцип: в таблицах маршрутизации, если у вас есть несколько правил, которые применяются к одному и тому же пункту назначения, используется наиболее конкретное правило. Например, глядя на ваш второй 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, и, насколько я понимаю, он мне кажется абсолютно ненужным.