Настройка SSH на двух сетевых интерфейсах

@PaperMan013 · Регистрация: 24.09.2019

Студворк — интернет-сервис помощи студентам

Приветствую форумчане.

Имеется несколько серверов под Debian с двумя сетевыми интерфейсами. Eth0 имеет статический адрес и смотрит в интернет. Eth1 подключён к локальной сети, которая тоже имеет выход в интернет через роутер.

Доступ по ssh из интернет через eth0 работает без проблем. Но при проброске порта через роутер на eth1 соединения нет. Из локалки напрямую ssh соединяется через eth1 без проблем.

Проблема похоже кроется именно в наличии двух интерфейсов в системе, и она одинаковая на всех серверах с двумя интерфейсами. В локалке есть другие сервера с одним только локальным интерфейсом. На них проброс порта через роутер работает без проблем.

Роутер на проброшенный порт пускает, переадресация работает. Но ssh сервер не слышит/не хочет слышать.

Настройки sshd пробовал разные: слушать на 0.0.0.0 или только на конкретном адресе - разницы нет. Всё как бы должно работать, вот только не работает.

Подскажите что проверить и куда копать?

@gng · 24.09.2019, 22:23

Сообщение от PaperMan013

Подскажите что проверить и куда копать?

Насколько я понял из вашего описания, маршрут по умолчанию указывает на маршрутизатор провайдера через eth0. Тогда обратные пакеты в любом случае уходят через eth0 и адрес отправителя будет другим.

Одно из решений:
1. Создаете два правила iptables: 1) маркирующeе входящие из роутера вашей сети пакеты (узнать можно, напр. по мак-адресу)
2) снимающeе маркировку у исходящих пакетов.
2. Создаете новую таблицу маршрутизации и прописываете там маршрут по умолчанию, указывающий на роутер вашей сети.
3. Прописываете правило маршрутизации, заворачивающее маркированные пакеты в созданную вами таблицу.

Примеры, думаю, найдете поиском по запросу о маршрутизации с двумя провайдерами .

@PaperMan013 · 25.09.2019, 01:13 **[ТС]**

Сообщение от gng

Насколько я понял из вашего описания, маршрут по умолчанию указывает на маршрутизатор провайдера через eth0. Тогда обратные пакеты в любом случае уходят через eth0 и адрес отправителя будет другим.

Одно из решений:
1. Создаете два правила iptables: 1) маркирующeе входящие из роутера вашей сети пакеты (узнать можно, напр. по мак-адресу)
2) снимающeе маркировку у исходящих пакетов.
2. Создаете новую таблицу маршрутизации и прописываете там маршрут по умолчанию, указывающий на роутер вашей сети.
3. Прописываете правило маршрутизации, заворачивающее маркированные пакеты в созданную вами таблицу.

Примеры, думаю, найдете поиском по запросу о маршрутизации с двумя провайдерами .

gng, Спасибо за направление!

Я создал две таблицы маршрутизации и назначил каждую своему интерфейсу. Теперь ответ сервера по дефолту идёт через шлюз интерфейса, на который поступил запрос. Ssh заработал и напрямую, и через проброшенный порт. Ssh настроил слушать запросы только из локальной сети. Цель в целом достигнута. Однако выяснился другой момент, который мне пока не понятен. Перестал отзываться ssh сервера на запросы другой машины внутри локальной сети. Видимо сервер теперь этот трафик отправляет на роутер вместо той машины в локальной сети. Я не имею опыта ручной настройки маршрутизации, но могу нарыть и научиться, что частично уже сделал по Вашей наводке. Но вот для поиска не могу сформулировать задачу. Прошу дать ещё наводку что поискать, чтобы окончательно решить вопрос. Можно оставить и так, тк основная задача решена, но хочется убрать все зазубрины, чтобы всё было идеально.

Добавлено через 9 минут
Для изучения и настройки использовал эту инструкцию.

@gng · 25.09.2019, 11:50

PaperMan013, покажите
# ip rule
# ip r show table all

