Gerät per VPN und Ethernet-Port mit gleicher IP-Adresse mit Fritzbox verbinden

[sirpreis]

Hallo,

ich möchte folgendes bewerkstelligen, komme aber nicht weiter:

Ich habe einen Raspberry Pi, den ich gerne außer Haus als rsync-Backupziel meines NAS aufstellen möchte. Das Gerät verbindet sich per VPN (die von der Fritzbox 7390 mitgelieferte Lösung) mit der Fritzbox und erhält dort die erste IP, die nicht im IP-Adressbereich des Fritzbox-DHCP-Servers liegt (Bereich des DHCP-Servers ist 192.168.178.2 bis 192.168.178.100, das erste per VPN verbundene Gerät erhält die 101). Sollten mal größere Datenmengen anfallen und das Backup durch die nur 500 kb/s über VPN auf den Raspberry Pi zu lange dauern, hätte ich gern die Möglichkeit, das Gerät mit nach Hause zu nehmen und per Ethernet oder WLAN mit der Fritzbox zu verbinden.

Optimalerweise sollte das Gerät hier dann die gleiche IP-Adresse haben wie von extern (192.168.178.101), damit der Backupjob auch weiterhin korrekt funktioniert. Nun habe ich versucht, dem Raspberry Pi die 192.168.178.101 manuell zu vergeben, da die Adresse außerhalb des zu vergebenen Bereichs liegt. Ich erreiche dann zwar die anderen Geräte im Netz (Ping an Fritzbox), die anderen Geräte erreichen aber den Raspberry nicht. Vergebe ich anschließend eine andere Adresse oder wechsle auf DHCP, funktioniert alles einwandfrei.

Woran liegts? Gibt's eine Möglichkeit, dass das Gerät sowohl bei verbundenem VPN als auch wenn es lokale verbunden ist die gleiche IP nutzt?

Vielen Dank vorab!

 

[PeterPawn]

VPN-Verbindung deaktivieren (in der 7390), solange der RasPi im LAN ist.

 

[sirpreis]

Das wäre für mich nur eine Option, wenn sich das automatisieren ließe. Würde aber vermuten, dass das nicht gehen wird?

 

[HabNeFritzbox]

Die FB verwendet doch .200, .201 , ect. für VPN, also verwende die IP entsprechend die FB für VPN zugewiesen hat.

Wenn RasPI am anderen Standort ist, ist dort anderes Subnetz?

 

[sirpreis]

Da ich den Adressbereich für den DHCP-Server manuell angepasst habe (von 192.168.178.20 bis .100), scheint die Fritzbox für VPN dann >=192.168.178.101 zu verwenden. Ist dann ja m.E. auch das gleiche Subnetz.

 

[PeterPawn]

Das wäre für mich nur eine Option, wenn ...

Das ist aber die einzige Option (außer statischen ARP-Einträgen auf den Backup-Clients, die dann wieder nicht mehr funktionieren, wenn der RasPi nur über VPN erreichbar ist) ... die FRITZ!Box macht für jede aktivierte VPN-Verbindung vom Typ "conntype_user" Proxy-ARP für die verwendete IP-Adresse. Selbst wenn es also mal durch Zufall im LAN funktionieren sollte (weil der RasPi tatsächlich schneller antwortet als die FRITZ!Box), ist das keine dauerhafte Lösung. Am besten liest Du Dir mal etwas zum ARP-Protokoll durch und beobachtest mit einem Packet-Dump die "Stellvertreter-Antworten" der FRITZ!Box auf die Anfragen der LAN-Clients, wo sich das Gerät mit der IPv4-Adresse 192.168.178.101 wohl befinden mag.

 

[HabNeFritzbox]

Wenn am anderen Standort selbe Subnetz ist, funktioniert kein VPN.

Daher sollte man auch Standard IP´s vermeiden.

 

[PeterPawn]

