Перенаправление пользователя на страничку подключения при падении VPN

[AnrDaemon]

Зацикливание, как раз, есть.
Укажите входящий интерфейс.

[slech]

Код: [Выделить]

# Generated by iptables-save v1.3.5 on Sat Mar  3 22:48:08 2012
*nat
:PREROUTING ACCEPT [852:87782]
:POSTROUTING ACCEPT [42:3000]
:OUTPUT ACCEPT [42:3000]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -m comment --comment "Redirect if VPN is down" -j REDIRECT --to-ports 80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -m comment --comment "Redirect if VPN is down" -j REDIRECT --to-ports 443
COMMIT
# Completed on Sat Mar  3 22:48:08 2012
Результат тот же впринципе.
Работает вроде как надо, но долго.
Пользователь решил продолжить мысль 04 Марта 2012, 02:12:37:сделал 2 скрипта
iptables-if-up-nat.sh

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

Код: [Выделить]

#!/bin/bash
#
# Flush nat table
/sbin/iptables --table nat --flush
#
#
# Add NAT rule
/sbin/iptables --table nat --append POSTROUTING --out-interface tun0 -j MASQUERADE -m comment --comment "Masquerading"
#


iptables-if-down-redirect.sh

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

Код: [Выделить]

#!/bin/bash
#
# Flush nat table
/sbin/iptables --table nat --flush
#
# Add rules to redirect all traffic
/sbin/iptables --table nat --append PREROUTING --in-interface eth0 -p tcp --dport 80 -j REDIRECT --to-port 80 -m comment --comment "Redirect if VPN is down"
/sbin/iptables --table nat --append PREROUTING --in-interface eth0 -p tcp --dport 443 -j REDIRECT --to-port 443 -m comment --comment "Redirect if VPN is down
#


изменил /etc/netplug.d/netplug

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

Код: [Выделить]

PATH=/usr/bin:/bin:/usr/sbin:/sbin
export PATH

dev="$1"
action="$2"

case "$action" in
in)
    if [ -x /sbin/ifup ]; then
        if [ "$1" = "tun0" ]; then
        /bin/bash /opt/vpn/iptables-if-up-nat.sh
        exec /sbin/ifup $dev
    else
        exec /sbin/ifup $dev
    fi
    else
        echo "Please teach me how to plug in an interface!" 1>&2
        exit 1
    fi
    ;;
out)
    if [ -x /sbin/ifdown ]; then
        # At least on Fedora Core 1, the call to ip addr flush infloops
        # /sbin/ifdown $dev && exec /sbin/ip addr flush $dev
        exec /sbin/ifdown $dev
    else
        exit 1
    fi
    ;;
probe)
    if [ "$1" = "tun0" ]; then
        /bin/bash /opt/vpn/iptables-if-down-redirect.sh
        exec /sbin/ip link set $dev up >/dev/null 2>&1
    else
    exec /sbin/ip link set $dev up >/dev/null 2>&1
    fi
    ;;
*)
    echo "I have been called with a funny action of '%s'!" 1>&2
    exit 1
    ;;
esac


Теперь при установке VPN соединения сайт site1-vpn.domain.com открывается, при отсутсвующем VPN соединении пользователь попадает на страничку https://proxy-vpn.domain.local

Проблемы которые остались:
1. Редирект происходит крайне долго, иногода до 20 секунд - так же долго как и отваливается соединение если VPN не поднят - т.е. цель всех моих манипуляйий не достигнута.

[AnrDaemon]

МыслЯ в голову пришла.
Посмотри, что реально происходит долго?

[slech]

Использовал Google Chrome - Inspect Element
1. https://site1-vpn.domain.com - 06.919 sec.
2. 302 https://site1-vpn.domain.com - 09.475 sec
3. 302 http://proxy-vpv.domain.local - 00.005 sec
4. 200 https://proxy-vpn.domain.local - 00.192 sec

Получается что основная задержка на первых 2-ух шагах. Буду разбираться с Apache откуда берётся второй этап.
А вот почему на первом получаетяс долгое ожидание непонятно.
1. DNS имя резолвится у нас на наших DNS серверах - т.е. задержка точно не в DNS.
2. Далее идёт обращение по IP.
3. Mikrotik посылает на CentOS
4. CentOS дожен завернуть весь трафик на Сaptive Portal
5. Captive Portal перенапрявлят на https://proxy-vpn.domain.local


