Чому правило порту джерела ламає один із ваших шляхів SSH

Збіг «sport 22» не вказує, до якого входу SSH належить відповідь. Обмежте правило політики потоком керування, а не однією таблицею лише для WAN.

Два керівні входи на одному хості, один порт служби й правило політики, яке мало допомогти обом. Правило збігається з портом джерела 22, надсилає пошук до таблиці, яка знає лише типове значення WAN, і вхід VPN перестає відповідати на нові входи, тоді як прямий вхід продовжує працювати. Нічого загадкового в цьому немає, щойно селектор прочитано правильно. Порт джерела визначає службу, а не шлях, яким прийшло з'єднання.

Два входи, один порт служби

Хост має адресу з боку LAN і адресу VPN, і sshd слухає на обох. Тому прямий сеанс і тунельний сеанс поділяють порт служби й різняться лише тим, яка локальна адреса приймає з'єднання.

Цієї різниці достатньо для вибору шляху відповіді, і саме цю різницю відкидає правило, засноване на порту. Обидва сеанси створюють відповіді, порт джерела яких дорівнює 22, тому правило, що збігається з цим портом, не може їх розділити. Воно надсилає обидва пошуки до однієї таблиці, і один із них отримує відповідь, яка не підходить. Виправлення — зіставити атрибут, який справді різниться.

Дати кожному входу власний порт теж спрацювало б, а вважати це вимогою — вибір проєктування, а не властивість SSH.

Прочитайте правило, потім таблицю

Правило політики — це впорядкований селектор, і перше, що повертає придатну відповідь, завершує пошук. Прочитайте список по порядку й зауважте, яке правило може перемогти.

Потім прочитайте таблицю, на яку вказує це правило, бо правило, яке успішно розв'язується, не обов'язково розв'язується корисно. Таблиця, що містить лише типовий маршрут, надсилає відповідь із джерелом VPN назовні через інтерфейс WAN. Конкретніший маршрут у пізнішій таблиці ніколи не розглядається, і тому додавання другої таблиці так часто нічого не змінює. Саме вибрану таблицю треба перевірити.

ip -4 rule show
ip route show table 100
ip route show table main

Ці два виводи разом пояснюють результат; кожен окремо веде до хибного висновку.

Обмежте правило тим потоком, який маєте на увазі

Атрибут, що розділяє два входи, — локальна адреса джерела. Правило, яке збігається з цією адресою, надсилає до приватної таблиці лише тунельні сеанси, а прямі сеанси залишає в основній таблиці.

Це правило потрібно поєднати з таблицею, що містить приватний маршрут і зворотний шлях для цієї підмережі. Обмежте обидва керівним трафіком, а не кожною службою на хості. Правило, яке перехоплює весь трафік із цієї адреси, перенаправить і все інше, що хост надсилає звідти. Вузьке тут перемагає хитромудре, бо наступній людині це читати.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Якщо обидва входи перекласти на одну локальну адресу, ця різниця зникає, і проєктуванню замість цього потрібен стан, що враховує з'єднання.

Тримайте окремо слухач, дозвіл і вибір відповіді

Три окремі речі мають бути істинними, перш ніж сеанс запрацює: адреса існує, служба слухає на ній, і відповідь знаходить шлях назад. Зміна маршруту виправляє лише третю.

Конфігурація слухача — це окремий файл і окреме перезавантаження, і кілька адрес прослуховування — це нормально. Автентифікація — знову третє рішення, і виняток у маршрутизації нікому не дає доступу. Тримайте перевірку ключа хоста, автентифікацію облікового запису й обмеження джерела на обох входах і спротивляйтеся бажанню послабити інші засоби контролю тунелю, щоб працював один шлях керування.

Тримайте канал відновлення, який не залежить від шляху, який ви змінюєте, бо помилка тут блокує саме виправлення.

Доведіть це новим сеансом, а не старим

Установлений термінал нічого не доводить, оскільки його допущено до зміни. Відкрийте новий сеанс через кожен передбачений вхід.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Потім повторіть перепідключення VPN і спробуйте знову, бо маршрут, що переживає перепідключення, — не те саме, що маршрут, доданий до таблиці, яку перепідключення очищає. Спостерігайте за відхиленими джерелами окремо від дозволених, щоб заблокована спроба не сховалася за робочим сеансом. Збережіть локальну адресу, правило й таблицю поруч із результатом. Якщо натомість ви розділили порти, зафіксуйте це як операційне рішення, а не як обмеження SSH.

Схожі статті