Update README.md

This commit is contained in:
2026-05-26 11:21:05 +00:00
parent 7bbc4d6ada
commit ac3606808d

View File

@@ -92,7 +92,7 @@ EOF
```
ВАЖНОЕ ЗАМЕЧАНИЕ.
Далее мы сталкиваемся с дилеммой. OpenVPN в режиме DCO не имеет встроенной маршрутизации, а смотрит только системную таблицу маршрутизации (в линуксе - вообще только таблицу main). Значит мы должны направить default gateway в сторону клиента-шлюза. Но тогда сервер перестанет отвечать на запросы с основного (физического) интерфейса. Точнее, отвечать будет, но в интерфейс OpenVPN. Значит для трафика, входящего с физического интерфейса, default gateway должен быть направлен в сторону шлюза провайдера. Поэтому далее будет применена магия FreeBSD - FIBs (таблицы маршрутизации) и PF (фильтрация пакетов), с помощью которых легко и элегантно можно применить policy-based routing.
Далее мы сталкиваемся с дилеммой. OpenVPN в режиме DCO не имеет встроенной маршрутизации, а смотрит только системную таблицу маршрутизации. Значит мы должны направить default gateway в сторону клиента-шлюза. Но тогда сервер перестанет отвечать на запросы с основного (физического) интерфейса. Точнее, отвечать будет, но в интерфейс OpenVPN. Значит для трафика, входящего с физического интерфейса, default gateway должен быть направлен в сторону шлюза провайдера. Поэтому далее будет применена магия FreeBSD - FIBs (таблицы маршрутизации), в которой будут запущены демоны sshd и openvpn. На линуксе аналогичных возможностей нет, только долшая и мучительная возня с iptables. Лично я убил гору времени, не получив результата.
#### Шаг 1. Настройка ядра FreeBSD на работу с двумя таблицами (FIB)
По умолчанию во FreeBSD одна таблица маршрутизации. Добавим вторую:
```
@@ -102,25 +102,25 @@ echo 'net.fibs="2"' >> /boot/loader.conf
```
sysctl net.fibs=2
```
#### Шаг 2. Включаем Packet Filtering:
#### Шаг 2. Заполним альтернативную таблицу (FIB 1) при старте.
Узнайте имя своего физического интерфейса, а также локальную сеть и адрес шлюза сс помощью команды `ifconfig` и `netstat -rn`
```
nano /etc/pf.conf
nano /etc/rc.local
```
Если создался новый файл - это нормально. Значит pf на данной системе ещё не применялся. Добавим в файл следующее:
Если файл уже существует, добавьте туда две команды (без шебанга). Но на чистой системе он должен отсутствовать. И естественно, **замените имя интерфейса, сеть и адрес шлюза на свои**.
```
# Разрешаем весь трафик на vpn-интерфейсе и принудительно переключаем его на rtable 1 (FIB 1)
match in on ovpn0 rtable 1
# Пропускаем трафик (базовое правило, если у вас нет других ограничений)
pass all
#!/bin/sh
/sbin/route add -fib 1 -net 157.22.241.0/24 -interface vtnet0
route add -fib 1 default 157.22.241.1
```
Включаем PF в автозагрузку и запускаем его:
Перезагрузимся и проверим обе таблицы маршрутизации.
```
sysrc pf_enable="YES"
netstat -rn -F 0
```
```
service pf start
netstat -rn -F 1
```
Вторая таблица должна приссутствовать и в ней должны быть два маршрута из */etc/rc.local*
#### Шаг 3. PostUP-скрипт для добваления маршрутов
Поскольку сам процесс OpenVPN ничего не знает об альтернативной таблице маршрутизации, он будет пытаться добавлять маршруты в основную (FIB 0). Значит будем добавлять маршруты скриптом, запускающимсся вместе с туннелем.
```