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 ...
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

         0.0.0.0/1 via 10.102.1.5 dev tun0
To Twój problem.
0.0.0.0/1 to niesamowicie duży zakres adresów IP (0.0.0.0 - 127.255.255.255) i jest to pierwszy wpis w twojej tablicy routingu, więc każdy adres IP mieszczący się w tym zakresie będzie zmuszony do kierowania w dół.
         tun0
... Zakres jest tak szeroki, że obejmuje większość rutowalnej przestrzeni IP w Internecie. Więc echoip.org, który dla mnie rozwiązuje 69.163.172.52, jest zawarty w 0.0.0.0/1 (0.0.0.0 - 127.255.255.255).
Aby sprawdzić, czy mam rację, spróbuj wget

http://serverfault.com
http://serverfault.com
który dla mnie rozwiązuje się na 198.252.206.16 i zobaczę, czy pochodzi z eth0. Powinien, ponieważ jest poza zakresem (0.0.0.0 - 127.255.255.255).
Ogólnie rzecz biorąc, zwykle określam moją przestrzeń IP tun0 tak szczegółowo, jak to tylko możliwe.
         10.102.0.0/16 via 10.102.1.5
na przykład.
Jeśli Twoim celem nie jest kierowanie całego ruchu internetowego przez określony punkt wyjścia ze względów bezpieczeństwa/monitorowania, spróbuję zawęzić przestrzeń adresów IP tunelu.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się