pfSense OpenVPN: доступ да сеткі за іншым маршрутызатарам

Ваш ноўтбук дасягае лакальнай сеткі pfSense праз VPN і ўсё роўна не можа дасягнуць сэрвісу яшчэ праз два хопы, і розніца — адно рашэнне аб маршрутызацыі на кожнага ўладальніка. Тры прылады павінны пагадзіцца, перш чым пакет завершыць свой шлях туды і назад: кліент, фаервол і маршрутызатар, які фактычна валодае сеткай прызначэння. Прапусціце хоць адну з іх — і сімптом будзе выглядаць аднолькава.

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

Адзін пакет, тры рашэнні аб маршрутызацыі

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

Адмова любога з іх дае аднолькавую скаргу карыстальніка. Таму парадак адладкі важнейшы за інструменты.

Дайце кліенту прэфікс, а не здагадку

На серверы pfSense SSL/TLS з сеткай тунэлю IPv4 большай за /30 поле IPv4 Local network(s) раздае маршруты кліентам пры падключэнні. Дадайце ніжэйшы прэфікс туды, а не спадзявайцеся, што кліент прыдумае яго сам. Затым прачытайце фактычную табліцу кліента пасля падключэння, бо профіль з route-nopull або фільтр маршрутаў можа ігнараваць тое, што адправіў сервер. Сервер можа быць цалкам правільным, пакуль кліент нічога не ўсталёўвае.

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

Направіце pfSense на ўнутраны маршрутызатар

Статычнаму маршруту ў pfSense патрэбны вызначаны і дасяжны шлюз, а інтэрфейс, выбраны для гэтага шлюза, павінен быць тым, які фактычна да яго даходзіць, як апісвае кіраўніцтва Netgate па статычных маршрутах. У ілюстрацыйнай схеме транзітны канал — 192.168.77.1 на фаерволе і 192.168.77.2 на ўнутраным маршрутызатары, а сетка сэрвісу — 172.16.30.0/25 за ім. Тады маршрут называе прэфікс і наступны хоп, а не адрас сэрвісу. Выкарыстанне адраса з далёкай сеткі як шлюза — распаўсюджаны спосаб пабудаваць маршрут, які выглядае правільным і нікуды не перасылае.

Прысваенне інтэрфейсу імя не апісвае сеткі за ім. Статычны маршрут — гэта тое апісанне.

Далёкі бок павінен ведаць пул

Ніжэйшаму маршрутызатару патрэбны зваротны маршрут да пула, у гэтым прыкладзе 10.55.0.0/24 праз 192.168.77.1, калі маршрут па змаўчанні або дынамічны пратакол ужо не дае яго. Шлюз самога хоста сэрвісу павінен весці да гэтага маршрутызатара, што звычайна праўдзіва, калі маршрутызатар з'яўляецца яго шлюзам па змаўчанні, і няпраўда, калі хост наладжвалі ўручную. Палітычная маршрутызацыя на фаерволе таксама можа перавызначыць табліцу для пэўнага трафіку, таму праверце, ці правіла выбірае іншы шлюз, перш чым рабіць выснову, што маршрут няправільны.

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

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

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