Drucken über VPN - CCD Files
Hallo,
ich habe einen Ubuntu Server mit CUPS. Zusätzlich folgendes Setup:
Smartphone mit Internet welches Internet per WLAN an einen Router TP Link WR841N bereitstellt.
An diesen Router sind angeschlossen:
Ein PC mit Windows, und zwei Drucker.
Alle Geräte erhalten die IP also vom Router. Nun habe ich ein funktionierendes VPN zwischen dem Ubuntu Server und dem Windows PC. Ich kann auf dem Server jedoch nicht die Drucker in CUPS hinzufügen. Ich habe auf dem Server eine CCD file "client1" angelegt mit folgendem Inhalt
iroute 192.168.1.0 255.255.255.0
Ich hatte mal auf einem Testserver das zum laufen bekommen und die Drucker ansprechen können. Dies klappt leider nicht mehr.
Habt ihr da Ideen was ich falsch mache bzw welche Einstellungen noch fehlen.
Danke und viele Grüße
ich habe einen Ubuntu Server mit CUPS. Zusätzlich folgendes Setup:
Smartphone mit Internet welches Internet per WLAN an einen Router TP Link WR841N bereitstellt.
An diesen Router sind angeschlossen:
Ein PC mit Windows, und zwei Drucker.
Alle Geräte erhalten die IP also vom Router. Nun habe ich ein funktionierendes VPN zwischen dem Ubuntu Server und dem Windows PC. Ich kann auf dem Server jedoch nicht die Drucker in CUPS hinzufügen. Ich habe auf dem Server eine CCD file "client1" angelegt mit folgendem Inhalt
iroute 192.168.1.0 255.255.255.0
Ich hatte mal auf einem Testserver das zum laufen bekommen und die Drucker ansprechen können. Dies klappt leider nicht mehr.
Habt ihr da Ideen was ich falsch mache bzw welche Einstellungen noch fehlen.
Danke und viele Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 494146
Url: https://administrator.de/contentid/494146
Ausgedruckt am: 19.12.2024 um 08:12 Uhr
19 Kommentare
Neuester Kommentar
Smartphone mit Internet welches Internet per WLAN an einen Router TP Link WR841N bereitstellt.
Das ist irgendwie verwirrend ??Nutzt du am Router lediglich den Switchteil ?? Scheinbar ja, oder ?
Der WLAN AP im Router ist dann als WLAN Client oder Bridge definiert und loggt sich dann ins Tethering WLAN des Smartphones ein. Ist das so richtig ?
Nur um das Design genau zu verstehen. Leider machst du hier sehr wenig hilfreiche Angaben zu....
Der Ubuntu Server ist Teil des lokalen LANs am Router ??
Ein Topologie Zeichnung wäre hier hilfreich ! Oder muss man sich das ganze so vorstellen:
Essentiel wichtig ist zu wissen wie die Anbindung des Router WLANs an den den Tethering WLAN AB des Smartphones passiert.
- Ist das Bridging also eine reine Layer 2 Kopplung ? WLAN Netz IP ist also gleich der IP des Router LANs
- Ist das Routing mit WISP. Also WLAN Netz IP ist NICHT gleich der IP des Router LANs und der Router macht auch noch NAT (Translation Firewall) zwischen WLAN und LAN.
Auch hier wäre die Server Konfig Datei und ein Output der Routing Tabelle bei aktivem VPN Client sehr hilfreich für ein Troubleshooting.
Auf dem Router habe ich DD-Wrt installiert.
WIE hast du den Client eingerichtet ?? Als Router (Router Mode) oder als NAT Interface (Gateway Mode) bei DD-WRT ! ?? Siehe dazu auch hier:Mit einem WLAN zwei LAN IP Netzwerke verbinden
Das ist essentiell wichtig zu wissen für die Funktion !
Wenn es weiter hilft male ich gerne auch eine Skizze.
Das musst du ja nicht mehr, oben ist ja schon eine !! Allerdings sagst du mit keinem Wort ob diese richtig oder falsch ist
So wie oben müsste sie dann falsch sein wenn der Ubuntu Server irgendwo in einem RZ steht remote. Du greifst dann vermutlich mit einem OpenVPN Client auf dem PC auf den Server zu, richtig ?
Dann sähe es vermutlich so aus wenn man es jetzt richtig versteht:
Leider bist du weiter sehr oberflächlich in der Beschreibung deines IP Adress Setups deshalb muss man leider so oft nachfragen hier um das zu verstehen um eine zielführende und helfende Antwort zu geben.
Der DD-WRT Router wird vermutlich im NAT Modus (Gateway Mode) am WAN Interface laufen. Das müsste eigentlich so sein, denn wenn du ihn im Router Mode (ohne NAT) laufen liessest, dann würde das eine statische Route auf dem Smartphone erzwingen die du meist nicht eingeben kannst.
Gehen wir also mal davon aus das der DD-WRT im Gateway Mode, sprich also mit NAT arbeitet.
Knackpunkt ist das OpenVPN ein internes IP Netz benutzt. Dieses kannst du auch sehen wenn du mit aktiviertem OVPN Client PC dort mal ein ipconfig -all in der Eingabeaufforderung eingibst !
Dort müsstest du ein VPN Tunnelinterface (tun) sehen was die interne IP Adresse des OpenVPN Netze enthält.
Dieses IP Netz muss dein DD-WRT Router kennen. Dazu gibst du ihm eine feste statische Route in das Netz mit dem Client PC als Gateway IP Adresse. Der Client PC fungiert dann quasi als Router zwischen OpenVPN Netz und lokalem LAN 192.168.1.0 /24. Deshalb muss hier über die Registry auch IPv4 Forwarding aktiviert sein. Siehe dazu auch:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Damit der Drucker im LAN Daten vom Server drucken kann muss er ja dessen internes OpenVPN Netz kennen. Ansonsten würden Druckdaten niemals bei ihm ankommen, da diese ja immer eine Absender IP aus dem OpenVPN Netz haben.
Da der Drucker ja den DD-WRT Router als Default Gateway bekommt und dieser jetzt eine statische Route ins OpenVPN IP Netz hat "kennt" der DD-WRT Router wieder den Weg zum Server und seinen Druckdaten.
Damit sollte der Drucker dann alle Daten des Servers fehlerfrei drucken.
Gibt es ein Tool um diese Skizzen zu malen?
Ja, Visio, OmniGraffel, dia, Draw usw.... Cisco_Logos helfen.Zurück zum Thema !
Die Client Konfig kann so nicht stimmen bzw. würde so niemals funktionieren !!
Der Parameter "remote 192.168.1.109 1194" impliziert ja das der VPN Server extern im 192.168.1.0 IP Netz erreichbar ist.
Das kollidiert aber mit dem lokalen IP Netz was ja ebenfalls ein 192.168.1.0er Netz ist. Das kann so niemals funktionieren, da ein fundamentaler Verstoß gegen IP Adressregeln die vorschreiben das IP Netze einzigartig sein müssen. Siehe dazu auch:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Das musst du also zwingend korrigieren.
Zweiter Kardinalsfehler ist der fehlende Kernel Route Eintrag am Server "iroute 192.168.1.0 255.255.255.0".
Siehe auch hier: https://community.openvpn.net/openvpn/wiki/RoutedLans
und
Problem mit site 2 site VPN
Desweiteren muss IPv4 Forwarding am Client in der Registry aktiviert sein !!
Hast du das beachtet ?
dass der Eintrag zur iroute nicht in die server.conf gehört sondern in die ccd file.
Solange du nur eine Seite hast brauchst du das nicht in ein spezielles Client Verzeichnis kopieren wo es dann Client spezifisch hinzugeladen wird sondern kannst es bei nur einem LAN zu LAN Client dann logischerweise auch direkt in die Konfig schreiben.iroute und route gehört de facto in die server.conf. Siehe auch hier:
Problem mit site 2 site VPN
Das eine definiert es in der Kernel Routing Tabelle des Server Betriebssystems und das andere behandelt es innerhalb des OpenVPN Prozesses.
Nochmal zum Verständns....
In der Anleitung steht "In ccd/client1 He should have the following:..."
Damit ist dann gemeint das auf dem Server das Verzeichnis /ccd die verschiedenen Client Konfig Dateien enthält die so benamt sein müssen wie der Common Name der Clients (Beispiel hier Common Name des Clients = client1). Dort ist dann das spezifische iroute Kommando drin für die Client IP Netze die dann dynmaisch beim VPN Dialin der Server Konfig zugefügt werden.
Da du nur einen einzigen Client hast kannst du es dann auch gleich direkt in deine Server Konfig schreiben und brauchst natürlich NICHT das Splitting in die Client spezifischen Dateien..
Übrigens zeigt dir ein route print sowohl auf Client- als auch auf Server Seite bei aktivem VPN dann immer die korrekten IP Routen an !
Damit kannst du immer checken das die IP Netze korrekt geroutet werden auf beiden Seiten.
So wie ich verstehe steht das VPN ja vernünftig da.
Ja, routingtechnisch sieht das gut aus !Hast du de Connectivity und Erreichbarkeit zwische den Netzen mal mit einem Traceroute und/oder Ping getestet ??
Ich kann vom Client und vom Server die VPN Gegenseite anpingen.
OK, hat sich erledigt die Frage... Bedeutet das netztechnisch dann alles OK ist und jeder jeden im jeweils anderen Netz erreichen kann. VPN rennt also fehlerlos.
Wie bekomme ich nun den Drucker welcher an den DD-WRT Router per LAN Kabel angeschlossen ist mit dem Server verbunden.
Wichtig ist erstmal das du vom Server die Drucker IP pingen kannst ! Vermutlich klappt das auch, oder ?Der Server rennt unter Ubuntu und hat sicher CUPS installiert, oder ???
Du installierst dann einfach mit CUPS diesen Drucker. Das geht bequem und enfach über das CUPS WebGUI mit dem Browser sofern das im Server freigeschaltet ist.
https://xentral.com/helpdesk/drucker-cups
https://www.elektronik-kompendium.de/sites/raspberry-pi/2007081.htm
https://www.heise.de/ct/ausgabe/2013-14-Mini-PC-als-stromsparender-Print ...
usw. usw.
IPP sollte klappen.
Genau das klappt leider nicht.
Dann fehlt mit großer Wahrscheinlichkeit das Default Gateway in der IP Konfiguration des Druckers !!Dort muss der DD-WRT Rozter bzw. dessen IP eingetragen sein !
ACHTUNG: Das funktioniert aber nur dann wenn der DD-WRT eine statische Route des internen OVPN IP Netzes auf den OVPN Client PC buw. dessen IP eingetragen hat !
Ohne diese statische Route im DD-WRT kann der Drucker logischerweise das OVPN Netzwerk des Servers nicht erreichen. Das erreicht er ja nur über den OVPN Client als Router !
Traceroute ist hier dein Freund !
Im DD-WRT muss sowas stehen in der statischen Route Konfig:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.1.100
(Jetzt mal unter der Annahme das der OVPN Client PC die .1.100 als IP hat !)
Der OVPN Client PC muss zwingend IPv4 Forwarding aktiviert haben !
Wenn ich aber schon vom Server den PC im LAN Netz anpinge -> ping 192.168.1.101 habe ich 100% Verlust.
Das lässt befürchten das du vergessen hast hier auf dem Client das IPv4 Forwarding (Routing) zu aktivieren !! Kann das sein ? (Windows = in der Registry, Linux = in der Datei /etc/sysctl. Bei beiden Reboot danach)Bevor der Ping vom Server zum Drucker nicht funktioniert musst du gar nicht erst weitermachen...klar denn dann scheitert ja schon grundsätzlich die IP Verbindung.
Ja, das ist richtig !
Ist ja klar, der Client ist ja quasi auch ein Router bzw. muss also solcher ins OVPN Netz agieren. Er routet zwischen dem lokalen 192.168.1.0er LAN und dem internen OVPN Tunnel IP Netz 10.8.0.0 /24.
Wenn du von dem aus pingst erreicht der natürlich immer alles, denn er "kennt" ja alle beteiligten IP Netze da die direkt an ihm dran sind.
Pingst du aber von einem LAN Client "kennt" dieser logischerweise ja nur das lokale LAN und sein Default Gateway was in diesem LAN liegt. So ein Client wird also alles was an IP Netze geht die er nicht kennt an sein Default Gateway senden.
Bei einem Ping dieses Clients auf die 10.8.0.1 (OVPN Server) z.B. greift also dessen Default Gateway (sofern eins konfiguriert ist !). Der forwardet das Paket also dahin.
In deinem Falle also der DD-WRT Router.
Ohne entsprechende Route in das 10.8.0.0er Netz auf dem DD-WRT Router würde er das an das Tethering Smartphone schicken, das ja sein Default Gateway ist und damit landen die 10.8.0.0 Pakete dann beim Mobilfunk Provider und damit im Nirvana, da der private RFC 1918 IPs kommentarlos in den Datenmülleimer entsorgt.
Die Route auf dem DD-WRT ist also entscheident !
Die muss die 10.8.0.0er IP Paket an die 192.168.1.101 also deinen OVPN Cliewnt schicken, damit sie sauber zum Ziel kommen.
Das ist das ganze Geheimnis dahinter.
Ist ja klar, der Client ist ja quasi auch ein Router bzw. muss also solcher ins OVPN Netz agieren. Er routet zwischen dem lokalen 192.168.1.0er LAN und dem internen OVPN Tunnel IP Netz 10.8.0.0 /24.
Wenn du von dem aus pingst erreicht der natürlich immer alles, denn er "kennt" ja alle beteiligten IP Netze da die direkt an ihm dran sind.
Pingst du aber von einem LAN Client "kennt" dieser logischerweise ja nur das lokale LAN und sein Default Gateway was in diesem LAN liegt. So ein Client wird also alles was an IP Netze geht die er nicht kennt an sein Default Gateway senden.
Bei einem Ping dieses Clients auf die 10.8.0.1 (OVPN Server) z.B. greift also dessen Default Gateway (sofern eins konfiguriert ist !). Der forwardet das Paket also dahin.
In deinem Falle also der DD-WRT Router.
Ohne entsprechende Route in das 10.8.0.0er Netz auf dem DD-WRT Router würde er das an das Tethering Smartphone schicken, das ja sein Default Gateway ist und damit landen die 10.8.0.0 Pakete dann beim Mobilfunk Provider und damit im Nirvana, da der private RFC 1918 IPs kommentarlos in den Datenmülleimer entsorgt.
Die Route auf dem DD-WRT ist also entscheident !
Die muss die 10.8.0.0er IP Paket an die 192.168.1.101 also deinen OVPN Cliewnt schicken, damit sie sauber zum Ziel kommen.
Das ist das ganze Geheimnis dahinter.
Und das ist so wie ich verstehe Grundvorraussetzung.
Ja, auch das muss zwingend funktionieren ! Das zeigt dann grundsätzlich die Konnektivität ins 192.168.1.0er LAN.Du solltest bei aktivem VPN Client dann nochmals die Routng Tabellen auf beiden Seiten (Server und Client) checken:
Linux: netstat -r Windows: route print
Die beteiligten IP Netze müssen in den Routing Tabellen stehen. Auf dem Server das 192.168.1.0/24 via OVPN tun Interface.
Ist das der Fall dann bleiben nur noch 2 Optionen !
- Lokale Firewalls: Hier musst du aufpassen das diese Netze nicht geblockt sind !
- NAT: Der Server sollte kein NAT im OVPN Tunnel machen.