![](https://seccdn.libravatar.org/avatar/2a0d9f17afa936fe9558e9e32ba91b92.jpg?s=120&d=mm&r=g)
Wie sag=B4 ich es der Fritzbox, das =FCber VPN der Drucker-Rechner = gemeint ist,=20 der auf Linux l=E4uft - wo ich vielleicht auch =B4ne VPN-Verbindung = zur lokalen=20 Fritz-Box aufbauen mu=DF......
Gar nicht. Entweder die Fritzbox selbst ist Tunnelendpunkt - oder Du = hast den Tunnelendpunkt auf einem Rechner dahinter. Dann mu=DFt Du die = Fritzbox Pakete an den IP-Port des Tunnelendpunktes weiterleiten lassen.
Ist es nicht sogar Sinnvoll, openvpn auf den "Druckerrechner" = einzurichten;=20
Absolut! Ich kenne die Fritzboxen nicht: Wenn die eine DMZ bieten, = geh=F6rt der Rechner mit OpenVPN dorthin.
Hallo. ich habe hier openvpn im Einsatz (läu9ft zwar netterweise auf dem Router als Tunnelendpunkt, muss aber eben nicht sein und nraucht auch keine Durchreiche im Router. Aus Sicht des Benutzers sieht das so aus: Standort 1 hat ein Subnetz, z.B. 192.168.2.0 Standort 2 hat ein anderes Subnetz, z.B. 192.168.3.0 openvpn richtet auf beiden Rechnern eine virtuelle Netzkarte ein und routet Traffic darüber, das wird in ifconfig als PtP Verbindung angezeigt und verwendet nochmal andere IP Adressen (z.B. 192.168.50.1 und 192.168.50.2) Aus Sicht der Internetverbindung: openvpn sendet regelmässig udp Pakete an die Gegenstelle (die es über einen dyndns Namen finden sollte) und erhält von dort Antwortpakete. Deshalb ist auch in der Fritzbox kein Loch in der Firewall notwendig. Die Nutzdaten, seien es Druckaufträge oder auch nur ein Ping, um zu testen, dass in der Gegenstelle noch alle Rechner aktiv sind, werden verschlüsselt in diesen udp Paketen transportiert Der Tunnelendpunkt, also der Linux Rechner, arbeitet dabei als Router, und wenn eine FW drauf ist, muss das Tunnel-Interface zur internen Zone gehören. Der Drucker, also der CUPS Server, sollte Requests nur aus den beiden Subnetzen annehmen Etwas problematisch kann es sein, wenn dyndns Aktualisierungen nicht klappen. Hier hat es sich bewährt, in der openvpn Konfig mit "float" zu erlauben, dass zwischen dem dyndns Servernamen und der IP, von der tatsächlich Datenpakete kommen, eine Diskrepanz besteht. Erst wenn auf beiden Seiten nach dem IP Wechsel die Aktualisierung nicht klappt, bricht die Leitung zusammen. Diese Variante ist (oder war zumindest, als ich das vor einigen Jahren eingerichtet habe) nur mit statischen Keys möglich Wolfgang Hamann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org