@PaperMan013 · 26.09.2019, 23:24 **[ТС]**

ip rule

Code
1
2
3
4
5
0:      from all lookup local
32764:  from 93.95.102.143 lookup table1
32765:  from 192.168.1.9 lookup table2
32766:  from all lookup main
32767:  from all lookup default

ip r show table all

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
default via 93.95.102.1 dev ens192 table table1
default via 192.168.1.1 dev ens256 table table2
default via 93.95.102.1 dev ens192 onlink
93.95.102.0/24 dev ens192 proto kernel scope link src 93.95.102.143
192.168.1.0/24 dev ens256 proto kernel scope link src 192.168.1.9
broadcast 93.95.102.0 dev ens192 table local proto kernel scope link src 93.95.102.143
local 93.95.102.143 dev ens192 table local proto kernel scope host src 93.95.102.143
broadcast 93.95.102.255 dev ens192 table local proto kernel scope link src 93.95.102.143
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.1.0 dev ens256 table local proto kernel scope link src 192.168.1.9
local 192.168.1.9 dev ens256 table local proto kernel scope host src 192.168.1.9
broadcast 192.168.1.255 dev ens256 table local proto kernel scope link src 192.168.1.9
fe80::/64 dev ens192 proto kernel metric 256  pref medium
fe80::/64 dev ens256 proto kernel metric 256  pref medium
unreachable default dev lo proto kernel metric 4294967295  error -101 pref medium
local ::1 dev lo table local proto none metric 0  pref medium
local fe80::20c:29ff:fedb:a886 dev lo table local proto none metric 0  pref medium
local fe80::20c:29ff:fedb:a890 dev lo table local proto none metric 0  pref medium
ff00::/8 dev ens192 table local metric 256  pref medium
ff00::/8 dev ens256 table local metric 256  pref medium
unreachable default dev lo proto kernel metric 4294967295  error -101 pref medium

p.s. ens192 = eth0; ens256=eth1

@gng · 27.09.2019, 15:06

Сообщение от PaperMan013

Прошу дать ещё наводку

1. В двух словах, что происходит у вас:
Все пакеты, у которых исходящий адрес 93.95.102.1, попадают в таблицу table1 и идут через 93.95.102.1,
а с исходящим адресом 192.168.1.9 попадают в table2 и идут через 192.168.1.1
Исходящий адрес устанавливается вашим sshd при настройке сокета.

2. Что должно быть:
Пакеты, ответные на приходящие с внешней сети через ens192, должны уходить через 93.95.102.1,
а ответы на пакеты внешние пакеты через ens256, долдны уходить через 192.168.1.1.

3. Возможное решение.
1) Маркируем маркером 1 внешние пакеты, приходящие с ens256

Bash
1
# iptables -A INPUT -d 192.168.1.9/32 -m mac --mac-source <мак интерфейса 192.168.1.1 на роутере> -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x1/0xffffffff

или

Bash
1
# iptables -A INPUT -d 192.168.1.9/32 ! -s 192.168.0.0/16 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x1/0xffffffff

2) Снимаем на всякий случай маркировку с ответных пакетов уже после маршрутизации

Bash
1
# iptabkes -A OUTPUT -s 192.168.1.9/32 -m connmark ! --mark 0x0 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

3) Добавляем новую таблицу маршрутизации (у вас она table2)

Bash
1
# ip rule add fwmark 1 lookup table2

4) Добавляем в нее маршрут по умолчанию

Bash
1
# ip route add default via 192.168.1.1 dev ens256 table table2

5) Проверяем работу и, если нужно, изменяем файлы конфигурации

Добавлено через 28 минут
PS. Если будете играться с моими настройками, свои старые не забудьте сбросить.

@PaperMan013 · 27.09.2019, 15:18 **[ТС]**

gng, спасибо за ответ

Не понимаю пока в чём разница. У меня сейчас:

Ответы внешнего интерфейса идут на внешний шлюз
Ответы внутреннего интерфейса идут на внутренний шлюз

