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, освен ако маршрут по подразбиране или динамичен протокол вече не предоставя такъв. Шлюзът на самия хост на услугата трябва да води към този рутер, което обикновено е вярно, когато рутерът е негов шлюз по подразбиране, и невярно, когато хостът е конфигуриран ръчно. Политическото маршрутизиране на защитната стена също може да отмени таблицата за конкретен трафик, затова проверете дали правило избира друг шлюз, преди да заключите, че маршрутът е грешен.

За този дизайн не е необходима транслация и запазването на видим адреса на източника на клиента позволява на долната мрежа да приложи собствената си политика.

За приемане проследете една нова заявка през входа на тунела, вътрешния изход на защитната стена и отговора от местоназначението. Ако вместо това умишлено се използва транслация, запишете източника, който долната мрежа вижда, и как се очаква да се върне отговорът.

Запазете плана с трите собственика заедно с разрешеното приложение, така че следващият администратор да може да възстанови пътя, вместо да го открива наново.