когда останавливаю openvpn -- не работает gatetway

[demjanok]

Всем привет!
Комп работает в качестве шлюза и openvpn сервера.
Столкнулся с проблемой: когда останавливаю деймона openvpn - не работает gatetway.
Может стоит openvpn перенастроить в режим бриджа?

[fisher74]

Предлагаю начать с диагностики.
покажите конфиг сервера OVPN и выхлоп команды ip a; ip r во время работы деймона и после его остановки.

[demjanok]

Конфиг openvpn:

(Нажмите, чтобы показать/скрыть)

push "redirect-gateway def1"   
push "dhcp-option DNS 8.8.8.8"
local 195.xx.xx.61
port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
duplicate-cn
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth ta.key 0
cipher DES-EDE3-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
verb 5

Вывод ip a && ip r когда работает openvpn:

(Нажмите, чтобы показать/скрыть)

root@test:~# ip a && ip r
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:08:a1:72:a4:ee brd ff:ff:ff:ff:ff:ff
    inet 195.xx.xx.61/29 brd 195.xx.xx.63 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::208:a1ff:fe72:a4ee/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:30:4f:1b:51:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::230:4fff:fe1b:5170/64 scope link
       valid_lft forever preferred_lft forever
14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
default via 195.xx.xx.57 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.2
195.xx.xx.56/29 dev eth0  proto kernel  scope link  src 195.xx.xx.61

После остановки:

(Нажмите, чтобы показать/скрыть)

root@test:~# ip a && ip r
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:08:a1:72:a4:ee brd ff:ff:ff:ff:ff:ff
    inet 195.xx.xx.61/29 brd 195.xx.xx.63 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::208:a1ff:fe72:a4ee/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:30:4f:1b:51:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::230:4fff:fe1b:5170/64 scope link
       valid_lft forever preferred_lft forever
default via 195.xx.xx.57 dev eth0
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.2
195.xx.xx.56/29 dev eth0  proto kernel  scope link  src 195.xx.xx.61

Также NAT прописал в rc.local:

(Нажмите, чтобы показать/скрыть)

sysctl -w net.ipv4.ip_forward="1"
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
# Added by hwdsl2 VPN script
#service fail2ban restart || /bin/true
#service ipsec start
#service xl2tpd start
#echo 1 > /proc/sys/net/ipv4/ip_forward
exit 0

[fisher74]

Партизанство до конца у Вас не получилось
Теперь скажите как проявляется "не работает gatetway". Просто не совсем понятно о чём Вы пишите, так как выход в интернет для локальной сети изначально не предусмотрен, ибо маскарадится интерфейс локальной сети (что видимо для работы удалённой сети), а не внешней.

[demjanok]

извините за невнимательность 
изначально с
sysctl -w net.ipv4.ip_forward="1"
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
комп как шлюз работал.

[fisher74]

тогда уж показывайте sudo iptables-save во время "кризиса"

[demjanok]

iptables-save

(Нажмите, чтобы показать/скрыть)

# Generated by iptables-save v1.4.21 on Wed Jul 20 12:31:19 2016
*nat
:PREROUTING ACCEPT [892:70193]
:INPUT ACCEPT [157:19933]
:OUTPUT ACCEPT [37:2559]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADE
COMMIT
# Completed on Wed Jul 20 12:31:19 2016
# Generated by iptables-save v1.4.21 on Wed Jul 20 12:31:19 2016
*mangle
:PREROUTING ACCEPT [11285:2546501]
:INPUT ACCEPT [3395:584527]
:FORWARD ACCEPT [7542:1937698]
:OUTPUT ACCEPT [2498:515073]
:POSTROUTING ACCEPT [10040:2452771]
COMMIT
# Completed on Wed Jul 20 12:31:19 2016
# Generated by iptables-save v1.4.21 on Wed Jul 20 12:31:19 2016
*filter
:INPUT ACCEPT [3247:565489]
:FORWARD ACCEPT [7025:1767117]
:OUTPUT ACCEPT [2353:499728]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Wed Jul 20 12:31:19 2016

Вроде нашел причину: когда закомментировал в конфиге ovpn строчку push "redirect-gateway def1" - как шлюз работает нормально, но openvpn не видит локальную сеть...
Пользователь добавил сообщение 20 Июля 2016, 12:37:55:как решить?

[fisher74]

Вроде нашел причину: когда закомментировал в конфиге ovpn строчку push "redirect-gateway def1" - как шлюз работает нормально

Что-то не то. Этот параметр на серверную часть вообще никак не действует. Диагностика это подтверждает.
Вы так и не ответили, как проявляется "не работает gatetway"

[demjanok]

Оказывается что влияет на маршрутизацию...
https://openvpn.net/index.php/open-source/documentation/howto.html

(Нажмите, чтобы показать/скрыть)

Implementation

Add the following directive to the server configuration file:

    push "redirect-gateway def1"

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

    push "redirect-gateway local def1"

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

    iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.

When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

    push "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server.

Эта опция заставляет "гнать" весь трафик через сервер openvpn.

тут я Вас переплюнул?

[fisher74]

Конечно переплюнули... только ветер в другую сторону. Вытирайтесь.
Опция влияет на таблицу маршрутизации у клиента OVPN, а не у сервера. Собственно для этого она и создана.

[demjanok]

тогда как объяснить? когда я сижу в локальной сети и даю нагрузку на шлюз (торренты, спидтест и тд) процессор грузит до придела только openvpn.

[fisher74]

что объяснять, если пока не получен ответ на главный вопрос: как проявляется "не работает gatetway"?

Если клиент торрентов находится в сети OVPN, то повышенная прожорливость сервера OVPN вполне объяснима - ему весь этот трафик приходится шифровать/дешифровать

[demjanok]

"не работает gatetway" - трафик не маршрутизирует между локальной сетью и сетью провайдера. Нагрузку я давал с локальной сети (не с удаленного пк через ovpn туннель) и было понятно что openvpn пропускал через себя весь локальный трафик. Закомментировал #push "redirect-gateway def1" и добавил "push "route 192.168.0.0 255.255.255.0" # home" и все заработало как надо. Теперь при нагрузке с локальной сети демон openvpn "отдыхает".

Пользователь добавил сообщение 20 Июля 2016, 14:11:39:Пометил как решенная проблема, спасибо за внимание и помощь.

[fisher74]

бред. команда push не влияет на сам собственно сервер. НИКАК. Влияет исключительно на таблицу маршрутизации подключаемого удалённого клиента. И таблица маршрутизации у Вас не изменилась (можете сами посмотреть).

[demjanok]

Это не моя фантазия. Всего лишь констатирую факт, больше никаких манипуляций в система я не делал, а для более глубокого анализа у меня нету навыков.