@HabNeFritzbox:
Es steht doch in #1 ganz klar da, daß das VPN funktioniert ... es handelt sich hier (sieht man ja daran, daß der VPN-Client eine IP-Adresse aus dem LAN erhält) um eine Verbindung für einen Benutzer(!) und da spielt dann #7 gar keine Rolle bzw. stimmt in der Grundaussage nicht.

 

[HabNeFritzbox]

Wenn RasPi woanders im selben Subnet ist, und dann in diesem auch noch eine IP über VPN bekommt, weiß der RasPi doch nicht wohin mit den Daten, bzw. würde doch ggf. auf die LAN Verbindung fallen, da diese doch höhere Prio haben müsste in der Metric.

 

[thtomate12]

Ich suche auch noch eine automatisierbare Lösung zum (De-)Aktivieren der VPN-Verbindung... und bin kurz davor das Webinterface zu nutzen

 

[PeterPawn]

@HabNeFritzbox:
Ich nehme mal an, daß die VPN-Verbindung einfach nicht aktiviert wird, wenn sich der RasPi im LAN befindet.

Damit gehört die 192.168.178.101 dann auf dem RasPi auf das lokale Ethernet-Interface in diesem Falle - das muß ja ohnehin umkonfiguriert werden auf dem RasPi; notfalls ließe es sich per Skript automatisieren - wenn die 192.168.178.1 auch ohne IPSec erreichbar ist, bootet der RasPi im LAN. Die Notwendigkeit des Bootens unterstelle ich einfach mal, der wird kaum auf Batterien durch die Gegend getragen werden.

Es macht ja auch keinen Sinn, im LAN die Daten erst noch durch den (schwachen) Prozessor der 7390 zu jagen, nur damit sie auf dem (ebenfalls schwachen) RasPi wieder entschlüsselt werden können.

@thtomate12:
Bei "stock firmware" wird Dir nichts anderes bleiben ... wobei AVM einen Entwickler u.a. auch für TR-069 (TR-064 wäre ja ein Subset) sucht, vielleicht tut sich da ja noch etwas an diesen Schnittstellen.

Für das Einrichten einer VPN-Verbindung gibt es wohl eine Möglichkeit per TR-069, für das (De-)Aktivieren kenne ich auch keine ... das mache ich nun schon seit Jahren über die passende Kommunikation mit einem Skript (einfach per "nc" gestartet) auf einem "custom port", da kann man dann auch gleich noch den Status abfragen (und das in kürzeren Intervallen als bei direkter Lua-Abfrage über das GUI).

PS: Wobei man es auch über den "Einzelimport" einer VPN-Verbindung mit demselben Namen (halt mit wechselndem "enabled"-Attribut) lösen kann ... das hat zumindest den Vorteil, daß man nur den passenden HTTP-Aufruf über "firmwarecfg" tätigen muß und nicht noch die Checkboxen in der Liste "nachbilden" muß (dazu muß man sie ja auch erst einmal auslesen aus dem (inzwischen asynchronen) Ergebnis der Abfrage).

 

[sirpreis]

@thtomate12:
Bei "stock firmware" wird Dir nichts anderes bleiben ... wobei AVM einen Entwickler u.a. auch für TR-069 (TR-064 wäre ja ein Subset) sucht, vielleicht tut sich da ja noch etwas an diesen Schnittstellen.

Lässt sich mit Freetz was machen (läuft auf meiner)? Falls ja, wie?

 

[PeterPawn]

Etwas wenig Information ... aber ja, da kann man etwas machen.

Wie das genau geht (es ist eine einzelne Eigenschaft der VPN-Verbindung, die man über ctlmgr_ctl oder über "set.lua" ändern kann), steht erstens schon irgendwo und ehe ich jetzt zweitens zu einer ausführlicheren Schilderung aushole, wüßte ich gerne, wie ernst es Dir mit der Umsetzung ist (ich habe keinen Bock, hier 10 Minuten zu schreiben und dann ist das Ergebnis wieder "hört sich kompliziert an" (ist es nicht) und "dann lasse ich es lieber bleiben", hatte ich gerade erst wieder bei jemand anderem als "Erfahrung", auf die ich locker hätte verzichten können).

 

