☰

Нет маршрута к хосту с маршрутизацией к интерфейсу для определенного порта

tag-icon • tag-icon iproute wireguard
Нет маршрута к хосту с маршрутизацией к интерфейсу для определенного порта

У меня есть сервер A с настроенным VPN-соединением с другим сервером B. В настоящее время сервер A может пинговать сервер B, используя адрес VPN 10.12.0.1.

Я хотел бы направить весь HTTPS-трафик через сервер B и разрешить остальному трафику использовать интерфейс по умолчанию.

Для этого я черпал вдохновение изэтот ответ unix stackexchangeи выполнили следующие команды:

# define route
echo "200 myroute" >> /etc/iproute2/rt_tables
# seems necessary
sysctl -w net.ipv4.conf.wg1.rp_filter=2
# actual routing
ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10
ip route add table 200 default via 10.12.0.1
# actual rule telling HTTPS traffic to use table 200
ip rule add iif lo ipproto tcp dport 443 lookup 200

Затем я запускаю curl https://1.1.1.1(или любой другой хост) и получаю ошибку Failed to connect to 1.1.1.1 port 443: No route to host. Когда я удаляю правило, все снова работает.

Полагаю, мой маршрут для таблицы 200 неверен, но он, похоже, совпадает с маршрутом из исходного ответа и маршрутом для интерфейса по умолчанию.

Знаете ли вы, как я могу исследовать и устранить проблему?

Спасибо

Дополнительная информация:

$ ip route show table 200
default via 10.12.0.1 dev wg1 
10.12.0.0/24 dev wg1 scope link src 10.12.0.10 

$ ip route show dev wg1
10.12.0.0/24 proto kernel scope link src 10.12.0.10

$ ip route get 1.1.1.1 ipproto tcp dport 443
1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001 
    cache 

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10 
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202

VPN — это Wireguard VPN. При настройке на маршрутизацию всего трафика через VPN все работает.

решение1

Ошибка "no route to host" скорее всего вызвана попыткой подключения к хосту ( 1.1.1.1), не включенному в настройки WireGuard AllowedIPs. Если вы используете wg-quick, сделайте следующее:

Какшаг 1в конфигурации WireGuard сервера A измените AllowedIPsнастройки в [Peer]разделе для сервера B, включив IP-адреса (или блоки IP-адресов), к которым вы хотите подключиться.

Вместо 1.1.1.1, предположим, что с сервера A вы хотели бы иметь возможность подключаться к любому HTTPS-серверу в блоке 192.0.2.0/24(и в частности, был сервер, 192.0.2.123с которым вы проводите тестирование). Предположим также, что вы изначально настроили свой AllowedIPsпараметр на сервере A для сервера B, чтобы включить 10.12.0.0/24блок. Измените этот параметр на следующий:

AllowedIPs = 10.12.0.0/24, 192.0.2.0/24

Избавьтесь от маршрутов и правил, которые вы ранее установили для таблицы 200 на сервере A, перезапустите WireGuard (например, sudo wg-quick down wg1; sudo wg-quick up wg1) и протестируйте это изменение, выполнив следующее:

$ curl -k https://192.0.2.123

Это должно, по крайней мере, помочь вам обойти ошибку "no route to host". Если вы все еще получаете ошибки только с этим, вам, вероятно, нужно настроить правила брандмауэра/маршрутизации на сервере B, чтобы разрешить ему пересылать пакеты с сервера A на 192.0.2.0/24.

Какшаг 2в [Interface]разделе конфигурации WireGuard сервера A добавьте следующую настройку:

Table = 200

Это заставит wg-quick добавлять маршруты, которые он создает автоматически, в вашу пользовательскую 200таблицу маршрутизации, а не в вашу основную таблицу. Перезапустите WireGuard еще раз и проверьте ваши таблицы маршрутизации:

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
$ ip route show table 200
10.12.0.0/24 dev wg1 scope link
192.0.2.0/24 dev wg1 scope link

Теперь добавьте специальное правило политики HTTPS:

$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200

И проверьте:

$ curl -k https://192.0.2.123

Какшаг 3Если вы по-прежнему хотите иметь возможность подключаться напрямую с сервера A к серверу B через WireGuard для служб, отличных от HTTPS (например, SSH и т. д.), добавьте еще одно правило политики на сервере A для всех подключений к блоку 10.12.0.0/24:

$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201

Теперь вы снова сможете использовать WireGuard для подключения с сервера A к серверу B:

$ ssh 10.12.0.1

Связанный контент