Дозволити одному клієнту OpenVPN підключатися по SSH до іншого, не відкриваючи пул

Залиште client-to-client вимкненим, дозвольте ядру пересилати один потік, а решта пулу нехай залишається закритою. Два правила на сервері й одне на призначенні.

Одному клієнту треба дістатися до служби SSH іншого клієнта, а решта пулу має залишатися такою ж ізольованою, як зараз. Спокусливий перемикач — client-to-client, який вмикає доступ між вузлами одразу для всіх і передає рішення OpenVPN замість ядра. Вужча відповідь залишає цей перемикач вимкненим і дозволяє власній маршрутизації та міжмережевому екрану сервера нести рівно один потік.

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

Куди client-to-client переносить пакет

Коли client-to-client увімкнено, сервер пересилає пакет сусіда внутрішньо, замість того щоб відправити його назад через тунельний пристрій, тож пакет ніколи не потрапляє на шлях пересилання ядра. Це зручно, і це також означає, що ваш міжмережевий екран ніколи не бачить потік, який мав би контролювати. Залиште параметр вимкненим, і сервер спрямує пакет назад через той самий інтерфейс, що ставить його перед netfilter. Той самий інтерфейс на вході, той самий на виході, і ланцюг FORWARD отримує голос.

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

Шлях, який пакет сусіда справді проходить

Припустімо службу Linux Community OpenVPN 2.6, обробку TUN у просторі користувача, а не DCO, топологію підмережі, tun0 і пул 10.44.0.0/24 з клієнтом A на 10.44.0.21 і клієнтом B на 10.44.0.37. За топології підмережі адреса й маска, які отримав A, уже покривають пул, тож A надсилає пакет на тунельний пристрій без додаткового проштовхуваного маршруту. Перевірте фактичний маршрут на A, а не припускайте його.

На сервері пакет надходить адресованим B, а це не локальна адреса, тож він пересилається. Пересилання IPv4 має бути ввімкнене, щоб це взагалі сталося, і пошук маршруту має відправити пакет назад через tun0. Тому міжмережевий екран бачить пересланий потік з тим самим інтерфейсом з обох боків, і це та деталь, яку пропускає більшість наборів правил. Тут не потрібна трансляція джерела, і саме збереження адреси A недоторканою дозволяє B застосувати власне правило за джерелом.

Два правила на сервері, у цьому порядку

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Ці команди ілюстративні й належать до того механізму, яким ваш хост зберігає правила; вставка під час роботи зникає при наступному завантаженні. Саме правило зі станом дозволяє відповідям B і рукостисканню TCP повернутися без другого, дзеркального дозволу.

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

Що B усе ще має дозволити

B запускає службу SSH, тож B вирішує, чи щось слухає тунельну адресу і чи приймає джерело власний міжмережевий екран хоста. Дозвіл на рівні мережі на сервері не є дозволом для жодного облікового запису на B, а перевірка ключа хоста й автентифікація користувача далі діють, як і з будь-якого іншого місця.

Спершу перевірте позитивний випадок: нове SSH-з'єднання від A до тунельної адреси B, прийняте з очікуваним ключем хоста. Потім перевірте іншого сусіда або інший порт і підтвердіть, що його відхилено, бо дозвіл, який мовчки дозволяє все, не відрізнити від робочого, поки це не стане важливим. Потрібні обидві половини цієї перевірки, і друга — та, яку люди пропускають.

Запишіть призначені адреси, фактичні маршрути на обох клієнтах і точні правила на сервері та на B. Успішний ping до шлюзу або відкритий порт на сервері нічого з цього не доводить, бо і те й те може бути правдою, поки пересилання між сусідами ще заблоковане. Запишіть ці числа, поки тунель піднятий, бо адреса, яку клієнт отримує після повторного підключення, може бути іншою.

Схожі статті