Маршрутызаваны ці маставы VPN: выбірайце па тым, да чаго павінен дабрацца кліент

У адзін дзень прыходзяць дзве заяўкі: аднаму карыстальніку патрэбна ўнутраная вэб-праграма, а аднаму інжынеру патрэбна, каб стэндавы прыбор паводзіў сябе так, нібы ён стаіць у тым самым сегменце Ethernet. На абедзве адказваюць «пасадзіце іх на VPN», і менавіта тут пачынаецца бяда. Маршрутызаваны тунель і маставы тунель усталёўваюць розныя адносіны, і толькі адзін з іх адпавядае кожнаму запыту. Выбар тапалогіі — гэта рашэнне аб доступе, а не налада крыптаграфіі.

Дзве заяўкі, якія выглядаюць аднолькава на стойцы рэгістрацыі

Патрабаванне супрацоўніка — гэта сэрвіс, дасяжны праз IP з прылады, якой вы не кіруеце. Патрабаванне інжынера — на ўзроўні канала: прыбор чакае ўбачыць кадры Ethernet і шырокавяшчальнае выяўленне, а магчыма, і DHCP з таго сегмента, у якім ён лічыць сябе.

Гэта розныя пытанні, і адказ на абодва мостам без прычыны пашырае доступ супрацоўніка на ўсю офісную LAN.

Запішыце патрабаванне сказам перад выбарам: якія прызначэнні, якія пратаколы і якія аднарангі павінны выглядаць лакальнымі. Калі адказ — хост і порт, маршрутызацыя гэта пакрывае. Калі адказ — адносіны на ўзроўні кадра з прыладамі, якія размаўляюць толькі шырокавяшчальна, мост можа быць адзіным варыянтам. Усё прамежкавае заслугоўвае тэставага сегмента, а не вытворчай LAN.

Маршрут вузейшы за сяброўства ў LAN

Маршрутызаваны кліент атрымлівае адрас у падсетцы тунеля і маршруты для выбраных вамі прэфіксаў. Ён можа дасягнуць сервера праграмы і нічога большага, калі так кажа палітыка. Шлюз становіцца пунктам прымянення, пры ўмове, што кожны адпаведны шлях перасякае яго.

Не блытайце маршрут з дазволам. Калі сказаць кліенту, як дасягнуць падсеткі, гэта не перашкодзіць яму паспрабаваць іншае прызначэнне.

Ужывайце кантроль доступу там, дзе ён сапраўды можа забяспечыць паток, і захоўвайце ўласныя дазволы праграмы. Шырокае правіла перасылкі або забыты другі інтэрфейс могуць даць больш, чым паказвае схема. Чытайце дзейныя правілы, а не меркаваныя. Затым праверце прызначэнне, якое павінна не спрацаваць, бо палітыка, якую ніхто не спрабаваў парушыць, — гэта гіпотэза.

Мост змяняе пытанне аб допуску

Маставанне аб’ядноўвае фізічны інтэрфейс і прыладу TAP у праграмны камутатар, таму аддаленыя прылады далучаюцца да таго ж шырокавяшчальнага дамена. Гэта рэальная магчымасць і рэальная рызыка: аддаленая прылада ўжо не маршрутызаваны госць, а ўдзельнік.

Вырашыце, якім прыладам можна далучацца, якія тыпы кадраў павінны праходзіць і дзе блакуецца непажаданае ўзаемадзеянне. Адрасацыя і паўнамоцтвы DHCP становяцца часткай супольнай сеткі, і два серверы DHCP у адным сегменце ствараюць менавіта той бязлад, якога вы чакаеце.

Для прыбора звычайна лепш падыходзіць асобны тэставы сегмент, чым офісная LAN. Трымайце доступ кіравання па-за эксперыментам і вызначце, як часовы ўдзельнік выдаляецца пасля заканчэння працы.

Фільтраванне ёсць у абедзвюх тапалогіях

Мост не з’яўляецца непазбежна нефільтруемым, а маршрут не з’яўляецца непазбежна бяспечным. Фільтраванне мастоў Linux мае свае крукі і свой сінтаксіс правілаў, і правіла, напісанае для маршрутызаванай перасылкі IP, не ўжываецца аўтаматычна да кадраў маста.

Праверце, што платформа сапраўды падтрымлівае, перш чым абяцаць мяжу:

bridge link show
nft list ruleset

TUN і TAP апісваюць трафік інтэрфейса, а не шыфр. Пераключэнне інтэрфейсаў не выпраўляе нічога з гэтага: аўтэнтыфікацыя аднарангаў, украдзены ключ і састарэлая крыптаграфічная палітыка ўсе перажываюць змену. Абодва бакі па-ранейшаму патрабуюць налад, якія супадаюць і якія ўсё яшчэ падтрымліваюцца.

Давядзіце мяжу трыма спробамі

Прыёмка — гэта тры назіранні, а не прагляд схемы. Патрэбная аперацыя павінна працаваць, непавязанае прызначэнне павінна не спрацаваць, а ўласныя службы кіравання шлюза павінны заставацца недасяжнымі.

Запусціце дазволены і забаронены шляхі з аднаго кліента і запішыце абодва:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Для моста дадайце праверкі ўзроўню канала: ці праходзіць дазволены трафік выяўлення, ці адрасацыя прыходзіць ад меркаванага ўладальніка і ці знік часовы ўдзельнік пасля выдалення. Калі звычайны маршрутызаваны IP ужо задавальняе патрабаванне, далучэнне да офіснага сегмента Ethernet патрабуе асобнага абгрунтавання, і яго трэба запісаць да змены.