[sirpreis]

Ich würde mich freuen, wenn du dir Zeit nehmen würdest. Es ist nun aber nicht so, dass ich darauf angewiesen bin, dass dies umgesetzt wird. Tatsächlich wird es vermutlich eher relativ selten vorkommen, dass der Pi mit nach Hause genommen wird. Es wäre sicherlich "nice to have", wenn ich in solchen seltenen Fällen nicht daran denken muss, vor dem Anschalten des Pis das VPN in der Fritzbox zu deaktivieren. Es wäre aber auch kein Beinbruch.

Was würdest du denn für Informationen benötigen?

 

[PeterPawn]

Na ja, schon mal das Modell der FRITZ!Box und die verwendete Basis-Version wäre recht nett, ebenso die Information, welche Freetz-Pakete denn nun verwendet werden ... ist es eine NAND-basierte Box, läßt sich so etwas tatsächlich sogar als "add-on" über das "yaffs2"-Dateisystem in der /wrapper-Partition realisieren (so, wie es "modfs-Starter" auch macht, bei Freetz läßt sich so etwas ja dann sogar über ein Firmware-Update aktivieren).

Ansonsten ist das "Umschalten" so einer Verbindung ziemlich simpel ... am ehesten kann man dazu die Skript-Files von https://github.com/PeterPawn/YourFritz/tree/master/luavar verwenden.

Das Auslesen der Verbindungen ginge dann etwa so:

$ echo "VPN=vpn:settings/connection/list(activated,name)" | queries.lua
VPN_1_index="connection0"
VPN_1_activated="0"
VPN_1_name="Udligenswil"
VPN_2_index="connection1"
VPN_2_activated="1"
VPN_2_name="Waldacker"
VPN_3_index="connection2"
VPN_3_activated="0"
VPN_3_name="Traunstein"
VPN_4_index="connection3"
VPN_4_activated="0"
VPN_4_name="Graz"
VPN_5_index="connection4"
VPN_5_activated="0"
VPN_5_name="Vachendorf"
VPN_6_index="connection5"
VPN_6_activated="0"
VPN_6_name="Salzburg"
VPN_7_index="connection6"
VPN_7_activated="0"
VPN_7_name="Hanau"
VPN_8_index="connection7"
VPN_8_activated="0"
VPN_8_name="Source"
VPN_9_index="connection8"
VPN_9_activated="1"
VPN_9_name="Basdorfer"
VPN_10_index="connection9"
VPN_10_activated="0"
VPN_10_name="Ulm"
VPN_11_index="connection10"
VPN_11_activated="0"
VPN_11_name="Zuerich"
VPN_12_index="connection11"
VPN_12_activated="0"
VPN_12_name="Luzern"
VPN_13_index="connection12"
VPN_13_activated="0"
VPN_13_name="Garten"
VPN_14_index="connection13"
VPN_14_activated="0"
VPN_14_name="central"
VPN_count=14

und aus diesen Variablen sucht man sich dann die richtige Verbindung heraus, die man wiederum mit

$ echo "vpn:settings/connection1/activated=0" | set.lua
OK

umschalten kann (0 - deaktiviert).

Ansonsten kann man das natürlich auch noch in ein passendes Lua-Skript (analog zu queries.lua und set.lua) packen, das dann selbst den richtigen Index (anhand des übergebenen Namens) ermittelt und gleich das (De-)Aktivieren auch noch übernimmt.

Den Aufruf so eines Skript-Files (egal ob Shell oder Lua), kann man dann - je nach eigenen Sicherheitsanforderungen - beliebig organisieren, da gibt es viel zu viele individuelle Aspekte, als daß da eine generelle "Empfehlung" sinnvoll wäre.

