Ubuntu, две сетевухи, два разных провайдера
Хочу настроить сервак с двумя разными интернет провайдерами. На машине стоит Ubuntu 20.04 и две сетевухи подключённые к двум разным ISP1 и ISP2 через разные роутеры. Каждая сетевуха в своей подсети — 192.168.2.2/30 и 192.168.3.2/30 соответственно.
Был куплен домен на reg.ru и у него были прописанны два IP от ISP1 и ISP2. Проблема в том, что машина доступна или через одну сетевуху или через другую. Нельзя одновременно пинговать оба IP адреса или обращаться по домену на разные сетевухи (reg.ru использует что-то типа round-robin). Всегда одна из сетевух не отвечает.
Если я пингую сетевуху 1 и она успешно отвечает то сайт запущенный на этом серваке успешно открывается через IP этой сетевухи. Если я пингую другую сетевуху и она не отвечает то сайт не открывается.
Wireshark показывает, что «рабочая» в данный момент сетевуха если её пинговать отвечает в ответ, но что интересно «не рабочая» сетевуха если её пинговать получает пакеты и даже на них отвечает, но они не приходят. Похоже что-то с роутингом или т.п. На машине есть два дефолтных гейтвея т.е. с виду всё нормально. Тема немного пересекается с https://askubuntu.com/questions/1211096/two-network-cards-which-provides-internet Но я не спец по Linux и не могу сам разобраться, как это настроить.
Вопрос, кто нибудь смог заставить одновременно работать две сетевухи? И как это можно сделать?
Вопрос, кто нибудь смог заставить одновременно работать две сетевухи? И как это можно сделать?
Определитесь с рутинг полиси (чего куда хочется), потом настраивайте.
Это ответ типа — лучше быть богатым и здоровым чем бедным и больным. Вы бы ещё написали — разберитесь, как настраивать и настройте как вам нужно.
По роутинг полиси там всё нормально. Нет вообще ничего в роутинге, что могло бы мешать работать так, как задумано.
У всех все работает. Очевидно что надо не прозой описывать, а роутпринт смотреть, трэйсрт и потобными утилитами смотреть.
Будьте здоровы. Ну и почитайте на досуге, например man ip-rule — routing policy database managemen .
Примеров в интернете полно, ибо это самая стандартная ситуация.
Примеров в интернете полно, ибо это самая стандартная ситуация.
Ссылку можно хотя бы на один пример? Всё что лежит в интернете не работает.
Ссылку можно хотя бы на один пример? Всё что лежит в интернете не работает.
Ну, искать надо тренироваться. 🙂
Там все просто. Узел называется по нашему «ёжик» 🙂
Вам не обязательно настраивать два правила и две таблицы. Достаточно оставить одну для одного интерфейса, второй интерфейс будет работать через основную конфигурацию.
Захотите обсудить тему «что там делается», дайте знать.
«не рабочая» сетевуха если её пинговать получает пакеты и даже на них отвечает, но они не приходят.
Потому, что операторы последней мили, как правило, не пропускают пакеты с чужими src ip, а пакет пытается уйти на default gw. Способ борьбы с этим подсказали уже.
Ещё просто в Linux есть rp_filter, может даже к оператору и не уходит.
reg.ru использует что-то типа round-robin
Нет, это не reg.ru использует. reg.ru никак не может влиять на то, что отдаёт твой DNS (ну или провайдера). round-robin — это стандартное поведение любого нормального DNS.
Так как что-то, всё же, работает, полагаю, что речь не про эти адреса на самом деле?
Дело даже не в чужом src. Удалённый хост зовёт Васю из первого подъезда, а ему вместо этого отзывается Коля из второго. Естественно, что оно так не работает.
Выше Oleg_Iu правильную ссылку дал.
Удалённый хост зовёт Васю из первого подъезда, а ему вместо этого отзывается Коля из второго.
Нет, как раз Вася и отзывается, только выйти не через свой подъезд пытается, а через Колин. Я об этом.
Вася и Коля — это eth. Что у них у обоих один и тот же номер Комсомольской правды в руках лежит — фиолетово.
Чтобы из eth1 ушёл пакет с адресом eth0, это нужно специально настраивать.
По-дефолту сервер поставит исходящему пакету в src адрес интерфейса с которого пакет уйдёт.
Судя по описанию, у него шлюзом по-умолчаню висит eth0, а defgw via eth1 у него или отсутствует, или не активен, т.к. имеется более приоритетный маршрут через eth0. Скорее второе.
И у него там, похоже, ещё два роутера стоят, у которых в NAT прописаны соответствующие локальным подсетям роутеров адреса сервера.
Так что даже если он научит Васю через общий балкон выходить из чужого подъезда, ему это всё-равно не поможет.
Правильно — отвечать в тот же интерфейс, откуда запрос поступил, если клиент не ожидает иного.
Так что ссылка таки правильная.
Чтобы из eth1 ушёл пакет с адресом eth0, это нужно специально настраивать.
Совсем нет. Надо всего лишь default gw через eth1, если не использовать source policy routing.
По-дефолту сервер поставит исходящему пакету в src адрес интерфейса с которого пакет уйдёт.
Нет. По дефолту сервер (точнее не сервер, а приложение) поставит исходящему пакету в src адрес, на который пришёл запрос. Это вот если это не ответ на запрос, то да, тогда адрес интерфейса, с которого пакет уйдёт.
Правильно — отвечать в тот же интерфейс, откуда запрос поступил,
Это так не работает, если специально не настраивать.
Откуда ты можешь знать ожидание клиента, который не известно кто и не известно где?
AS ★★★★★ ( 30.06.21 10:36:56 MSK )
Последнее исправление: AS 30.06.21 10:39:55 MSK (всего исправлений: 3)
По дефолту сервер (точнее не сервер, а приложение) поставит исходящему пакету в src адрес
А, кажется, да… я тупанул, мозг не ту диаграмму подсунул в память.
Откуда ты можешь знать ожидание клиента, который не известно кто и не известно где?
Если клиент не сказал, что примет ответ на этот адрес и порт от любого, то воспринимать как «жду ответ оттуда же, куда спросил».
mogwai ★★★★ ( 30.06.21 11:32:18 MSK )
Последнее исправление: mogwai 30.06.21 11:33:49 MSK (всего исправлений: 1)
user@user-desktop:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens2: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 76:7c:26:8d:f2:2b brd ff:ff:ff:ff:ff:ff altname enp1s0 inet 192.168.2.2/30 brd 192.168.2.3 scope global noprefixroute ens2 valid_lft forever preferred_lft forever 3: enp5s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 7a:05:ae:b5:d6:cd brd ff:ff:ff:ff:ff:ff inet 192.168.3.2/30 brd 192.168.3.3 scope global noprefixroute enp5s0 valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:04:48:d3:22 brd ff:ff:ff:ff:ff:ff user@user-desktop:~$ route -n Таблица маршутизации ядра протокола IP Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 ens2 0.0.0.0 192.168.3.1 0.0.0.0 UG 101 0 0 enp5s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 ens2 192.168.2.0 0.0.0.0 255.255.255.252 U 100 0 0 ens2 192.168.3.0 0.0.0.0 255.255.255.252 U 101 0 0 enp5s0 user@user-desktop:~$ ip route default via 192.168.2.1 dev ens2 proto static metric 100 default via 192.168.3.1 dev enp5s0 proto static metric 101 169.254.0.0/16 dev ens2 scope link metric 1000 192.168.2.0/30 dev ens2 proto kernel scope link src 192.168.2.2 metric 100 192.168.3.0/30 dev enp5s0 proto kernel scope link src 192.168.3.2 metric 101 Потому, что операторы последней мили, как правило, не пропускают пакеты с чужими src ip, а пакет пытается уйти на default gw.
Ещё просто в Linux есть rp_filter, может даже к оператору и не уходит.
net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 Нет, это не reg.ru использует. reg.ru никак не может влиять на то, что отдаёт твой DNS
Я использую DNS reg.ru, у них есть бесплатные DNS для тех кто купил домен у них. Они периодически меняют местами положение IP при выдаче nslookup т.е. получается round robin.
Так как что-то, всё же, работает, полагаю, что речь не про эти адреса на самом деле?
Конечно. Cервак к обоим ISP подключен через отдельный роутер т.е. схема такая
ISP1---[router 1]---[server]----[router 2]---ISP2 У одного ISP IP начинается на 178, у другого на 77.
Дело даже не в чужом src. Удалённый хост зовёт Васю из первого подъезда, а ему вместо этого отзывается Коля из второго. Естественно, что оно так не работает.
Нет. Удалённый хост зовёт Васю и Вася или не отвечает или отвечает, но ответы не приходят (последнее точно имеет место с роутером 1, про второй роутер не могу сказать т.к. он сам на пинги отвечает, это не отключается, точнее смогу сказать позже). Коля вместо Васи не отвечает.
Нет, как раз Вася и отзывается, только выйти не через свой подъезд пытается, а через Колин. Я об этом.
Судя по wireshark пинги приходят к Васи, а Вася не отвечает
37 13.312055861 123.27.01.68 192.168.2.2 ICMP 98 Echo (ping) request seq=62/15872, ttl=53 (no response found!) 38 14.335995807 123.27.01.68 192.168.2.2 ICMP 98 Echo (ping) request seq=63/16128, ttl=53 (no response found!) 39 15.359980098 123.27.01.68 192.168.2.2 ICMP 98 Echo (ping) request seq=64/16384, ttl=53 (no response found!) 40 16.384039643 123.27.01.68 192.168.2.2 ICMP 98 Echo (ping) request seq=65/16640, ttl=53 (no response found!) Коля при этом вообще ничего не делает.
Используем 2+ провайдера (первая часть)
Здесь я хочу рассказать о настройке шлюза на Linux’e, для использования 2-х (и более) провайдеров интернета.
Для настройки мы будем использовать возможности iptables и утилиты ip из пакета, который как правило называется iproute2. А для решения поставленной задачи пакеты мы будем маршрутизировать на основе «policy routing» (т.е. маршрутизация на основе политик), а не «destination routing» (маршрутизация на основе адреса получателя).
Итак, приступим. Для начала определимся с переменными:
P — это шлюзы по умолчанию у наших провайдеров
Policy routing позволяет выполнять маршрутизацию на основе адреса источника поэтому перечислим сервера которые будут учавствовать:
Здесь SRV11 и SRV12 — это два айпишника одного и тогоже сервера (это важно!), это позволяет одному серверу обрабатывать входящие соединения с двух провайдеров. Конечно же, существуют и другие варианты реализовать эту возможность, но я буду использовать именно айпишники, мне кажется для начала так будет проше.
Ну а теперь самое интересное — пишем правило для маршрутизации.
Первое что мы должны сделать это добавить свои таблицы маршрутизации, для этого необходимо отредактировать файл /etc/iproute2/rt_tables, например так:
Тоесть мы добавляем маршруты, в которых указываем что попасть в подсеть первого провайдера можно через первый интерфейс. Во второй строчке мы добавляем шлюз по умолчанию.
Тоже самое и во второй:
Затем разберемся с основной таблицей, которая называется «main». Ее мы видим, когда набираем ip route:
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
ip route add default via $P1 metric 10
Первые две строчки аналогичны предыдущим записям, только опущено «table main». В третьей строчке задается маршрут по умолчанию с указанием метрики.
На этом с маршрутизацией разобрались, чтобы посмотреть что у нас находится в таблице маршрутизации можно выполнить команду «ip route show table ». Теперь приступим к правилам. Как раз по правилам и будет приниматься решения какой пакет по какой таблице будет маршрутизироваться.
Здесь мы указали, что если адрес источника равен первому внешнему адресу, тогда маршрутизация выполняется по таблице T1. Аналогично вторая запись.
И наконец самое интересное:
Используя iptables мы можем маркировать интересующие нас пакеты и маршрутизировать их на основе этих меток. Собственно здесь мы добавили два правила: для пакетов, имеющих метку 10, использовать таблицу T1, для пакетов с меткой 20 — T2. Сейчас возможно не очень понятно для чего это может потребоваться, но из правил iptables все станет ясно. Для просмотра правил выполняем «ip rule», при маршрутизации они проверяются по порядку.
Ну вот половина работы сделана осталось написать правила для iptables, об этом мы поговорим во второй части.
p.s. Написано, чтобы понять самому и рассказать другим.