Смотрю tracert

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

tracert site1-vpn.domain.com
  1    <1 ms     5 ms    13 ms  Mikrotik
  2    <1 ms    19 ms    20 ms  CentOS
  3    20 ms    40 ms    40 ms  Mikrotik
  4    20 ms    31 ms    19 ms  CentOS
  5    41 ms    40 ms    60 ms  Mikrotik
  6    45 ms    60 ms    60 ms  CentOS
  7    61 ms    66 ms    40 ms  Mikrotik
  8    66 ms    81 ms    55 ms  CentOS
  9   100 ms   101 ms   101 ms  Mikrotik
 10    47 ms    41 ms    60 ms  CentOS

Смотрю пинги

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

Pinging site1-vpn.domain.com [44.44.44.44] with 32 bytes of data:
reply from CentOS: TTL expired in transit.
reply from CentOS: TTL expired in transit.
reply from CentOS: TTL expired in transit.
reply from CentOS: TTL expired in transit.

Пользователь решил продолжить мысль 04 Марта 2012, 12:19:30:а, ну да. icmp и не будет работать. у нас заворачивается tcp http/https.

[AnrDaemon]

tcpdump вообще-то смотреть надо.

[slech]

tcpdump так же показал задержки, а так же что происходит несколько запросов

Код: [Выделить]

16:09:00.865264 IP Web Browser.61938 > site1-vpn.domain.com.http: S 656466050:656466050(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
16:09:00.865338 IP site1-vpn.domain.com.http > Web Browser.61938: S 1293976531:1293976531(0) ack 656466051 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>
16:09:03.865250 IP site1-vpn.domain.com.http > Web Browser.61938: S 1293976531:1293976531(0) ack 656466051 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>
16:09:09.865168 IP site1-vpn.domain.com.http > Web Browser.61938: S 1293976531:1293976531(0) ack 656466051 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>
16:09:09.865606 IP Web Browser.61938 > site1-vpn.domain.com.http: . ack 1 win 256 <nop,nop,sack 1 {0:1}>
16:09:10.185391 IP Web Browser.61938 > site1-vpn.domain.com.http: P 1:829(828) ack 1 win 256
16:09:10.185456 IP site1-vpn.domain.com.http > Web Browser.61938: . ack 829 win 59
16:09:10.185972 IP site1-vpn.domain.com.http > Web Browser.61938: P 1:144(143) ack 829 win 59
16:09:10.186072 IP site1-vpn.domain.com.http > Web Browser.61938: F 144:144(0) ack 829 win 59
16:09:10.186542 IP Web Browser.61938 > site1-vpn.domain.com.http: . ack 145 win 256
16:09:10.205837 IP Web Browser.61938 > site1-vpn.domain.com.http: F 829:829(0) ack 145 win 256
16:09:10.205873 IP site1-vpn.domain.com.http > Web Browser.61938: . ack 830 win 59

Убрал Mikrotik c с пути(прописал себе маршрут) - отрабатывает моментально.
Пользователь решил продолжить мысль 04 Марта 2012, 18:54:27:Получается что CentOS получает пакет для site1-vpn.domain.com - маршрута до него у неё нет.
Она его отсылает на шлюз свой, им является Mikrotik, а у микротика маршрут, что site1-vpn.domain.com доступен через CentOS.
Пользователь решил продолжить мысль 05 Марта 2012, 01:16:18:При установлении VPN происходит переписывание таблицы маршрутизации и CentOS все пакеты напрявляет в тунель.
Без VPN шлюзом для неё является Mikrotik. В результате петля при отсутствии VPN.

[AnrDaemon]

Навскидку: Меняйте адреса назначения пакета.
А вообще странно. После редиректа пакет не должен никуда маршрутизироваться.

[slech]

поднял второй такой сервер с более новой версией OS и там всё заработало с таким же набором правил в таблице nat и цепочке FORWARD таблицы filter.

CentOS release 5.6 (Final) -- Linux 2.6.18-238.el5 i686 -- iptables v1.3.5 - не работает как нужно
CentOS release 6.2 (Final) -- Linux 2.6.32-220.el6.x86_64 x86_64 -- iptables v1.4.7 -- рабоает как нужно