[Gelöst] OpenVPN: Traffic der Fritz!Box über VPN-Service routen

[bStuB]

Nach gefühlten 20 Stunden eigenständiger Arbeit, welche sich über das gesamte vergangene Wochenende verteilt und sich auch heute einen gewissen Anteil genommen haben, gebe ich nun auf. Ich bin mit meinem Wissen echt am Ende und erbitte nun eure Hilfe.

Mein Ziel ist es, den gesamten Traffic der Fritz!Box über einen VPN-Service, für den ich bezahle, zu schleusen (d.h., ich habe keinen Zugriff auf Serverkonfigurationen).

Zuerst etwas zum VPN-Service: Der Server hat dieselbe IP und mir wird VPN-intern dieselbe IP zugewiesen.

Nun zur Fritz!Box: Fon WLAN 7141, Firmware 41.04.76, geflasht mit freetz-devel-11050, also der aktuelle Trunk. Zusatzpakete sind eben OpenVPN 2.3 mit den ganzen nicht abwählbaren Komponenten wie OpenSSL und so. Dazu das Webinterface avm-firewall.

Noch etwas zur Geschichte. 18 Stunden davon verbrachte ich mit dem Versuch, es mit OpenVPN 2.1 (ebenfalls openssl) und iptables zu vollenden. 18 Stunden Such-, Build-, Flash-, und Configarbeit. Ich habe sogar unerwartet viel Neues über iptables gelernt, hat also auch seine Vorteile gehabt. Problem ist aber dieses hochbescheuerte Routing, der Internet-Verkehr der Geräte im LAN wollte einfach nicht durch den Tunnel und ich hatte eben immer noch die ISP-IP.

So nun. Ich habe den Trunk genommen, weil ich, durch die SuFu hier, in einem Post gelesen habe, dass im aktuellen Trunk OpenVPN in der Version 2.3 enthalten ist und es keine probleme mit dem Routing geben soll. Nun hab ich es versucht. BÄM, keines der Geräte hat Internet gehabt, hatte also denselben Blödsinn wie wenn ich auf dem "alten" release die Routen mittels route in der Rudi-Shell geändert habe. Firefox sagte permanent "Verbinde zu [Website]", tracert (auf Windows) endete mit timeouts nach dem ersten Hop, und zwar der zur Fritz!Box.

Führt man in der Rudi-Shell netstat -nr aus, kommt dies hier.

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
46.165.208.65   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.180.1   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
10.4.72.225     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.4.0.1        10.4.72.225     255.255.255.255 UGH       0 0          0 tun0
84.133.0.131    0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.178.0   0.0.0.0         255.255.255.0   U         0 0          0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 lan
0.0.0.0         10.4.72.225     128.0.0.0       UG        0 0          0 tun0
128.0.0.0       10.4.72.225     128.0.0.0       UG        0 0          0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 dsl

Leider sehe ich momentan einfach nicht das Problem dabei.

ifconfig zu tun0

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.4.72.226  P-t-P:10.4.72.225  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:1344 (1.3 KiB)

Ich habe bemerkt, dass es nach einer Zeit immer mehr TX (transmit) packets gibt; das sind keepalives. Die Zahl der RX (receive) packets bleibt aber nahezu konstant bei 0.

Ich würde daraus schließen, dass es ein Problem mit dem Routing der vom VPN-Server kommenden Pakete gibt. Meine Idee wäre eventuell iptables zu benutzen, aber die Regeln sind immer sone Sache. MASQUERADE ist klar, doch was danach folgt, wird im Internet immer und immer anders vorgeschlagen. Mal mit SNAT, mal mit DNAT, mal beides, mal gar nicht, und das verwirrt einen doch sehr.

Weitere Versuche: Rein aus Neugierde Kernel-Replacement mit gemessenen 0.1 Veränderungen. Die Update-Datei ist größer; komischerweise noch im Rahmen des Möglichen, aber keine Wirkung auf die Verbindung.

Ich danke schon einmal jedem, der sich eigene Zeit nimmt, sich meinem Problem zu widmen und wünsche einen guten Abend, eine gute Nacht oder schon einmal guten Morgen oder einen guten Tag im Voraus.

bStuB

 

[RalfFriedl]

Die Probleme mit dem Routing stammen vermutlich nicht von OpenVPN, sondern von dem, das AVM an den normalen Linux-Funktionen vorbei gemacht hat.
Aus der Beschreibung gehe ich mal davon aus, dass die VPN Verbindung aufgebaut wird. Ist die VPN-Verbindung von der Box aus nutzbar?
Ohne NAT wird der Zugriff von den Rechnern im Netz nicht funktionieren. Mit MASQUERADE wird es sicher funktionieren, SNAT ist auch eine Möglichkeit, wenn Deine IP-Adresse immer gleich bleibt. DNAT ist etwas anderes.

Statt Rudi-Shell solltest Du besser Putty nehmen, Rudi steht für Rudimentär.
Wenn der Platz reicht, solltest Du noch tcpdump mit ins Image aufnehmen, das ist bei solchen Problemen sehr hilfreich. Damit kannst Du sehen, welche Pakete auf welchem Interface kommen und gehen. Wenn der Platz im Image nicht reicht, kannst Du es einmal erstellen und dann bei Bedarf ins RAM der Box laden.

 

[bStuB]

Hallo, danke für die Antwort.

Ja, die VPN-Verbindung steht und kann genutzt werden.
Würde diese Regel hier es richtig maskieren?

-t nat -A POSTROUTING -o tun0 -j MASQUERADE

Und welche Regeln soll(t)en sonst noch angewendet werden?

 

[RalfFriedl]

Die Regel sollte passen, wenn nicht, schau, was tcpdump dazu sagt.

