Richtlinienrouting für OpenVPN-Server und -Client auf demselben Router?

PROBLEM

Eine OpenVPN- Serverinstanz ( tun, udp, Port 1194) auf einem Linux-basierten Router einzurichten, die auch eine OpenVPN Client - Instanz läuft ( tun, udp, Port 1197) an einen VPN - Provider verbindet. Sowohl die Client- als auch die Serverinstanz funktionieren einzeln einwandfrei . Clients können jedoch keine Verbindung zum VPN-Server herstellen, wenn die VPN-Clientinstanz aktiviert ist.

Ich bin mir sicher, dass dies der Fall ist, weil die VPN-Clientinstanz die mainRouting-Tabelle so ändert, dass der gesamte Datenverkehr von ( OUTPUT) und durch ( FORWARD) vom Router an den VPN-Anbieter geleitet wird. Dies ist das gewünschte Standardverhalten, jedoch nicht für Verbindungen, die über das Internet initiiert werden.

Verwenden iptablesund / oder ip, wie kann eine Routing - Richtlinie festgelegt werden, so dass alle (oder zumindest VPN) Verbindungen aus dem Internet initiiert werden über den Standard - Standard - Gateway geroutet ( 192.168.1.1)?

KONFIGURATION

LINUX ROUTER ----------------------------------------- | LAN if: br-lan, 192.168.2.1/24 | | VPN client if: tun0, 10.63.10.6/32 | | VPN server if: tun1, 10.255.0.1/24 | | DMZ if: eth0, 192.168.1.2/24 | ----------------------------------------- | GATEWAY ROUTER | -------------------------- | DMZ if: 192.168.1.1/24 | | WAN if: x.x.x.x/x | -------------------------- | INTERNET | VPN CLIENT OF LINUX ROUTER (public IP: y.y.y.y/y) ----------------- -------------------------------------- | |----| VPN client if: tun1, 10.255.0.6/24 | ----------------- -------------------------------------- | | VPN PROVIDER OF LINUX ROUTER --------------------------------  | VPN server if: 10.63.10.1/32 | -------------------------------- 

Wie Sie feststellen werden, befinden wir uns hier in einer doppelten NAT-Situation. So unangenehm es auch sein mag, ist dies nicht das Problem, da Clients eine Verbindung herstellen können, wenn die VPN-Clientinstanz deaktiviert ist.

Mit den VPN - Client und Server - Instanzen aktivierten, ist dies die mainRouting - Tabelle als gegeben an, durch ip route list table main:

0.0.0.0/1 via 10.63.10.5 dev tun0 #added by VPN client instance default via 192.168.1.1 dev eth0 proto static  10.63.10.1 via 10.63.10.5 dev tun0 #added by VPN client instance 10.63.10.5 dev tun0 proto kernel scope link src 10.63.10.6 #added by VPN client instance 10.255.0.0/24 via 10.255.0.2 dev tun1  10.255.0.2 dev tun1 proto kernel scope link src 10.255.0.1  128.0.0.0/1 via 10.63.10.5 dev tun0 #added by VPN client instance 178.162.199.211 via 192.168.1.1 dev eth0 #added by VPN client instance 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2  192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1  

und dies sind die IP-Regeln, die gegeben sind durch ip rule list:

0: from all lookup 128 #a non-existent table 1: from all lookup local  32766: from all lookup main  32767: from all lookup default #empty table 

VERSUCHE

Zuerst habe ich eine no_vpn_providerRouting-Tabelle ( echo "2 no_vpn_provider" >> /etc/iproute2/rt_tables) erstellt, eine exakte Kopie der mainTabelle ohne Änderungen der VPN-Client-Instanz. ip route list table no_vpn_providerzeigt an

default via 192.168.1.1 dev eth0 proto static  10.255.0.0/24 via 10.255.0.2 dev tun1  10.255.0.2 dev tun1 proto kernel scope link src 10.255.0.1  192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2  192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1 

1) Ich habe diese einfachen ipRegeln ausprobiert

ip rule add from 192.168.1.2 table no_vpn_provider priority 2 ip rule add from 10.255.0.1 table no_vpn_provider priority 3 

wobei 192.168.1.2und 10.255.0.1sind die IP-Adressen der externen Schnittstelle eth0bzw. der VPN-Server-Schnittstelle tun1.

Ich habe auch versucht from all iif eth0und from all iif tun1statt from 192.168.1.2und from 10.255.0.1.

2) Ich habe versucht, mit 0x1neuen Verbindungen (das conntrackModul ist installiert) an den Schnittstellen eth0und zu kennzeichnentun1

iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -i eth0 -j CONNMARK --set-mark 0x1 iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -i tun1 -j CONNMARK --set-mark 0x1 

und fügen Sie diese Regel hinzu, damit markierte Verbindungen die neue Routingtabelle verwenden

ip rule add fwmark 0x1 table no_vpn_provider priority 2 

3) Ich habe versucht, ausgehende Pakete vom VPN-Serverport zu markieren1194

iptables -t mangle -A OUTPUT -p udp --sport 1194 -j MARK --set-mark 0x1 iptables -t mangle -A OUTPUT -p tcp --sport 1194 -j MARK --set-mark 0x1 # just in case 

und nach derselben Regel

ip rule add fwmark 0x1 table no_vpn_provider priority 2 

Ich habe auch 2) und 3) mit verschiedenen Markierungen und mit inserting ( -I) anstelle von appending ( -A) versucht . Ich hatte den Verdacht, dass meine Firewall überhaupt keine Markierungen hatte

iptables -t mangle -A FORWARD -s 192.168.2.0/24 -j MARK --set-mark 0x1 ip rule add fwmark 0x1 table no_vpn_provider priority 2 

Wie erwartet wurden jedoch Pakete aus meinem LAN nicht an den VPN-Anbieter weitergeleitet.

4) Das einzige, was bisher funktioniert, ist diese hässliche Regel

ip rule add from all to y.y.y.y/y table no_vpn_provider priority 2 

Dabei ist yyyy / y die öffentliche IP-Adresse des Clients, der versucht, eine Verbindung herzustellen: Dies ist natürlich eine schreckliche Lösung, da die Clients nicht immer vom selben Netzwerk aus eine Verbindung herstellen.