Update README.md

README.md

@@ -90,8 +90,15 @@ status /var/log/openvpn-status.log
 verb 3
 EOF
 ```
-
-ВАЖНОЕ ЗАМЕЧАНИЕ.
+Добавим директивы для нашего клиента-шлюза:
+```
+cat << 'EOF' > /usr/local/etc/openvpn/ccd/gateway-client
+ifconfig-push 10.210.0.254 255.255.255.0
+iroute 0.0.0.0 0.0.0.0
+push-remove "redirect-gateway def1 bypass-dhcp"
+EOF
+```
+#### ВАЖНОЕ ЗАМЕЧАНИЕ.
 Далее мы сталкиваемся с дилеммой. OpenVPN в режиме DCO не имеет встроенной маршрутизации, а смотрит только системную таблицу маршрутизации. Значит мы должны направить default gateway в сторону клиента-шлюза. Но тогда сервер перестанет отвечать на запросы с основного (физического) интерфейса. Точнее, отвечать будет, но в интерфейс OpenVPN. Значит для трафика, входящего с физического интерфейса, default gateway должен быть направлен в сторону шлюза провайдера. Поэтому далее создадим альтернативную таблицу маршрутизации (FIB=Forwarding information base), в которой будут запущены демоны sshd и openvpn. На линуксе нельзя направить процессу талицу маршрутизации, только долгая и мучительная возня с iptables. Лично я убил гору времени, не получив результата.
 #### Шаг 1. Настройка ядра FreeBSD на работу с двумя таблицами (FIB)
 По умолчанию во FreeBSD одна таблица маршрутизации. Добавим вторую:
@@ -176,11 +183,7 @@ chmod +x /usr/local/etc/openvpn/route-down.sh
 ```
 service openvpn start
 ```
-SSH-сессия должна остаться активной, так как дефолтная таблица маршрутизации (FIB 0) сервера не изменилась. Проверить, что интерфейс поднялся, можно стандартно: `ifconfig ovpn0`
-Проверить, как выглядят маршруты внутри изолированной таблицы, можно командой:
-```
-netstat -rn -F 1
-```
+
 Осталось добавить директивы для нашего клиента-шлюза:
 ```
 cat << 'EOF' > /usr/local/etc/openvpn/ccd/gateway-client