Fürs NAT sollte die Regel reichen, was Du sonst noch willst, musst Du selbst entscheiden.
Du könntest sicherheitshalber den eingehenden Verkehr auf tun0 blockieren.

-A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i tun0 -j DROP

 

[bStuB]

Saving iptables/rules ... done.
Writing 8728 bytes to /var/flash/freetz ... done.

Flushing rules and unloading modules ... rmmod: can't unload 'ip_conntrack': Resource temporarily unavailable
rmmod: can't unload 'ipt_REJECT': unknown symbol in module, or unknown parameter
rmmod: can't unload 'ip_tables': Resource temporarily unavailable
done.
Loading modules ... modprobe: can't load module ipt_REJECT (kernel/net/ipv4/netfilter/ipt_REJECT.ko): unknown symbol in module, or unknown parameter
done.
Loading table list ... iptables-restore: line 1 failed
done.

Will ich die Regel über den Menüpunkt "Regeln" übernehmen, kommt das hier. Und das entzieht sich vollständig meinem Verständnis...
Ich habe beim Builden alle packages ausgewählt außer denen, die in den IPv4 and IPv6 shared libraries. Ich kann mir nicht vorstellen, dass zB.

modprobe ipt_REJECT
modprobe: module ipt_REJECT can't load module ipt_REJECT (kernel/net/ipv4/netfilter/ipt_REJECT.ko): unknown symbol in module, or unknown parameter

das da sagt.

 

[bStuB]

Problem selbstständig gelöst. Das Problem kommt immer, wenn ich es über die Oberfläche einstellen will. Über SSH kann ich das aber eingeben und dann gehts auch... unglaublich, nach 23 Stunden Arbeit geht nun auch das. Danke, RalfFriedl, dass du bestätigt hast, dass ich diese iptables-Regeln brauche. Ich fühl mich einfach nice, nach 23 Stunden sowas festzustellen.

 

[bStuB]

Ich hab aber noch ein Problem:

VoIP muss über die Internet-Leitung gehen, da ansonsten das Telefon nicht erreichbar ist. Gibt es dazu auch eine iptables-Regel, die ich anwenden kann?

 

[MaxMuster]

Das machst du am einfachsten per "normalem" Routing. Ermittle die IP-Adressen des/r VoIP Server(s) und route diese als Host-Adressen über das Device "dsl".
Vermutlich musst du auch den DNS-Server wechseln, weil viele Provider nur ihren eigenen Adress-Space bedienen und du jetzt ja per VPN-IP ankommst.

 

[RalfFriedl]

DNS geht sowieso über DSL, durch die beiden Einträge 192.168.180.1 und 192.168.180.2 in der Routing Tabelle. Diese beiden Adressen werden als Nameserver verwendet, und im dsl Interface auf die externen Adressen umgesetzt.

 

[MaxMuster]

Die Probleme gibt es m. W. immer nur für die Namensauflösung initiiert von der Box selbst (/etc/resolv.conf), z.B. um den Namen des SIP-Servers aufzulösen.
Kann man aber problemlos testen, ob auf der Box bei verbundenem VPN ein "ping -c 1 www.zdf.de" klappt (oder ein anderer Name, der nicht gecached ist)

 

[bStuB]

Ich hatte nochmal die SuFu benutzt gehabt, und habe auch herausgefunden, dass ich dies einfach per route -add routen kann.

dig tel.t-online.de

; <<>> DiG 9.7.0-P1 <<>> tel.t-online.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15753
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;tel.t-online.de.		IN	A

;; ANSWER SECTION:
tel.t-online.de.	242	IN	CNAME	ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de.	85561	IN	CNAME	ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de.	85561	IN	CNAME	m-ipp-a01.isp.t-ipnet.de.
m-ipp-a01.isp.t-ipnet.de. 19	IN	A	217.0.16.42

;; AUTHORITY SECTION:
t-ipnet.de.		85561	IN	NS	dns00.btx.dtag.de.
t-ipnet.de.		85561	IN	NS	dns50.t-ipnet.de.
t-ipnet.de.		85561	IN	NS	secondary004.dtag.net.
t-ipnet.de.		85561	IN	NS	pns.dtag.de.
t-ipnet.de.		85561	IN	NS	dns02.btx.dtag.de.

;; ADDITIONAL SECTION:
pns.dtag.de.		1900	IN	A	194.25.0.125
dns00.btx.dtag.de.	85559	IN	A	194.25.2.132
dns02.btx.dtag.de.	85559	IN	A	194.25.2.131
dns50.t-ipnet.de.	30955	IN	A	217.5.100.185
secondary004.dtag.net.	8151	IN	A	195.244.245.27

;; Query time: 60 msec
;; SERVER: 192.168.178.254#53(192.168.178.254)
;; WHEN: Tue Oct  1 13:29:04 2013
;; MSG SIZE  rcvd: 331

Für alle "Nachkommen": Führt wie oben DiG aus, als Parameter halt die Domain der Gegenstelle fürs VoIP, hier tel.t-online.de, und routet nicht nur die IP in der Answer Section über dsl, sondern auch alle anderen IPs in der Additional Section. Welche davon nun nicht geroutet werden müssen, ist mir Wurst gewesen; vorsichtshalber routet alles über dsl, was dort angegeben wird. Bei mir hat das Routen bloß einer IP nicht funktioniert.

Demnächst werde ich im Forum mal eine gute Anleitung posten. Und jetzt sagt mir doch einer, wie ich die Überschrift so abändere, dass da gelöst steht und nicht Problem.

 

[MaxMuster]

Schön.
Titel ändern: Erster Beitrag "Bearbeiten" und dann "erweitert". Dann läßt sich auch der Titel ändern ;-)