kieruj ruch http i ssh normalnie, wszystko inne przez tunel VPN

Czytam to trochę i blisko, czuję to i wyrywam włosy ...

Zapraszamy

Wsparcie!
Mam klienta OpenVPN, którego serwer konfiguruje trasy lokalne i domyślnie zmienia gw (wiem, że mogę temu zapobiec za pomocą --route-nopull). Chciałbym cały wychodzący ruch http i ssh przez lokalną gw, a wszystko inne przez VPN.

• Lokalny adres IP to 192.168.1.6/24, gw 192.168.1.1.
• Lokalny adres IP OpenVPN - 10.102.1.6/32, gw 192.168.1.5
• Serwer OpenVPN znajduje się pod adresem {OPENVPN_SERVER_IP}

Oto tablica tras po podłączeniu openvpn:

# ip route show table main

0.0.0.0/1 via 10.102.1.5 dev tun0 

default via 192.168.1.1 dev eth0  proto static 

10.102.1.1 via 10.102.1.5 dev tun0 

10.102.1.5 dev tun0  proto kernel  scope link  src 10.102.1.6 

{OPENVPN_SERVER_IP} via 192.168.1.1 dev eth0 

128.0.0.0/1 via 10.102.1.5 dev tun0 

169.254.0.0/16 dev eth0  scope link  metric 1000 

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.6  metric 1

To zmusza wszystkie pakiety do przejścia przez tunel VPN, z wyjątkiem tych przeznaczonych dla 192.168.1.0/24.
Robić

       wget -qO- [url=http://echoip.org]http://echoip.org[/url]

     

pokazuje adres serwera VPN zgodnie z oczekiwaniami, pakiety mają 10.102.1.6 jako adres źródłowy (lokalny adres IP VPN) i są kierowane przez

       tun0

     

... jak donosi

       tcpdump -i tun0

     

(

       tcpdump -i eth0

     

nie widzi ruchu).
Próbowałem:

• utwórz drugą tablicę routingu zawierającą informacje o routingu 192.168.1.6/24 (skopiowane z

           main       

  tabela powyżej)
• Dodaj

           iptables -t mangle -I PREROUTING       

  reguła oznaczania pakietów przeznaczonych na port 80
• Dodaj

           ip rule       

  dopasować zniekształcony pakiet i skierować go do drugiej tablicy routingu
• dodaj regułę IP dla

           to 192.168.1.6       

  i

           from 192.168.1.6       

  wskaż drugą tablicę routingu (chociaż jest to nadmiarowe)
• zmieniono sprawdzanie filtru IPv4 na brakujące w

           net.ipv4.conf.tun0.rp_filter=0       

  i

           net.ipv4.conf.eth0.rp_filter=0       

Ja też próbowałem

       iptables mangle output

     

zasada

       iptables nat prerouting

     

reguła. Nadal nie działa i nie jestem pewien, czego mi brakuje:

•          iptables mangle prerouting       

  : pakiet nadal przechodzi przez VPN

•          iptables mangle output       

  : przekroczono limit czasu pakietu

Czy nie jest tak, aby osiągnąć to, czego chcę, kiedy robię

       wget [url=http://echoip.org]http://echoip.org[/url]

     

Czy powinienem zmienić adres źródłowy pakietu na 192.168.1.6 przed jego routingiem? Ale jeśli to zrobię, odpowiedź z serwera http jest przekierowywana z powrotem do 192.168.1.6 i

       wget

     

nie zobaczy tego, ponieważ nadal jest z nim związane

       tun0

     

(interfejs VPN)?
Czy miła dusza może pomóc? Jakie polecenia uruchomiłbyś po podłączeniu openvpn, aby osiągnąć to, czego chcę?
Czekamy na porost włosów ...