Блог

ip -4 rule add table main suppress_prefixlength 0 Эта команда появляется в процессе подключения к wireguard vpn.

Возможно, проще всего объяснить это с точки зрения трех потенциальных соображений маршрута для wireguard.

Когда вы создаете интерфейс wireguard, вы, очевидно, хотите, чтобы пакеты, идущие в диапазоны IP, к которым вы хотите получить доступ через wireguard, проходили через этот интерфейс. Итак, если вы получаете доступ, скажем, к 10.2.0.0 / 16 через wireguard на wg0, вы могли бы просто сделать ip route add 10.2.0.0/16 dev wg0 .

Это работает, если вы просто подключаетесь к частной сети. Но что, если вы хотите, чтобы все маршрутизировалось через wireguard, чтобы это был ваш маршрут по умолчанию? Это создает сложность, потому что, когда вы хотите, чтобы все маршрутизировалось через интерфейс wireguard, вы, очевидно, не хотите, чтобы собственные пакеты wireguard маршрутизировались через этот интерфейс; в противном случае они вообще никуда не уходили. Попробуйте ip route add 0.0.0.0/0 dev wg0 , и теперь ничего не получится: пакеты, передающие wg0, попытаются пройти через wg0. Вы могли бы добавить определенные маршруты к каждому узлу wireguard, но у вас может быть много одноранговых узлов wireguard, так что это было бы неудобно.

Вместо этого wg-quick использует метку брандмауэра (fwmark), чтобы маршрутизация могла распознавать пакеты для этого интерфейса и обрабатывать их по-разному. Установив что-то вроде wg setconf wg0 fwmark 51820 , wireguard может затем добавлять правила для обработки пакетов wireguard и пакетов, отличных от wireguard. по-разному. Затем он создает другую таблицу маршрутизации (например, 51820, которую вы можете видеть ip route list table 51820 ), через которую проходят пакеты, не относящиеся к wireguard, и направляет их все через wg0, в то время как пакеты wireguard проходят через основную таблицу (то, что вы видите с ip route list помощью ). Он использует правило (не из всех fwmark 0xca6c lookup 51820) для перенаправления всего, что не является пакетом wireguard, в таблицу 51820 (вы можете увидеть эти правила с ip rule помощью или ip -6 rule ).

Итак, почему from all lookup main suppress_prefixlength 0 ? Во многих случаях вам это на самом деле не нужно: пакеты wireguard будут перенаправляться в основную таблицу, а пакеты, не относящиеся к wireguard, будут перенаправляться в таблицу, созданную wg-quick. Но что, если ваша основная таблица маршрутизации — это не просто маршрут по умолчанию? Что, если вы добавили другие, более конкретные маршруты, возможно, для какой-то VPN с частным адресным пространством (причина, по которой мне просто нужно было выяснить, что сделала эта команда), или, может быть, для того, чтобы в первую очередь добраться до некоторых одноранговых узлов: может быть, они находятся на разных интерфейсах?

Чтобы охватить эти ситуации, эта третья команда добавляет правило, которое сначала проверяет, какой маршрут для любого пакета (из всех) будет в главной таблице (lookup main). Затем он видит, насколько специфичен этот маршрут, например, какова его длина префикса. Если оно равно 0 (т.Е. Маршрут по умолчанию, 0.0.0.0 / 0 или ::/ 0), он подавляет этот маршрут (suppress_prefixlength 0, который подавляет все, что имеет длину префикса его аргумента или меньше) и продолжает просмотр следующих правил. Если оно больше 0 (например, 10.1.0.0 / 16), то он использует этот маршрут.

Таким образом, в итоге вы получаете правила, похожие на эти ip rule list (досадно, что правило ip показывает метку прошивки как шестнадцатеричную, поэтому 0xca6c, в то время как wireguard устанавливает его как десятичную, поэтому 51820):

 32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
 

Основная таблица, которая может выглядеть примерно так ( ip route ):

 default via {gateway_ip} dev wlan0 proto dhcp metric 600
10.2.0.0/24 dev other_vpn proto kernel scope link src 10.2.0.210
 

И таблица «51820», которая выглядит следующим образом ( ip route list table 51820 ):

 default dev wg0 scope link
 

Итак, когда пакет проходит через эти правила и таблицы:

1. На 32764 мы переходим к главному столу.
   1. Если пакет отправляется, скажем, на 10.2.0.5, то он попадет на маршрут 10.2.0.0 / 24, и с префиксом 24 он отправится именно туда.
   2. Если, с другой стороны, соответствует умолчанию (0.0.0.0 / 0), то вместо перехода к gateway_ip в wlan0 он будет подавлен suppress_prefixlength 0 , и мы продолжим.
2. На 32765 мы проверяем отметку fw. Если это не 0xca6c (т. Е. Это не пакет, который wireguard отправляет для реализации wg0), тогда мы перейдем к таблице 51820. И это очень просто: все проходит через wg0.
3. Если fwmark равен 0xca6c, и, следовательно, это пакет wireguard, тогда мы перейдем к 32766. Это вернет нас к главной таблице, где, в данном случае, мы сопоставим маршрут по умолчанию, и пакеты wireguard будут отправляться через wlan0, как мы хотим: в конце концов, нам нужно использовать наше физическое соединение.