Дазволіць аднаму кліенту 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 да шлюза або адкрыты порт на серверы нічога з гэтага не даказвае, бо і тое і другое можа быць праўдай, пакуль перасылка паміж суседзямі яшчэ заблакаваная. Запішыце гэтыя лікі, пакуль тунель падняты, бо адрас, які кліент атрымлівае пасля перападключэння, можа быць іншым.

Падобныя артыкулы