ЕЩЁ ОДИН САЙТ ДЛЯ СИСТЕМНЫХ АДМИНИСТРАТОРОВ Основы маршрутизации wireguard
Введение
Теперь, когда мы научились настраивать wireguard на разных операционных системах, давайте сделаем паузу и разберёмся, как работа wireguard влияет на вашу таблицу маршрутизации.
Основы маршрутизации wireguard
Самое важное понять: вы не настраиваете маршруты через wireguard напрямую — маршруты задаёт параметр AllowedIPs для каждого пиринга! Это влечёт за собой несколько последствий:
- Эти маршруты всегда присутствуют в таблице маршрутизации, даже если пиринг недоступен.
- Если вы разрешаете трафик из диапазона IP через wireguard, то весь трафик к этому диапазону тоже пойдёт через wireguard.
Это обычно вполне логично и удобно, но может создавать неудобства, если вы хотите:
- перенаправить весь интернет-трафик через wireguard;
- обеспечить резервирование доступа к удалённому хосту через несколько пирингов wireguard;
- маршрутизировать весь трафик, направленный в интернет.
Самая простая схема
Рассмотрим два хоста и две сети на схеме:
Простая схема
Первая сеть — физическая, соединяет eth0 интерфейсы двух хостов с подсетью 192.168.1.0/24. Вторая сеть — виртуальная, соединяет интерфейсы wireguard wg0 на двух хостах с подсетью 10.1.2.0/24.
Первый хост — Dalinar, с физическим интерфейсом eth0 и IP-адресом 192.168.1.10/24. Настроим wireguard с IP 10.1.2.1/24, приватным ключом kIrQqJA1kEX56J9IbF8crSZOEZQLIAywjyoOqmjzjHU= и публичным ключом zfxxxWIMFYbEoX55mXO0gMuHk26iybehNR9tv3ZwJSg=.
Второй хост — Kaladin, с физическим интерфейсом eth0 и IP 192.168.1.20/24. Настроим wireguard с IP 10.1.2.2/24, приватным ключом SIg6cOoTyJRGIYSZ9ACRryL182yufKAtTLHK/Chb+lo= и публичным ключом BN89Ckhy4TEHjy37zz/Mvi6cOksnKzHHrnHXx5YkMlg=.
Конфигурация wireguard
Конфигурация Dalinar выглядит так:
[Interface]
PrivateKey = kIrQqJA1kEX56J9IbF8crSZOEZQLIAywjyoOqmjzjHU=
ListenPort = 342
Address = 10.1.2.1/32
[Peer]
PublicKey = BN89Ckhy4TEHjy37zz/Mvi6cOksnKzHHrnHXx5YkMlg=
Endpoint = 192.168.1.20:342
AllowedIPs = 10.1.2.2/32
Конфигурация Kaladin выглядит так:
[Interface]
PrivateKey = SIg6cOoTyJRGIYSZ9ACRryL182yufKAtTLHK/Chb+lo=
ListenPort = 342
Address = 10.1.2.2/32
[Peer]
PublicKey = zfxxxWIMFYbEoX55mXO0gMuHk26iybehNR9tv3ZwJSg=
Endpoint = 192.168.1.10:342
AllowedIPs = 10.1.2.1/32
Важные моменты
Обратите внимание на маски подсети в Address и AllowedIPs — нигде нет /24! Я сделал так потому что:
- wireguard это не требует;
- было бы запутанно с несколькими пирингами;
- лучше держать таблицу маршрутизации максимально чистой.
Можно было бы использовать маску /24 для Address — это бы работало и выглядело привычно, так как обычно сетевые устройства делают. Но я не использую /24, чтобы не создавать маршрут к интерфейсу wg0 с маской /24 без следующего перехода. Он будет нужен, когда мы в следующей статье добавим удалённый хост в конфигурацию.
Для AllowedIPs можно было бы поставить /24, но это сработало бы только в этом конкретном случае. Если добавить несколько пирингов — конфигурация сломается.
Главный вывод: в отличие от других VPN или традиционного сетевого администрирования, где мы привыкли, что хосты логически принадлежат одной сети, например 10.1.2.0/24, это совершенно не обязательное условие для wireguard. Можно использовать 10.1.2.1 для wg0 Dalinar и 172.16.0.1 для wg0 Kaladin — при этом всё будет работать точно так же, разница будет только в IP.
Пусть это усвоится.
Таблицы маршрутизации
С этой настройкой, если Dalinar работает на Linux, его таблица маршрутизации (ip -4 r) будет выглядеть так:
10.1.2.2 dev wg0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 600
Таблица Kaladin будет очень похожей:
10.1.2.1 dev wg0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20 metric 600
Wireguard routing part two
Введение
Теперь, когда мы научились настраивать wireguard на разных операционных системах, давайте сделаем паузу и разберёмся, как работа wireguard влияет на вашу таблицу маршрутизации.
Основы маршрутизации wireguard
Самое важное понять: вы не настраиваете маршруты через wireguard напрямую — маршруты задаёт параметр AllowedIPs для каждого пиринга! Это влечёт за собой несколько последствий:
- Эти маршруты всегда присутствуют в таблице маршрутизации, даже если пиринг недоступен.
- Если вы разрешаете трафик из диапазона IP через wireguard, то весь трафик к этому диапазону тоже пойдёт через wireguard.
Это обычно вполне логично и удобно, но может создавать неудобства, если вы хотите:
- перенаправить весь интернет-трафик через wireguard;
- обеспечить резервирование доступа к удалённому хосту через несколько пирингов wireguard;
- маршрутизировать весь трафик, направленный в интернет.
Самая простая схема
Рассмотрим два хоста и две сети на схеме:
Простая схема
Первая сеть — физическая, соединяет eth0 интерфейсы двух хостов с подсетью 192.168.1.0/24. Вторая сеть — виртуальная, соединяет интерфейсы wireguard wg0 на двух хостах с подсетью 10.1.2.0/24.
Первый хост — Dalinar, с физическим интерфейсом eth0 и IP-адресом 192.168.1.10/24. Настроим wireguard с IP 10.1.2.1/24, приватным ключом kIrQqJA1kEX56J9IbF8crSZOEZQLIAywjyoOqmjzjHU= и публичным ключом zfxxxWIMFYbEoX55mXO0gMuHk26iybehNR9tv3ZwJSg=.
Второй хост — Kaladin, с физическим интерфейсом eth0 и IP 192.168.1.20/24. Настроим wireguard с IP 10.1.2.2/24, приватным ключом SIg6cOoTyJRGIYSZ9ACRryL182yufKAtTLHK/Chb+lo= и публичным ключом BN89Ckhy4TEHjy37zz/Mvi6cOksnKzHHrnHXx5YkMlg=.
Конфигурация wireguard
Конфигурация Dalinar выглядит так:
[Interface]
PrivateKey = kIrQqJA1kEX56J9IbF8crSZOEZQLIAywjyoOqmjzjHU=
ListenPort = 342
Address = 10.1.2.1/32
[Peer]
PublicKey = BN89Ckhy4TEHjy37zz/Mvi6cOksnKzHHrnHXx5YkMlg=
Endpoint = 192.168.1.20:342
AllowedIPs = 10.1.2.2/32
Конфигурация Kaladin выглядит так:
[Interface]
PrivateKey = SIg6cOoTyJRGIYSZ9ACRryL182yufKAtTLHK/Chb+lo=
ListenPort = 342
Address = 10.1.2.2/32
[Peer]
PublicKey = zfxxxWIMFYbEoX55mXO0gMuHk26iybehNR9tv3ZwJSg=
Endpoint = 192.168.1.10:342
AllowedIPs = 10.1.2.1/32
Важные моменты
Обратите внимание на маски подсети в Address и AllowedIPs — нигде нет /24! Я сделал так потому что:
- wireguard это не требует;
- было бы запутанно с несколькими пирингами;
- лучше держать таблицу маршрутизации максимально чистой.
Можно было бы использовать маску /24 для Address — это бы работало и выглядело привычно, так как обычно сетевые устройства делают. Но я не использую /24, чтобы не создавать маршрут к интерфейсу wg0 с маской /24 без следующего перехода. Он будет нужен, когда мы в следующей статье добавим удалённый хост в конфигурацию.
Для AllowedIPs можно было бы поставить /24, но это сработало бы только в этом конкретном случае. Если добавить несколько пирингов — конфигурация сломается.
Главный вывод: в отличие от других VPN или традиционного сетевого администрирования, где мы привыкли, что хосты логически принадлежат одной сети, например 10.1.2.0/24, это совершенно не обязательное условие для wireguard. Можно использовать 10.1.2.1 для wg0 Dalinar и 172.16.0.1 для wg0 Kaladin — при этом всё будет работать точно так же, разница будет только в IP.
Пусть это усвоится.
Таблицы маршрутизации
С этой настройкой, если Dalinar работает на Linux, его таблица маршрутизации (ip -4 r) будет выглядеть так:
10.1.2.2 dev wg0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 600
Таблица Kaladin будет очень похожей:
10.1.2.1 dev wg0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20 metric 600
Wireguard routing part two