Ich habe z.B. neben den (üblicherweise deaktivierten) VPN-Verbindungen aus der o.a. Liste auf den "Zielgeräten" noch ein Shell-Skript hinter einem "stunnel"-Server laufen, der nur über eine TLS-Verbindung mit einem passenden Client-Zertifikat (dann aber auch aus dem Internet) angesprochen werden kann und auf diesem Weg wird dann von mir "auf dem Peer" das VPN aktiviert, nachdem die passende Verbindung auf meiner Box ebenfalls aktiviert wurde (meine 7490 ist bis auf zwei Verbindungen immer nur "responder"). Diese "Serverrolle" übernimmt dann ein passend gepatchtes "stunnel"-Paket mit dem FRITZ!OS-Zertifikat (aus meinem Freetz-Fork auf GitHub) und den Client gibt wiederum meine eigene 7490 (auch mit ihrem Zertifikat für die Client-Authentifizierung), wenn dort eine VPN-Verbindung aktiviert wird. Alle notwendigen Angaben (DynDNS-Adresse usw.) für den zu (de-)aktivierenden Peer kann man ja wieder aus der VPN-Konfiguration auslesen (die zwei Attribute oben beim Auslesen sind ja nur ein Beispiel, da gibt es noch einige weitere Angaben, sogar die Peer-IP bei aufgebauter VPN-Verbindung).

 

[sirpreis]

Danke für die ausführliche Antwort! Werde ich mir in den nächsten Tagen näher ansehen. Das "klingt kompliziert" kann ich aber selbst aus studierter Informatiker nachvollziehen, wenn man rein gar nicht in der Thematik steckt ;-)

 

[sirpreis]

So, hier noch einige Informationen zur Box:

Boxtyp 7390
AVM-Firmwareversion 06.30
Kernelversion 2.6.28.10 (gcc version 4.8.1 (Buildroot 2013.05) )
Freetz-Version freetz-devel-13633

Installiert sind aktuell nur dnsmasq und das onlinechanged-cgi, also äußerst überschaubar. Ließe sich bei Bedarf natürlich ergänzen.

Bekomme die VPN-Verbindung mithilfe deiner lua-Scripte erfolgfach aktiviert und deaktiviert, vielen Dank.

Als Trigger hätte ich mir vorgestellt, sofern umsetzbar, dass die VPN-Verbindung deaktiviert wird, sobald sich eine der beiden MAC-Adressen (WLAN und Ethernet) des Clients (Raspberry Pi) mit der Fritzbox verbindet. Also irgendwie bevor der DHCP-Server seine Adresse vergibt. Hast du dazu eine Idee?

 

[PeterPawn]

Ich sehe gerade nicht, was ein DHCP-Server in diesem Szenario jetzt soll ... der RasPi muß ja seine Adresse selbst setzen (statisch), solange die FRITZ!Box (genauer deren "multid") den DHCP-Server im LAN gibt. Die FRITZ!Box wird dem RasPi nicht die .101 per DHCP im LAN zuteilen - diese Adresse liegt für den "multid" außerhalb seiner Range.

Wann genau die FRITZ!Box jetzt die entsprechenden Events für "neuer WLAN-Client" erzeugt, weiß ich nicht ... ich würde das Triggern auch nicht der FRITZ!Box überlassen.

Da der RasPi ohnehin einen Mechanismus zur Detektion braucht, daß er direkt im LAN ist (er muß/soll ja sein Ethernet-Interface passend konfigurieren), kann der doch auch gleich noch das Deaktivieren der VPN-Verbindung anstoßen ... dafür reicht ja schon ein passendes UDP-Paket (kann man mit "nc" erzeugen) an ein Skript, das auf der FRITZ!Box im LAN auf dieses eingehende Paket wartet/lauscht.