Почему тогда ssh соединение c соседнего адреса 192.168.1.21 на 192.168.1.9 не работает? По указанной выше логике ведь должно работать. Трафик от сервера 192.168.1.9 отправляется на шлюз 192.168.1.1 и должен направляться шлюзом на 192.168.1.21. Почему так не происходит?

И в чём принципиальная разница с предложенным Вами вариантом? Вы предлагаете сортировать запросы не по получателю, а по отправителю, но внутренние запросы также будут отправлены на шлюз 192.168.1.1. Или есть нюанс?

Я пытаюсь понять корень проблемы, даже если Ваш вариант будет работать, а использованный мной нет, хотя сейчас они оба кажутся мне похожими.

@gng · 27.09.2019, 17:31

Сообщение от PaperMan013

Трафик от сервера 192.168.1.9 отправляется на шлюз 192.168.1.1 и должен направляться шлюзом на 192.168.1.21. Почему так не происходит?

Потому что запросы внутри подсети не должны передаваться на шлюз. См. таблицу маршрутизации.

Сообщение от PaperMan013

И в чём принципиальная разница с предложенным Вами вариантом? Вы предлагаете сортировать запросы не по получателю, а по отправителю, но внутренние запросы также будут отправлены на шлюз 192.168.1.1.

Внутренние запросы не будут промаркированы и не попадут в новосозданную таблицу. Ядро при маршрутизации сразу поставит MAC получателя.
Почитайте что-нибудь из азов про отличие 2 и 3 уровней OSI.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@PaperMan013 0 / 0 / 0 Регистрация: 24.09.2019 Сообщений: 4

	Настройка SSH на двух сетевых интерфейсах 24.09.2019, 19:15. Показов 5705. Ответов 7 Метки нет (Все метки) Приветствую форумчане. Имеется несколько серверов под Debian с двумя сетевыми интерфейсами. Eth0 имеет статический адрес и смотрит в интернет. Eth1 подключён к локальной сети, которая тоже имеет выход в интернет через роутер. Доступ по ssh из интернет через eth0 работает без проблем. Но при проброске порта через роутер на eth1 соединения нет. Из локалки напрямую ssh соединяется через eth1 без проблем. Проблема похоже кроется именно в наличии двух интерфейсов в системе, и она одинаковая на всех серверах с двумя интерфейсами. В локалке есть другие сервера с одним только локальным интерфейсом. На них проброс порта через роутер работает без проблем. Роутер на проброшенный порт пускает, переадресация работает. Но ssh сервер не слышит/не хочет слышать. Настройки sshd пробовал разные: слушать на 0.0.0.0 или только на конкретном адресе - разницы нет. Всё как бы должно работать, вот только не работает. Подскажите что проверить и куда копать? 0

@gng 923 / 639 / 198 Регистрация: 08.09.2013 Сообщений: 1,693
	25.09.2019, 11:50
	PaperMan013, покажите # ip rule # ip r show table all 0

@PaperMan013 0 / 0 / 0 Регистрация: 24.09.2019 Сообщений: 4
	27.09.2019, 15:18 [ТС]
	gng, спасибо за ответ Не понимаю пока в чём разница. У меня сейчас: Ответы внешнего интерфейса идут на внешний шлюз Ответы внутреннего интерфейса идут на внутренний шлюз Почему тогда ssh соединение c соседнего адреса 192.168.1.21 на 192.168.1.9 не работает? По указанной выше логике ведь должно работать. Трафик от сервера 192.168.1.9 отправляется на шлюз 192.168.1.1 и должен направляться шлюзом на 192.168.1.21. Почему так не происходит? И в чём принципиальная разница с предложенным Вами вариантом? Вы предлагаете сортировать запросы не по получателю, а по отправителю, но внутренние запросы также будут отправлены на шлюз 192.168.1.1. Или есть нюанс? Я пытаюсь понять корень проблемы, даже если Ваш вариант будет работать, а использованный мной нет, хотя сейчас они оба кажутся мне похожими. 0