dbadovsky/openvpn_infrastructure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Дмитрий Бадовский
2026-05-26 12:12:47 +00:00
parent ac3606808d
commit 0f714f3ffd
1 changed files with 32 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
README.md
View File

@@ -92,7 +92,7 @@ EOF
```
ВАЖНОЕ ЗАМЕЧАНИЕ.
Далее мы сталкиваемся с дилеммой. OpenVPN в режиме DCO не имеет встроенной маршрутизации, а смотрит только системную таблицу маршрутизации. Значит мы должны направить default gateway в сторону клиента-шлюза. Но тогда сервер перестанет отвечать на запросы с основного (физического) интерфейса. Точнее, отвечать будет, но в интерфейс OpenVPN. Значит для трафика, входящего с физического интерфейса, default gateway должен быть направлен в сторону шлюза провайдера. Поэтому далее будет применена магия FreeBSD - FIBs (таблицы маршрутизации), в которой будут запущены демоны sshd и openvpn. На линуксе аналогичных возможностей нет, только долшая и мучительная возня с iptables. Лично я убил гору времени, не получив результата.
Далее мы сталкиваемся с дилеммой. OpenVPN в режиме DCO не имеет встроенной маршрутизации, а смотрит только системную таблицу маршрутизации. Значит мы должны направить default gateway в сторону клиента-шлюза. Но тогда сервер перестанет отвечать на запросы с основного (физического) интерфейса. Точнее, отвечать будет, но в интерфейс OpenVPN. Значит для трафика, входящего с физического интерфейса, default gateway должен быть направлен в сторону шлюза провайдера. Поэтому далее будет применена магия FreeBSD - FIBs (таблицы маршрутизации), в которой будут запущены демоны sshd и openvpn. На линуксе аналогичных возможностей нет, только долгая и мучительная возня с iptables. Лично я убил гору времени, не получив результата.
#### Шаг 1. Настройка ядра FreeBSD на работу с двумя таблицами (FIB)
По умолчанию во FreeBSD одна таблица маршрутизации. Добавим вторую:
```
@@ -121,8 +121,36 @@ netstat -rn -F 0
netstat -rn -F 1
```
Вторая таблица должна приссутствовать и в ней должны быть два маршрута из */etc/rc.local*
#### Шаг 3. PostUP-скрипт для добваления маршрутов
Поскольку сам процесс OpenVPN ничего не знает об альтернативной таблице маршрутизации, он будет пытаться добавлять маршруты в основную (FIB 0). Значит будем добавлять маршруты скриптом, запускающимсся вместе с туннелем.
#### Шаг 3. Перемещение нужных процессов в FIB 1
Выполним команду:
```
setfib service sshd restart
```
Это единоразово переместит ssh в fib 1. **Переподключимся к серверу по ssh**. Проверим, какую таблицу ммаршрутизации использует наш демон.
```
ps -ax -o pid,fib,command | grep -E 'sshd'
```
Если во второй колонке мы видим единицы, значит мы вссё сделали правильно, и доступ к серверу через FIB 1 есть. Можно модифицировать FIB 0 под наши цели. Применим изменения перманентно. Для этого добавим в `/etc/rc.conf` следующие строки:
```
sshd_fib="1"
openvpn_fib="1"
```
Перезагрузимся и проверим, что мы точно имеем доступ к серверу именно благодаря альтернативной таблице.
```
ps -ax -o pid,fib,command | grep -E 'sshd|openvpn'
```
Должна показывать единицы во второй колонке, ессли это так, удалим маршрут по-умолчанию в основной таблице:
```
route del -fib 0 default
```
И проверим саму таблицу:
```
netstat -rnF 0
```
Вывод не должен содержать маршрута по-умолчанию. При этом вывод есть, значит доступ к серверу мы не потеряли.
Если потеряли, перезагрузка вернёт маршрут по-умолчанию.
*Поскольку сам процесс OpenVPN ничего не знает об альтернативной таблице маршрутизации, он будет пытаться добавлять маршруты в основную (FIB 0). Значит будем добавлять маршруты скриптом, запускающимсся вместе с туннелем.
```
echo 'script-security 2' >> /usr/local/etc/openvpn/openvpn.conf
echo 'up "/usr/local/etc/openvpn/up.sh"' >> /usr/local/etc/openvpn/openvpn.conf
@@ -139,7 +167,7 @@ EOF
```
```
chmod +x /usr/local/etc/openvpn/up.sh
```
```*
#### Шаг 4. Включаем OpenVPN.
```
service openvpn start