Zugriff auf Weboberfläche

fischefr

Mitglied
Mitglied seit
30 Okt 2004
Beiträge
204
Punkte für Reaktionen
0
Punkte
16
Hallo zusammen!

Ich habe meine Fritzbox so aufgebohrt, dass ich Wireguard (VPN) darauf laufen lassen kann (kein Freetz). Es funktioniert soweit, nur der Login auf der Benutzeroberfläche schlägt mit "falsches Passwort" fehl. Sobald ich dem verwendeten Nutzer den Login über das Internet gestatte, funktioniert es.
Die verwendete IP stammt aus dem Netz der Fritzbox. Weiß jemand, wie die Box zwischen Zugriff aus dem LAN und dem Internet unterscheidet? Es sollte doch kein Problem sein, wenn der Request vom Netzwerkdevice "wg0" statt "lan" kommt?! Wie erkennt die Box, dass es kein normaler Zugriff ist?
 
Es sollte doch kein Problem sein, wenn der Request vom Netzwerkdevice "wg0" statt "lan" kommt?! Wie erkennt die Box, dass es kein normaler Zugriff ist?
Eben daran ... es gibt viele Funktionen in der FRITZ!Box, deren Interpretation "Internet vs. LAN" davon abhängig ist, ob das Ziel (bzw. der Ursprung eines Requests) über "dev lan" erreichbar ist oder nicht.

Wie die Firmware das genau ermittelt, wechselte auch im Laufe der Zeit - vor noch gar nicht sooo langer Zeit, wurde das anhand der Tatsache, ob ein DNS-Root-Server über ein solches Interface erreichbar war, entschieden (bzw. das "Internet" daran erkannt, daß eine Verbindung zu diesem DNS-Root-Server über das Interface gehen müßte - teilweise kann man das in alten Quellen für den "ftpd" noch nachlesen, wenn man die alten AVM-Pakete findet).

Heutzutage wird das offenbar direkt in der "libcm.so" behandelt - dort finden sich jedenfalls Funktionen, deren Namen das nahelegen:
Rich (BBCode):
$ nm -D lib/libcm.so.0.0.0 | grep "internet\|vpn" | cat
0000ad18 T is_access_from_internet
0000ad64 T is_tcpconn_peer_within_internet
0000aa20 T is_tcpconn_routed_via_vpn
Wie genau AVM das dann ermittelt, ist ohne Reverse-Engineering nur schwer zu beurteilen (alle drei Funktionen stehen in der Lib unmittelbar nebeneinander, zumindest nach den exportierten Symbolen) - und ändern kann man es ohnehin nicht (wirklich). Also ist es hier am naheliegendsten, daß man sich vergewissert, wie der "ctlmgr" da jeweils reagiert und sich dann darauf einrichtet.

Ich bin nicht mal sicher, wie sich aktuelle Firmware-Versionen bei einer "conntype_user"-Verbindung des AVM-VPN entscheiden ... zwar kriegt der Client da ja eine IP aus dem LAN, aber die Funktion "is_tcpconn_routed_via_vpn" wird sicherlich auch von irgendeiner AVM-Komponente benutzt werden und das klingt ja schon nach einem zusätzlichen Test oder auch nur einer Unterscheidung - solche Entscheidungen sind ja an vielen Stellen zu treffen.
 
OK, Danke.
Dann habe ich jetzt fürs Wochenende wieder ein paar Ansätze zum rumprobieren.
Wenn ich wg0 zum Bestandteil des interfaces lan mache...
Man wird sehen :)
 
Wenn ich mich richtig erinnere, ist es eine der Änderungen von AVM an der "sk_buff"-Struktur, da ein "net_device *input_dev" hinzuzufügen, mit dem das Interface/Device verwaltet wird, auf dem ein Paket empfangen wurde.

Probieren schadet sicherlich nichts ... aber es muß auch nicht zwingend machbar sein, das "wg0"-Interface irgendwoanders anzuflanschen und dann löst sich das alles in Luft auf. Nur noch als "Anmerkung", falls es dann doch nicht klappt und die Frage entsteht, woher AVM wissen kann (zumindest auf der Kernel-Ebene und ich vermute einfach mal, daß das der "ctlmgr" (als Userland-Programm) für eine Verbindung beim "kdsld" abfragen kann), woher ein Paket kam.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.