Das hat zumindest den Vorteil, daß es (im engeren Sinne) nur einen einzelnen Trigger gibt. Macht man das dann noch als "heartbeat"-Signal (meinetwegen alle 15 Sekunden ein UDP-Paket), kann man beim Ausbleiben dieses Signals auch die VPN-Verbindung auf der FRITZ!Box automatisch wieder aktivieren - dann sorgt schon das Abschalten des RasPi im LAN mit kurzer Verzögerung dafür, daß der "normale Zustand" wiederhergestellt wird. Befindet sich der RasPi nicht im LAN, sendet er dieses Heartbeat-Paket einfach nicht (oder meinetwegen ein anderes, wenn diese "Überwachung" auch noch anderweitig genutzt werden kann).

 

[sirpreis]

Du hast natürlich recht.. DHCP ist hier gar nicht relevant.

Dein Vorschlag klingt sicher sinnvoll. Zum Verständnis:

1. Verbinde ich den Pi mit bereits statisch gesetzter Adresse .101 per Ethernet oder WLAN mit der Fritzbox, sende dann das UDP-Paket, das wiederum auf der Fritzbox das Deaktivieren der VPN-Verbindung bewirkt? Oder muss ich dem Pi vorher eine Adresse aus dem DHCP-Adressbereich geben, und nach Deaktivierung dann auf die .101 wechseln?
2. Womit/Wie lausche ich auf der Fritzbox auf dieses Paket?

 

[PeterPawn]

Zu 1: Ja, statische Adresse setzen und UDP-Paket senden ... da bei UDP ja keine Antwort der FRITZ!Box an den RasPi erforderlich ist (das ginge bei TCP natürlich so nicht), stört es nicht, wenn beim Eintreffen des UDP-Paketes aus dem LAN die Antwort noch an das falsche Interface der FRITZ!Box gehen würde (also an "dev dsl" statt an "dev lan"), weil es eben erst einmal keine Antwort (vor dem Deaktivieren der VPN-Verbindung) braucht. Nach dem Deaktivieren macht die FRITZ!Box dann auch für die .101 wieder ARP zur Ermittlung der MAC-Adresse - bei aktiver VPN-Verbindung (nicht nur bei aufgebauter) sieht sie sich ja selbst als Proxy für die MAC-Adresse der .101. Es reicht also aus, die .101 einmalig zu setzen ... irgendwelche Änderungen nach dem Deaktivieren braucht es (m.E., aber vielleicht sehe ich auch irgendeine Randbedingung gerade nicht) nicht.

Zu 2: Eine Möglichkeit wäre das "udpsvd"-Applet der Busybox ... muß ggf. in Freetz erst noch konfiguriert werden vor dem Build. Damit kann man bei einem eingehenden UDP-Paket auf einem angegebenen Port ein Programm starten ... da hier der Inhalt der UDP-Pakete nicht wirklich interessiert (kriegt das gestartete Programm auf stdin), reicht dafür schon ein Shell-Skript, welches einfach nur den Zeitstempel einer Datei als Semaphore aktualisiert ... ein weiterer Prozess schaut dann per Polling nach dieser Semaphore und aktiviert/deaktiviert die VPN-Verbindung in Abhängigkeit vom Zeitstempel für diese Datei.

Wenn man unbedingt das Umschalten der VPN-Verbindung an den RasPi quittieren will (dort kann man mit "netcat" z.B. ein UDP-Paket senden), muß man natürlich auf dem RasPi lange genug warten, damit die Antwort nach dem Umschalten der VPN-Verbindung dann auch noch ankommt (und man muß den Remote-Port auf der FRITZ!Box an das Umschalt-Skript durchreichen, damit das dann weiß, wo der RasPi die Antwort erwartet) ... welche Intervalle man da wählt, hängt von den eigenen Anforderungen an die "responsiveness" der Lösung ab.