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

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

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

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