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 eth0nie 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
ifrom 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
inet.ipv4.conf.eth0.rp_filter=0
Ja też próbowałem
iptables mangle outputzasada
iptables nat preroutingreguła. Nadal nie działa i nie jestem pewien, czego mi brakuje:
iptables mangle prerouting
: pakiet nadal przechodzi przez VPNiptables 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
wgetnie 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 ...
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
1 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
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ół.
... 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.
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.