9
Mehrere Rechner im VPN ansprechen OHNE VPN Switch bzw Router
Hallöchen zusammen,
vorweg muss direkt erwähnen das unser Betrieb die letzten Jahre enorm an der IT gespart hat und wir mit notdürftigen Mitteln (in unserer Freizeit) ein Intranet aufgebaut haben. Dieses läuft seit nunmehr 7 Jahren absolut stabil und ohne jegliche Probleme. Jedoch sind wir aktuell "mit den uns verfügbaren mitteln" am Ende angelangt.
Kurzer Sachstand zum Aufbau:
[ROUTER] >> [SWITCH] >> [SERVER mit VPN + Anwendungen]
- Debian Server mit Standleitung steht an Standort "A".
- Der VPN-Daemon läuft (leider noch) genau auf diesem Server. (und ebenfalls leider noch mit PPTP!)
- Alle Clients von anderen Standorten können sich ohne Probleme ins VPN und auf Server (10.0.0.1) verbinden.
- Auf dem Debian Server läuft zusätzlich noch ein DNS-Daemon welcher interne Domains routet.
Frage:
Wie bekomme ich es "MIT DEN VORHANDEN MITTELN"(Separater VPN-Switch leider erst nächstes Jahr) hin, dass ein zweiter Server im Netz zugänglich für alle VPN Clients wird ?
Der zweite Server ("Server B") am Switch hat einen festen Hostname (bsp.: bla.xyz), welcher auch im DNS-Daemon auf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
Aktuell haben wir es so gelöst das wir auf den Windows Clients eine statische Route eintragen (route add 192.168.178.5 etc ...) , welche dann vom VPN-DNS-Daemon zum Ziel bzw. "Server B" geroutet wird. Ich weiß, das ist wohl die stümperhafteste Lösung überhaupt aber so kommen wir derweil wenigstens auf "Server B". Wobei manche Clients (meistens Win10 Geräte) ab und an lieber den Telekom DNS Server abfragen anstatt den eigens angegebenen VPN-DNS-Daemon. (NdisWanIP in Win10 steht ja leider am Ende der Kette). Womit dann keine Verbindung zu stande kommt.
Es muss doch noch irgendeinen anderen Weg geben dem zweiten Server im Netz für die VPN Clients verfügbar zu machen ?
Wie oben schon erwähnt: Neuaufbau mit gescheitem VPN-Switch/Router (welcher dann direkt vor den Zielen hängt + gescheites VPN Protokoll mit routepush kommt erst nächstes Jahr in Frage
Vielen Dank schomal,
falls irgendwer eine bessere Lösung (außer abreißen und neu aufbauen) hat.
vorweg muss direkt erwähnen das unser Betrieb die letzten Jahre enorm an der IT gespart hat und wir mit notdürftigen Mitteln (in unserer Freizeit) ein Intranet aufgebaut haben. Dieses läuft seit nunmehr 7 Jahren absolut stabil und ohne jegliche Probleme. Jedoch sind wir aktuell "mit den uns verfügbaren mitteln" am Ende angelangt.
Kurzer Sachstand zum Aufbau:
[ROUTER] >> [SWITCH] >> [SERVER mit VPN + Anwendungen]
- Debian Server mit Standleitung steht an Standort "A".
- Der VPN-Daemon läuft (leider noch) genau auf diesem Server. (und ebenfalls leider noch mit PPTP!)
- Alle Clients von anderen Standorten können sich ohne Probleme ins VPN und auf Server (10.0.0.1) verbinden.
- Auf dem Debian Server läuft zusätzlich noch ein DNS-Daemon welcher interne Domains routet.
Frage:
Wie bekomme ich es "MIT DEN VORHANDEN MITTELN"(Separater VPN-Switch leider erst nächstes Jahr) hin, dass ein zweiter Server im Netz zugänglich für alle VPN Clients wird ?
Der zweite Server ("Server B") am Switch hat einen festen Hostname (bsp.: bla.xyz), welcher auch im DNS-Daemon auf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
Aktuell haben wir es so gelöst das wir auf den Windows Clients eine statische Route eintragen (route add 192.168.178.5 etc ...) , welche dann vom VPN-DNS-Daemon zum Ziel bzw. "Server B" geroutet wird. Ich weiß, das ist wohl die stümperhafteste Lösung überhaupt aber so kommen wir derweil wenigstens auf "Server B". Wobei manche Clients (meistens Win10 Geräte) ab und an lieber den Telekom DNS Server abfragen anstatt den eigens angegebenen VPN-DNS-Daemon. (NdisWanIP in Win10 steht ja leider am Ende der Kette). Womit dann keine Verbindung zu stande kommt.
Es muss doch noch irgendeinen anderen Weg geben dem zweiten Server im Netz für die VPN Clients verfügbar zu machen ?
Wie oben schon erwähnt: Neuaufbau mit gescheitem VPN-Switch/Router (welcher dann direkt vor den Zielen hängt + gescheites VPN Protokoll mit routepush kommt erst nächstes Jahr in Frage
Vielen Dank schomal,
falls irgendwer eine bessere Lösung (außer abreißen und neu aufbauen) hat.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 352110
Url: https://administrator.de/forum/mehrere-rechner-im-vpn-ansprechen-ohne-vpn-switch-bzw-router-352110.html
Ausgedruckt am: 06.04.2025 um 16:04 Uhr
9 Kommentare
Neuester Kommentar
Zitat von @curare:
Hallöchen zusammen,
vorweg muss direkt erwähnen das unser Betrieb die letzten Jahre enorm an der IT gespart hat und wir mit notdürftigen Mitteln (in unserer Freizeit) ein Intranet aufgebaut haben. Dieses läuft seit nunmehr 7 Jahren absolut stabil und ohne jegliche Probleme. Jedoch sind wir aktuell "mit den uns verfügbaren mitteln" am Ende angelangt.
oh..Hallöchen zusammen,
vorweg muss direkt erwähnen das unser Betrieb die letzten Jahre enorm an der IT gespart hat und wir mit notdürftigen Mitteln (in unserer Freizeit) ein Intranet aufgebaut haben. Dieses läuft seit nunmehr 7 Jahren absolut stabil und ohne jegliche Probleme. Jedoch sind wir aktuell "mit den uns verfügbaren mitteln" am Ende angelangt.
Kurzer Sachstand zum Aufbau:
[ROUTER] >> [SWITCH] >> [SERVER mit VPN + Anwendungen]
- Debian Server mit Standleitung steht an Standort "A".
- Der VPN-Daemon läuft (leider noch) genau auf diesem Server. (und ebenfalls leider noch mit PPTP!)
- Alle Clients von anderen Standorten können sich ohne Probleme ins VPN und auf Server (10.0.0.1) verbinden.
- Auf dem Debian Server läuft zusätzlich noch ein DNS-Daemon welcher interne Domains routet.
ok..- Auf dem Debian Server läuft zusätzlich noch ein DNS-Daemon welcher interne Domains routet.
Frage:
Wie bekomme ich es "MIT DEN VORHANDEN MITTELN"(Separater VPN-Switch leider erst nächstes Jahr) hin, dass ein zweiter Server im Netz zugänglich für alle VPN Clients wird ?
also sollst du die beiden netze verbinden! natürlich mit NETBIOS AUFLÖSUNG... und DNS.
Der zweite Server ("Server B") am Switch hat einen festen Hostname (bsp.: bla.xyz), welcher auch im DNS-Daemon auf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
Aktuell haben wir es so gelöst das wir auf den Windows Clients eine statische Route eintragen (route add 192.168.178.5 etc ...) , welche dann vom VPN-DNS-Daemon zum Ziel bzw. "Server B" geroutet wird. Ich weiß, das ist wohl die stümperhafteste Lösung überhaupt aber so kommen wir derweil wenigstens auf "Server B". Wobei manche Clients (meistens Win10 Geräte) ab und an lieber den Telekom DNS Server abfragen anstatt den eigens angegebenen VPN-DNS-Daemon. (NdisWanIP in Win10 steht ja leider am Ende der Kette). Womit dann keine Verbindung zu stande kommt.
Es muss doch noch irgendeinen anderen Weg geben dem zweiten Server im Netz für die VPN Clients verfügbar zu machen ?
Wie oben schon erwähnt: Neuaufbau mit gescheitem VPN-Switch/Router (welcher dann direkt vor den Zielen hängt + gescheites VPN Protokoll mit routepush kommt erst nächstes Jahr in Frage
was ich aber glaube ist, wenn Wir Administratoren dein Problem in 30 min lösen... gibbet nächstes jahr auch keine neuen VPN Router... klappt ja eh alles!
Vielen Dank schomal,
falls irgendwer eine bessere Lösung (außer abreißen und neu aufbauen) hat.
Hallo,
ich würde Euch dringend zu einem kräftigen Router raten aber dann auch gleich zusammen mit einem VPN Server
in einer DMZ, so ist der Router nicht voll und ganz gestresst und man kann auch gleich auf alles im LAN zugreifen
weil das alles dort im VPN Server eingetragen wird, also wenn mal ein alter Server z´günstig abfällt oder aber auch
zu kaufen ist wäre das die beste Lösung für Euch alle. Mittels OpenSource Lösungen kann man sogar richtig etwas
daraus machen! Ich würde zu einem VPN Server raten der aus CentOS und SoftEtherVPN besteht. Der kann recht
viele unterschiedliche VPN Protokolle und ein Server schlägt in der Regel immer einen Router oder eine Firewall
in Sachen Performance.
Bei dem Einsatz eines Routers käme mir je nachdem wie viele Benutzer man dort überhaupt vor Ort hat ein
MikroTik RB1100AHx4 zum Einsatz der schafft das auch alles. Kostet mehr als 200 € aber der hält dann
auch wieder für xyz Jahre.
Firewall am Server dafür öffnen und gut ist es.
Gruß
Dobby
ich würde Euch dringend zu einem kräftigen Router raten aber dann auch gleich zusammen mit einem VPN Server
in einer DMZ, so ist der Router nicht voll und ganz gestresst und man kann auch gleich auf alles im LAN zugreifen
weil das alles dort im VPN Server eingetragen wird, also wenn mal ein alter Server z´günstig abfällt oder aber auch
zu kaufen ist wäre das die beste Lösung für Euch alle. Mittels OpenSource Lösungen kann man sogar richtig etwas
daraus machen! Ich würde zu einem VPN Server raten der aus CentOS und SoftEtherVPN besteht. Der kann recht
viele unterschiedliche VPN Protokolle und ein Server schlägt in der Regel immer einen Router oder eine Firewall
in Sachen Performance.
Bei dem Einsatz eines Routers käme mir je nachdem wie viele Benutzer man dort überhaupt vor Ort hat ein
MikroTik RB1100AHx4 zum Einsatz der schafft das auch alles. Kostet mehr als 200 € aber der hält dann
auch wieder für xyz Jahre.
Der zweite Server ("Server B") am Switch hat einen festen Hostname (bsp.: bla.xyz), welcher auch im DNS-Daemon
auf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing
ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
Also wenn der Server auch eine IP Adresse hat kann man die doch dort auch eintragen und dann noch schnell dieauf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing
ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
Firewall am Server dafür öffnen und gut ist es.
Gruß
Dobby
Wie bekomme ich es "MIT DEN VORHANDEN MITTELN"(Separater VPN-Switch leider erst nächstes Jahr) hin, dass ein zweiter Server im Netz zugänglich für alle VPN Clients wird ?
Der zweite Server ("Server B") am Switch hat einen festen Hostname (bsp.: bla.xyz), welcher auch im DNS-Daemon auf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
Der zweite Server ("Server B") am Switch hat einen festen Hostname (bsp.: bla.xyz), welcher auch im DNS-Daemon auf "Server A" auf dessen IP geroutet wird. Die VPN Clients können diesen aber nicht ansprechen weil das routing ja auf die interne IP läuft und "Server B" keine VPN-IP wie z.B. 10.0.0.2 hat.
SNAT ?
Es muss doch noch irgendeinen anderen Weg geben dem zweiten Server im Netz für die VPN Clients verfügbar zu machen ?
SNAT/DNAT und/oder RoutenWie oben schon erwähnt: Neuaufbau mit gescheitem VPN-Switch/Router (welcher dann direkt vor den Zielen hängt + gescheites VPN Protokoll mit routepush kommt erst nächstes Jahr in Frage
Vielen Dank schomal,
falls irgendwer eine bessere Lösung (außer abreißen und neu aufbauen) hat.
Zitat von @Vision2015:
also ihr habt keine 200 euro für einen Mikrotik Router???!!!?? sorry, das kann ich kaum glauben!
Ja, klingt krass - ist aber leider so! Du glaubst nicht wie oft wir in den letzten Jahren Sprüche wie: "System läuft, gibt nix neues!" gehört haben. Unser Problem ist, dass wir Mitarbeiter das mal alles nebenbei für lau gebastelt haben. Die Verwöhnheit (ja kein Geld für IT oder einen IT'ler ausgeben so lange der Betrieb läuft) hängt bei uns recht hoch .... aber gut, das ist ein anderes Thema. Ich bin eigentlich Web- & Medien Entwickler, von daher fehlt mir halt leider das Intensiv-Wissen rund um Netzwerke etc. Deswegen bin ich hier....also ihr habt keine 200 euro für einen Mikrotik Router???!!!?? sorry, das kann ich kaum glauben!
Zitat von @108012:
Bei dem Einsatz eines Routers käme mir je nachdem wie viele Benutzer man dort überhaupt vor Ort hat ein
MikroTik RB1100AHx4 zum Einsatz der schafft das auch alles. Kostet mehr als 200 € aber der hält dann
auch wieder für xyz Jahre.
Danke für die Empfehlung ... hatte die Geräte gar nicht auf dem Schirm. Wir hatten uns hier (für die Anschaffung in 2018) eher in Richtung komplette VPN-Firewall orientiert und sind bei Geräten von Netgear, Sophos, Cisco & Co gelandet. Dort sind aber meist die VPNs limitiert und/oder man ist an monatliche Lizenzen gebunden. Supi, schau ich mir gleich mal an ...Bei dem Einsatz eines Routers käme mir je nachdem wie viele Benutzer man dort überhaupt vor Ort hat ein
MikroTik RB1100AHx4 zum Einsatz der schafft das auch alles. Kostet mehr als 200 € aber der hält dann
auch wieder für xyz Jahre.
Werde mich dann nochmal mit der VPN Config beschäftigen und die iptables überprüfen.... Eventuell ist ja doch irgendwo ein dämlicher Fehler drin.
Danke für die Empfehlung ... hatte die Geräte gar nicht auf dem Schirm. Wir hatten uns hier (für die Anschaffung in 2018)
eher in Richtung komplette VPN-Firewall orientiert und sind bei Geräten von Netgear, Sophos, Cisco & Co gelandet.
Also mit dem RB1100AHx2 kann man schon richtig gut was anfangen und dann gibt es dort auch noch dieeher in Richtung komplette VPN-Firewall orientiert und sind bei Geräten von Netgear, Sophos, Cisco & Co gelandet.
CCR Serie von MikroTik falls alle Stricke reißen sollten! Klar es kommt eben immer auf die Klienten an, wenn
man sehr viele davon hat und dann alle auf bzw. über die Firewall wollen dann ist das eher hinderlich bzw.
die bekommt immer mehr zu tun und wird dadurch auch nicht schneller!!!
Dort sind aber meist die VPNs limitiert und/oder man ist an monatliche Lizenzen gebunden. Supi, schau ich mir gleich mal an ...
Man kann auch eine große starke VPN Firewall aus dem OpenSource Umfeld nehmen und dann damit richtig Geld sparenund die sind in der Regel auch gut zu gebrauchen! pfSense auf einen Supermicro SYS-E300-9A ist schon eine echte Rakete
und muss sich auch nicht vor den anderen Herstellern verstecken! Ist aber OpenSource und man spart auch wieder an den
Lizenzen. Die Unterstützung durch pfSense sollte im November 2017 statt finden und die Anpassungen sollten bis März
2018 auch durch sein.
Werde mich dann nochmal mit der VPN Config beschäftigen und die iptables überprüfen.... Eventuell ist ja doch irgendwo
ein dämlicher Fehler drin.
Kann sein, viel Erfolg damit.ein dämlicher Fehler drin.
Gruß
Dobby
Hmmmm...
Gibt es einen sachlichen Grund, warum dein VPN-Server mit einer virtuellen IP arbeitet? Wenn dein Netz "eigentlich" 192.168.178.0 ist, warum verteilst du den Clients nicht IP's aus diesem Range? Dann routet der Client und das kann er normalerweise von selbst. Du versuchst unnötigerweise (?) ein Routing á la 192.168.1.0/24 --> 10..0.0.0/24 --> 192.168.178.0/24 zu etablieren. Kann man machen, aber dann müssen halt immer die Clients wissen, dass das 192.168.178.0-er Netz hinter der 10.0.0.1 zu finden ist. Statisches Routing. Da kannst du auf dem Server routen, was du willst. Der Client muss doch wissen wohin die Reise geht. Und die statische Route sagt ihm, dass er von München (Client) nach Hamburg (Server 2) über Hannover (Server 1 VPN) kommt. Von alleine kommt er leider nicht auf die Idee in Hannover zu fragen, ob der Weg nach Hamburg bekannt ist...
Guck dir nochmal die OPNSense an, wenn du in Richtung PfSense tendierst. Ist evtl. ne gute Alternative.
Beide gibts mittlerweile auch in deutsch.
Trotzdem: Lasst das nen IT-ler machen. Das Geld, das du in der Zeit der Einarbeitung und mit dem Troubleshooting als Webentwickler verdienen kannst, ist ein vielfaches. Du kannst das Wissen dann nicht beim nächsten Kunden einsetzen...
e mare libertas
Buc
Gibt es einen sachlichen Grund, warum dein VPN-Server mit einer virtuellen IP arbeitet? Wenn dein Netz "eigentlich" 192.168.178.0 ist, warum verteilst du den Clients nicht IP's aus diesem Range? Dann routet der Client und das kann er normalerweise von selbst. Du versuchst unnötigerweise (?) ein Routing á la 192.168.1.0/24 --> 10..0.0.0/24 --> 192.168.178.0/24 zu etablieren. Kann man machen, aber dann müssen halt immer die Clients wissen, dass das 192.168.178.0-er Netz hinter der 10.0.0.1 zu finden ist. Statisches Routing. Da kannst du auf dem Server routen, was du willst. Der Client muss doch wissen wohin die Reise geht. Und die statische Route sagt ihm, dass er von München (Client) nach Hamburg (Server 2) über Hannover (Server 1 VPN) kommt. Von alleine kommt er leider nicht auf die Idee in Hannover zu fragen, ob der Weg nach Hamburg bekannt ist...
Guck dir nochmal die OPNSense an, wenn du in Richtung PfSense tendierst. Ist evtl. ne gute Alternative.
Beide gibts mittlerweile auch in deutsch.
Trotzdem: Lasst das nen IT-ler machen. Das Geld, das du in der Zeit der Einarbeitung und mit dem Troubleshooting als Webentwickler verdienen kannst, ist ein vielfaches. Du kannst das Wissen dann nicht beim nächsten Kunden einsetzen...
e mare libertas
Buc
Hallo,
Meine ganz persönliche Meinung:
Ganz ehrlich? Selber Schuld....
Sieh zu das ihr das Ding gegen die Wand fahren lasst...
Die Kollegen haben ja den Lösungsansatz schon formuliert... daher sollte das passen.
Habt ihr euch mal die Frage gestellt was passiert wenn die IT einfach mal für 5 Tage ausfällt weil der Uralt Server abraucht....
brammer
Die Verwöhnheit (ja kein Geld für IT oder einen IT'ler ausgeben so lange der Betrieb läuft) hängt bei uns recht hoch .... aber gut, das ist ein
anderes Thema. Ich bin eigentlich Web- & Medien Entwickler, von daher fehlt mir halt leider das Intensiv-Wissen rund um Netzwerke etc.
Deswegen bin ich hier....
anderes Thema. Ich bin eigentlich Web- & Medien Entwickler, von daher fehlt mir halt leider das Intensiv-Wissen rund um Netzwerke etc.
Deswegen bin ich hier....
Meine ganz persönliche Meinung:
Ganz ehrlich? Selber Schuld....
Sieh zu das ihr das Ding gegen die Wand fahren lasst...
Die Kollegen haben ja den Lösungsansatz schon formuliert... daher sollte das passen.
Habt ihr euch mal die Frage gestellt was passiert wenn die IT einfach mal für 5 Tage ausfällt weil der Uralt Server abraucht....
brammer
Zitat von @Vision2015:
also ihr habt keine 200 euro für einen Mikrotik Router???!!!?? sorry, das kann ich kaum glauben!
Ja, klingt krass - ist aber leider so! Du glaubst nicht wie oft wir in den letzten Jahren Sprüche wie: "System läuft, gibt nix neues!" gehört haben. Unser Problem ist, dass wir Mitarbeiter das mal alles nebenbei für lau gebastelt haben. Die Verwöhnheit (ja kein Geld für IT oder einen IT'ler ausgeben so lange der Betrieb läuft) hängt bei uns recht hoch .... aber gut, das ist ein anderes Thema. Ich bin eigentlich Web- & Medien Entwickler, von daher fehlt mir halt leider das Intensiv-Wissen rund umalso ihr habt keine 200 euro für einen Mikrotik Router???!!!?? sorry, das kann ich kaum glauben!
Werde mich dann nochmal mit der VPN Config beschäftigen und die iptables überprüfen.... Eventuell ist ja doch irgendwo ein dämlicher Fehler drin.
Ich täte opeVPN Server drauf tun (einrichten, anwerfen, geht )auf der Serverseite SNAT - alles 10.x zu 192.168.x SNATten, dass es scheint als kommt der direkt aus dem Netz.
Wäre auch mit IPFire/pfSense abbildbar, braucht in der Firewall nur einen portforward ( 1 Port), ne kleine IntelCPu reicht oft, lieber etwas mehr RAM geben.
Anleitungen zu Hauf ...für Raspi und Banana PI wirds unter Debian-Derivaten gern und oft beschrieben
Ist eine Lösungsvariante von mehreren (eine 10Mbits Leitung schaffte noch ein Alix2 Board - 128 MB RAM mit LX800 CPU, um mal einen Vergleich zu bieten)
Man kann auch mehrerere Tunnel auf verschiedenen Ports gleichzeitig laufen lassen, wenn es denn sein muss.
Statt Lizenzkosten eben Know-How-Kosten
Fred
Nochmal vielen Dank für die zahlreichen Antworten , Denkanstöße und "ehrliche" Meinungen
Auf unseren Firmenhintergrund gehe ich nicht weiter ein - denke wir sind uns da alle einig (auch wenn ich bestimmte Vorschläge nicht so einfach "durchziehen" kann, hrhrhr)
Ich hab das Problem jetzt vorerst mit einem SecureNAT und routing Tabellen (unter IPsec) gelöst. Alle VPN-Clients werden direkt vom virtuellen DHCP bedient und alle Geräte im LAN sind für diese auch verfügbar. Das ganze dann noch mit Ausnahmeregeln versehen, so dass auch nur die gewünschten Routen intern zu Verfügung stehen und der normale Traffic nicht über den Tunnel geroutet wird. Selbst der dnsmasq daemon funktioniert mit der Lösung ohne Probleme.
Alles weitere folgt dann (hoffentlich mit Unterstützung eines Profis) in 2018 - und hoffentlich auch mit dem Einlenken für die einmalige Anschaffung potentieller Hardware.
Vielen Dank euch allen
Auf unseren Firmenhintergrund gehe ich nicht weiter ein - denke wir sind uns da alle einig (auch wenn ich bestimmte Vorschläge nicht so einfach "durchziehen" kann, hrhrhr)
Ich hab das Problem jetzt vorerst mit einem SecureNAT und routing Tabellen (unter IPsec) gelöst. Alle VPN-Clients werden direkt vom virtuellen DHCP bedient und alle Geräte im LAN sind für diese auch verfügbar. Das ganze dann noch mit Ausnahmeregeln versehen, so dass auch nur die gewünschten Routen intern zu Verfügung stehen und der normale Traffic nicht über den Tunnel geroutet wird. Selbst der dnsmasq daemon funktioniert mit der Lösung ohne Probleme.
Alles weitere folgt dann (hoffentlich mit Unterstützung eines Profis) in 2018 - und hoffentlich auch mit dem Einlenken für die einmalige Anschaffung potentieller Hardware.
Vielen Dank euch allen
