pfSense OpenVPN: пристап до мрежа зад друг рутер

Вашиот преносен компјутер стигнува до LAN-от на 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, освен ако стандардна рута или динамичен протокол веќе не обезбедува една. Портата на самиот домаќин на услугата мора да води кон тој рутер, што обично е точно кога рутерот е негова стандардна порта и неточно кога домаќинот е рачно конфигуриран. Рутирањето по политика на огнениот ѕид исто така може да ја надмине табелата за одреден сообраќај, затоа проверете дали правило избира друга порта пред да заклучите дека рутата е погрешна.

За овој дизајн не е потребно преведување, а останувањето на изворната адреса на клиентот видлива му овозможува на долниот мрежен дел да примени сопствена политика.

За прифаќање, следете едно ново барање низ влезот во тунелот, внатрешниот излез на огнениот ѕид и одговорот од целта. Ако наместо тоа намерно се користи преведување, запишете кој извор го гледа долниот мрежен дел и како се очекува да се врати одговорот.

Зачувајте го планот на трите сопственици покрај дозволената апликација, за да може следниот администратор да го реконструира патот наместо да го открива повторно.