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

Цій схемі не потрібна трансляція, а видима адреса джерела клієнта дозволяє нижній мережі застосувати власну політику.

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

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