Kein Port-Forwards mehr mit dem neuen Internet-Zugang - VPN als Ausweg

[jmar83]

Hmmm... dass mein Router unter "OpenWRT" läuft, macht die Sache ziemlich kompliziert...

Obwohl ich Informatiker bin (nur Fähigkeitszeugnis), steh ich da total "auf dem Schlauch"!!

Im Internet findet man fast nur Informationen wie man auf "OpenWRT" ein DMZ kreiert, und praktisch gar nicht wie man OpenWRT als Teilnehmer einer DMZ konfiguriert.

Beim ISP-Support wurde mir gesagt:

- Gateway: 192.168.254.1 (wie bisher??)
- DMZ: 192.168.254.2
- Subnet: 255.255.255.0 (Soweit klar)
- DHCP IP: 192.168.254.100 - 192.168.254.200


Mein Ziel ist, dass auf der ext. IP des 2. Routers (mein Eigener) 192.168.254.102 ALLES (Alle Ports TCP & UDP), reinkommt was auf der öffentlichen IP 5.44.x.x angefragt wird...

Ab diesem Zeitpunkt kann ich dann, wie gehabt, ganz normale Port Forwards zu den internen, per DHCP vergebenen, IP-Adressen meines eigenen Routers (192.168.1.x) weiterleiten, z.B.:

Port 80 ext. TCP -> Port 80 int. IP 192.168.1.143


Hat jemand eine Ahnung, wie man das unter einem Linux-Router wie OpenWRT einrichtet? Sonst bin ich wohl die nächsten Tage oder gar Wochen am basteln.

Vielen Dank!!!

 

[Thunderbyte]

Nö, so läuft das nicht.

Der Glasfaser Router hat die 192.168.254.1, alle einkommenden Ports leitet er an die 192.168.254.2 weiter.

D.h.

Internet ->

Glasfaserrouter (192.168.254.1) ->

Der OpenWRT Router muss auf dem WAN PORT manuell die IP Adresse 192.168.254.2 eingestellt bekommen, mit Subnet 255.255.255.0 und Gateway 192.168.254.1 und irgendwelchen DNS Servern (z.B. 1.1.1.1 und 8.8.8.8)
und auf dem LAN PORT ein ANDERES Subnet per DHCP verwalten (z.B. 192.168.1.XXX, mit DHCP Range von 192.168.1.20 bis 192.168.1.250)

Auf der IP Adresse, die vom DHCP des Glasfaserrouters ausgegeben wird, 192.168.254.102 wirst Du NIEMALS alle Ports bekommen, denn die einzige DMZ IP scheint die 192.168.254.2 zu sein. Und genau diese IP muss der 2. Router auf dem WAN Port verwenden.

Bei diesem Setup werden erst mal alle Ports vom Glasfaserrouter (192.168.254.1) an den eigenen Router (192.168.254.2 auf dem WAN Port) weitergereicht, bleiben aber erst mal beim NAT auf das 192.168.1.XXX am 2. Router hängen. Daher musst Du nun noch in Deinem eigenen Router Portforwards auf den betreffenden Rechner im LAN (z.B. 192.168.1.38, wenn das der HTTP Server wäre) einrichten. Du solltest dabei sicherstellen, dass entweder die IP Einrichtung von Servern manuell passiert (dafür die Reservierung im DHCP Server von 192.168.1.2-19) oder im DHCP immer wieder die gleiche IP zugeteilt wird.

 

[jmar83]

Vielen Dank!!!!!

Nun habe ich es zumindest geschafft, dass auf 192.168.254.2:80 im Browser der Apache-Dienst angezeigt wird.

Als DNS-Server verwende ich, da DHCP ausgeschaltet wurde, nun manuell 192.168.254.1 als "DNS Relay" - das läuft soweit auch.

Das ich mit dem DHCP für 192.168.1.x vorsichtig sein muss, ist soweit auch klar. Entweder DHCP komplett ausschalten oder dem Client per MAC eine feste IP zuweisen. (Oder auf dem Client direkt ne feste Adresse zuweisen, DHCP hin oder her - an oder aus) Werde mich dann wohl für die "statisch" DHCP-Zuweisung per MAC entscheiden, so wie bisher halt.

Obwohl auf 192.168.254.2:80 der Apache mit "It works!" antwortet, ist das bei 5.44.x.y:80 nicht der Fall. Habe gedacht ("try and error") ich müsse evtl. die Firewall-Optionen "Input" sowie "Forward" auf "accept" ändern. Bringt aber auch nix. Ein Screenshot von der OpenWRT-Option habe ich hier hochgeladen: https://image.ibb.co/jZW4Td/Unbenannt.png

Vorher waren diese beiden Optionen auf "reject".

(Habe gerade noch ein Update auf OpenWRT 17.1.04 gemacht, um eventuelle Probleme auszuschliessen)

Könnte es sein, dass der Provider einen Fehler gemacht hat bei der Einrichtung der DMZ? (Komme gar nicht auf's Glasfaser-Gerät, das hat ne besondere Firmware, läuft nichts auf Port 80 oder 443 auf 192.168.254.1)

...und bei "General Settings" (Screenshot) steht "Input: accept", "Output: accept" sowie "Forward: reject" - was aber nicht den Einstellungen unter "Zones" entspricht. Wird wohl ein "Template" für neu angelegt Zonen sein. (?)

 

[Thunderbyte]

Nun habe ich es zumindest geschafft, dass auf 192.168.254.2:80 im Browser der Apache-Dienst angezeigt wird.

Wenn Du an welchem Router hängst? Ob das Portforwarding wirklich korrekt durch beide Router funktioniert, kannst Du nur von wirklich extern (z.B. Smartphone ohne WLAN) testen.

Das ich mit dem DHCP für 192.168.1.x vorsichtig sein muss, ist soweit auch klar. Entweder DHCP komplett ausschalten oder dem Client per MAC eine feste IP zuweisen. (Oder auf dem Client direkt ne feste Adresse zuweisen, DHCP hin oder her - an oder aus) Werde mich dann wohl für die "statisch" DHCP-Zuweisung per MAC entscheiden, so wie bisher halt.

Aus diesem Grund die von mir empfohlene DHCP IP Range. Wenn man einige IP Adressen (in diesem Fall 2-19 nicht zuteilt, kann man sie zur manuellen Einrichtung z.B. in Servern verwenden.

Obwohl auf 192.168.254.2:80 der Apache mit "It works!" antwortet, ist das bei 5.44.x.y:80 nicht der Fall.

Das kannst Du nur wirklich sicher von extern sagen (Smartphone ohne WLAN!).

Habe gedacht ("try and error") ich müsse evtl. die Firewall-Optionen "Input" sowie "Forward" auf "accept" ändern. Bringt aber auch nix.

Zu korrekten Konfiguration von OpenWRT kann ich nichts sagen, da ich es nicht verwende. Wende Dich hierfür bitte an OpenWRT Foren. Hier gehts erst mal um das Verständnis des Konzepts.

Könnte es sein, dass der Provider einen Fehler gemacht hat bei der Einrichtung der DMZ? (Komme gar nicht auf's Glasfaser-Gerät, das hat ne besondere Firmware, läuft nichts auf Port 80 oder 443 auf 192.168.254.1)

Deine Netzwerkkenntnisse scheinen nicht die besten zu sein (als Informatiker ist das m.E. Grundwissen!). Daher tippe ich aktuell erst mal noch auf eine Fehlkonfiguration Deinerseits.

Hinweise:

Verkabelung: Glasfaserrouter -> 1 Kabel -> WAN Port des WRT - LAN Port des WRT -> 1 Kabel zum LAN Switch. Am Glasfaserrouter hängen keine Endgeräte, alles muss hinter dem WRT hängen und von diesem eine 192.168.1.XXX IP zugeteilt bekommen. Achtung: evtl müssen Testgeräte (z.B. Laptop/Desktop) kurz vom Netz getrennt werden, damit sie das neue Subnetz zugeteilt bekommen.

WLAN: das WLAN des Glasfasermodems SOLLTE AUS / nicht verwendet werden, der WRT oder ein AP im LAN (192.168.1.XXX) muss WLAN machen.

 

[jmar83]

Wenn Du an welchem Router hängst? Ob das Portforwarding wirklich korrekt durch beide Router funktioniert, kannst Du nur von wirklich extern (z.B. Smartphone ohne WLAN) testen.

Von 192.168.1.154 aus.

Aus diesem Grund die von mir empfohlene DHCP IP Range. Wenn man einige IP Adressen (in diesem Fall 2-19 nicht zuteilt, kann man sie zur manuellen Einrichtung z.B. in Servern verwenden.

Ja, werd ich dann so einrichten, danke.

"Obwohl auf 192.168.254.2:80 der Apache mit "It works!" antwortet, ist das bei 5.44.x.y:80 nicht der Fall."

Aha, dann könnte es sein dass mit "intern" was versperrt wird?

Zu korrekten Konfiguration von OpenWRT kann ich nichts sagen, da ich es nicht verwende. Wende Dich hierfür bitte an OpenWRT Foren. Hier gehts erst mal um das Verständnis des Konzepts.

Kein Problem, habe gedacht es könnte evtl. sein dass Du dich damit auskennst.

Deine Netzwerkkenntnisse scheinen nicht die besten zu sein (als Informatiker ist das m.E. Grundwissen!). Daher tippe ich aktuell erst mal noch auf eine Fehlkonfiguration Deinerseits.

Siehtst Du richtig! Für mich ist das nur "drum herum". Auch OS, Apache, PHP und MySQL einrichten mag ich nicht wirklich, komme aber besser damit klar als mit Netzwerk-Technik, dem IP-Protokoll und Telematik. Aber Programmieren mag ich*, wobei ich darunter natürlich nicht HTML oder CSS verstehe. Da weiss man man was macht, und ist in ca. 99.5% von allen Fällen "selber schuld"...

Verkabelung: Glasfaserrouter -> 1 Kabel -> WAN Port des WRT - LAN Port des WRT -> 1 Kabel zum LAN Switch. Am Glasfaserrouter hängen keine Endgeräte, alles muss hinter dem WRT hängen und von diesem eine 192.168.1.XXX IP zugeteilt bekommen.

Schon klar, hehe! Switch hab ich aber keinen. Es ist einer im WRT-Router drin mit 4 Ports.

WLAN: das WLAN des Glasfasermodems SOLLTE AUS / nicht verwendet werden, der WRT oder ein AP im LAN (192.168.1.XXX) muss WLAN machen.

Auf das Glasfasermodem hab ich wie gesagt nur Einfluss. WLAN ist dort eh ausgeschaltet, nicht mit festem Key (vom ISP vorgegeben) oder so. Ja, WLAN kommt vom WRT, so wie bisher immer.

Achtung: evtl müssen Testgeräte (z.B. Laptop/Desktop) kurz vom Netz getrennt werden, damit sie das neue Subnetz zugeteilt bekommen.

Werde mal das mit dem Smartphone versuchen! Und mal alle Geräte neu starten..

Vielen Dank noch mal!!!!

 

[jmar83]

Jawohl!! Mein uralt-Smartphone mit Android 2.3.7 zeigt mir das an, was es (soweit) tut: "It Works".

Jetzt hab ich wohl noch irgend ein schräges Routing-Problem, mal schauen... muss irgendwie laufen, kann ja nicht sein dass ich meine Webapp auf dem produktiven Server nicht auch Aufrufen und Testen kann...

 

[jmar83]

- Über VPN von hide.me geht auch nichts (Interessant!?) -> EDIT: Klar, wenn ich auf dem selben Gerät den HTTP-Dienst habe!
- Über y-x-44-5.dyn.ftth.fcom.ch ebenfalls nicht
- Über einen DNS-Eintrag test.domain.xxx zu meiner öffentlichen IP auch nicht, habe auch nichts Anderes erwartet
- Über einen anderen Rechner im gleichen Subnetz natürlich auch nicht...

...und tracert 5.44.x.y zeigt mir folgendes an:

Microsoft Windows [Version 10.0.17134.165]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Jan Marti>tracert 5.44.x.y

Routenverfolgung zu y-x-44-5.dyn.ftth.fcom.ch [5.44.x.y]
über maximal 30 Hops:

1 2 ms 2 ms 2 ms OpenWrt.lan [192.168.1.1]
2 3 ms 3 ms 4 ms y-x-44-5.dyn.ftth.fcom.ch [5.44.x.y]

Ablaufverfolgung beendet.

Schräg...

C:\Users\Jan Marti>

 

[jmar83]

"- Über VPN von hide.me geht auch nichts (Interessant!?) -> EDIT: Klar, wenn ich auf dem selben Gerät den HTTP-Dienst habe!"

Auf meiner Virtualbox-XP-VM geht's aber auch nicht über VPN von hide.me.

Nun werd ich es noch von meinem Vserver im Rechenzentrum aus probieren...

 

[jmar83]

- Über den Vserver bei alfahosting.de (-> telnet port 80) geht's ebenfalls nicht, während es auf dem Handy geht. -> SOLLTE GEHEN!!

- Über VPN auf der XP-Virtual-Maschine geht's ebenfalls nicht. -> SOLLTE GEHEN!!

Meine Fresse, aber echt!!!!!!

Das macht alles keinen Sinn, keine Logik dahinter...

 

[jmar83]

Folgende Fehlerkombination war die Ursache, dass es weder mit dem VPN-Dienst, noch auf dem Vserver lief: Der Apache ist abgeschmiert, gleichzeitig hat der Handy-Browser gecacht... Manchmal ist die IT-Welt wirklich zum kotzen...!!

Nun konnte ich wenigstens auf Firefox das Caching komplett ausschalten, per browser.cache.disk.enable = false; Bei Chrome ist das nach meinem aktuellen Wissensstand komplett unmöglich.. von anderen Browsern weiss ich es nicht!

Nachtrag: Bei Chrome geht's scheinbar nur über die Option in den Developer Tools, und auch nur solange diese geöffnet sind. Total suboptimal..

So, nun programmier ich ein wenig mit Musik im Hintergrund, Kaffee und Zigaretten zum relaxen... das entspannt...

 

[Thunderbyte]

Du hast zwar viel geschrieben, aber wenig Struktur drin. Ich kenne Dein Setup nicht, daher verstehe ich größtenteils Bahnhof.

OK, also scheint die Website nun von wirklich außen (Handy ohne WLAN, anderer Nutzer an anderem Internetzugang) zu funktionieren?

Und Dein Problem ist, dass Du intern nicht über den gleichen Domainnamen wie von extern auf die Website zugreifen kannst? Das könntest Du mit einer Zeile in der hosts Datei forcieren:
https://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/ . Das gilt dann nur für den Rechner auf dem die Hosts Datei editiert wurde, aber das scheint ja in diesem Fall zu reichen.

Warum Du, wenn Du einen VServer hast, die Website lokal aufsetzen willst, erschließt sich mir nicht.

Davon abgesehen hast Du bitte nicht gerade geschrieben, dass Du noch eine Windows XP (!!!!!!!!) virtuelle Maschine am Laufen hast? Ein OS, dessen Updates im April 2014, also vor >4 Jahren (!!!!!) aufgehört haben und das man daher als unendlich unsicher einstufen muss ( https://www.microsoft.com/de-de/windowsforbusiness/end-of-xp-support ).

 

[jmar83]

"OK, also scheint die Website nun von wirklich außen (Handy ohne WLAN, anderer Nutzer an anderem Internetzugang) zu funktionieren?"

Ja, so ist es. Über's Handy ohne WLAN oder über eine sonstige fremde IP (z.b. mit SSH), über VPN im EIGENEN Netz/IP (auf einer virt. Maschine oder einem anderen Rechner) oder über den Tor-Browser geht's. Also klar erreichbar! Allerdings nicht über die gleiche IP wie der Server läuft.

"Und Dein Problem ist, dass Du intern nicht über den gleichen Domainnamen wie von extern auf die Website zugreifen kannst? Das könntest Du mit einer Zeile in der hosts Datei forcieren:"

Ne, ich teste das Ganze (also diese DMZ) aktuell nur über die öffentliche IP. Meine obere Antwort bezieht sich nur auf das. Wenn ich eine Test-Subdomain mit einem A-Record test.domain.xxx zu dieser IP einrichte, ist das Verhalten genau gleich wie ohne Domain. Eben wie oben beschrieben.

"Warum Du, wenn Du einen VServer hast, die Website lokal aufsetzen willst, erschließt sich mir nicht."

Den Vserver habe nicht ich, sondern ein Kollege. Und bei dem wird wohl nächsten auch auf Glasfaser umgestellt. (und darauf will ich gerüstet sein, und bereite mich bei mir zuhause vor, da ich jetzt schon Glasfaser habe) Ich bin der "admin" dort, deshalb mein Vorgehen diesbezüglich.. habe nämlich dort auch ein paar virt. Maschinen ohne dass ich etwas an den Strom oder an den Internetanschluss zahlen muss, dafür verwalte ich des Host-System und das Netzwerk bei ihm...

Ein weiterer Vserver steht in einem Rechenzentrum. Über die Konsole (SSH) kann ich ebenfalls auf die Sache bei mir zuhause zugreifen.

"Davon abgesehen hast Du bitte nicht gerade geschrieben, dass Du noch eine Windows XP (!!!!!!!!) virtuelle Maschine am Laufen hast? Ein OS, dessen Updates im April 2014, also vor >4 Jahren (!!!!!) aufgehört haben und das man daher als unendlich unsicher einstufen muss ( https://www.microsoft.com/de-de/wind...-of-xp-support )."

Dort läuft seit ca. 7 Jahren Outlook 2010 ohne jegliche Probleme mit unterschiedlichsten Konten und Regeln. Von daher ist es kaum ein Problem.

 

[elias5000]

Nun konnte ich wenigstens auf Firefox das Caching komplett ausschalten [...] Bei Chrome ist das nach meinem aktuellen Wissensstand komplett unmöglich

Wenn du testen willst, ob deine Seite erreichbar ist, dann teste mit curl.
Auf Browsern testest du nur das Rendering und die Funktion des Contents.

 

[jmar83]

Hallo Elias

Ja, da hast Du sicher Recht, vielen Dank für den Hinweis. Aber wenn ich einen solchen "Murks" habe wie in diesem Fall, dann denke ich meist an alles andere als an solchen Sachen!


Alternativen unter Windows wären:

certutil.exe: certutil -urlcache -split -f "http://webserver.com" index.html
(...das lädt halt herunter.)

telnet.exe: telnet webserver.com 80
(...prüft, ob ein Dienst läuft. Habe ich auch verwendet, vom Vserver aus unter der Linux-SSH-Konsole.)

Und für Android 2.3.7 weiss ich nicht, ob es solche Sachen gibt?

Aber eine VPN-Verbindung zu verwenden, den Tor-Browser oder per SSH eine Verbindung zu einem ext. (V)Server herzustellen, ist wohl eh die bessere Idee als mit dem Handy-Browser ohne WLAN zu testen!


Schon schräg, dass ich von zuhause aus nicht auf den eigenen Server auf 5.44.x.y zugreifen kann, mit den oben erwähten Sachen allerdings schon... habe noch nichts weiteres zur Problemlösung gefunden...

 

[jmar83]

Also mit irgendwelchen alten Systemen sehe ich das so: Wenn man nicht die M$-eigenen Sachen verwendet (wie die Windows-Dateifreigabe oder den IIS oder den IE), und man noch mit aktuellen Versionen von z.b. von Apache, PHP, MySQL, Tomcat, OpenOffice, Firefox, Spybot, Anti-Virus, Scriptblocker-Plugins was auch immer arbeitet dann ist das "halb so schlimm"... des weiteren kann man auch einen reverse Proxy (z.b. mit dem aktuellsten Linux oder Windows) zum legacy-Webserver zwischenschalten, und dort noch ne Web Application Firewall und SSL-Abladung installieren wenn es unbedingt sein muss.

Wenn es für ein problematisches, Windows-eigenes Feature mal keinen Fix mehr gibt, dann schaltet man es am besten einfach aus falls möglich!

Bei älteren Linux-Version hat man viel grössere Probleme, überhaupt noch aktuelle Software zu finden, da hat man dann grösste Probleme mit den Abhängigkeiten, ausser man kompiliert vielleicht selbst und hat dann auch selbst kompilierte Libraries. (Ich finde das ehrlich gesagt nicht immer ideal, dass man wenn man unter Linux neue SW installiert sämtliche gemeinsam genutzte Libraries updaten muss - und damit noch sämtliche andere Applikation, welche davon abhängig sind, auch wenn man das gar nicht will...) Zumindest wenn man wie der Linux-Durchschnittsuser per "apt-get" sein Zeugs holt...

Von daher kann man Windows oft länger brauchen, man muss nur z.b. an Windows Server 2003 denken (Support von MS von 2003-2016?), welches heutzutage teilweise noch im Einsatz ist. (Gut, wohl grösstenteils innerhalb von privaten Netzwerken, eher seltener im öffentlichen Internet..) Ubuntu LTS find ich aber auch nicht schlecht in dieser Hinsicht, auch Red Hat bietet mit seinem "Enterprise Linux" etwas an was sich auf ne bestimmte Zeit bewährt. (=Investitionssicherheit)

Beide Sachen haben ihre Daseinsberechtigung, Linux und Windows. Keines ist "besser" als das andere!! Beide bieten in gewissen Bereichen grosse Vorteile und Alleinstellungsmerkmale, aber auch teilweise grosse Macken... dann gibt's noch Solaris und die ganzen BSD-Varianten..

...nur meine bescheidene Meinung zum Thema, welche nicht "absolut" sein muss!!

Will auf keinen Fall ne Diskussion entfachen à la Linux/UNIX vs. Windows oder ungekehrt!!!! Das ist was für emotional unreife Hacker-Kiddies und verschrobene Freaks - aber nichts für erwachsene und rational denkende Menschen!

Bin da relativ pragmatisch (und manchmal zugegebenermassen auch etwas faul! ) - mit geht's nicht darum wie oder was es ist, sondern dass es läuft!

 

[Thunderbyte]

Es geht hier nicht um Linux vs Windows, es geht darum, dass in KEINEM Fall (egal welches OS) aus Sicherheitsgründen Versionen betrieben werden sollen, die nicht mehr mit Sicherheitsupdates versorgt werden. Da helfen auch aktuelle Versionen der Anwendungen nicht. Es bringt nichts, wenn Du topaktuelle Steckdosen im Haus hast, wenn das Fundament durch ist.

Schon 2014 (also kurz nach Supportende) gabe es schon Sicherheitslücken, die nicht mehr gefixt wurden ( https://www.welt.de/wall-street-jou...at-erste-Sicherheitsluecke-fuer-Ewigkeit.html ). Und jetzt überleg mal, wie die Situation nach 4 Jahren wohl ist... Nochmal: Windows XP heute noch (egal in welchem Setting) zu betreiben ist (für die eigenen Daten und für "das Internet" - Spamschleudern) aus Sicherheitsgründen unverantwortlich. Punkt. Diskussion Ende. Ebenso unverantwortlich ist, es Linuxversionen nach deren Supportende zu betreiben.

Dass von einem Informatiker derartiges kommt erschreckt mich sehr!

 

[jmar83]

Grundsätzlich hast Du sicher recht, und danke für den Link!

Und einen speziellen Vertrag für (nicht öffentliche) Fixes von MS hab ich natürlich nicht. (Glaube das eine oder andere Bankomatensystem lief kürzlich noch mit XP, mit der "embedded Version"?)

 

[Joe User]

(Glaube das eine oder andere Bankomatensystem lief kürzlich noch mit XP, mit der "embedded Version"?)

Die werden auch noch (gegen Cash) supportet.

 

[danton]

Also mit irgendwelchen alten Systemen sehe ich das so: Wenn man nicht die M$-eigenen Sachen verwendet (wie die Windows-Dateifreigabe oder den IIS oder den IE), und man noch mit aktuellen Versionen von z.b. von Apache, PHP, MySQL, Tomcat, OpenOffice, Firefox, Spybot, Anti-Virus, Scriptblocker-Plugins was auch immer arbeitet dann ist das "halb so schlimm"...

Nein, ist es eben nicht. Auch Anwendungen, die nicht von MS sind, bedienen sich zahlreicher Komponenten des Betriebssystems, die eben bei allem, was älter als Windows 7 ist, keine Updates mehr bekommen. Damit sind auch diese von Sicherheitslücken betroffen, die nicht mehr gefixt werden.

Wenn es für ein problematisches, Windows-eigenes Feature mal keinen Fix mehr gibt, dann schaltet man es am besten einfach aus falls möglich!

Dazu muß man aber erst mal wissen, in welcher Komponente denn Probleme vorhanden sind. Da es keine Sicherheits-Hinweise von MS gibt, wenn der Support ausgelaufen ist, wird das natürlich schwierig. Im übrigen: Wenn es unbedingt sein muß, stellt MS seinen Enterprise-Kunden auch weiterhin Sicherheits-Updates und sogar Bugfixes zur Verfügung - ist letztendlich nur eine Frage des Geldes.

Von daher kann man Windows oft länger brauchen, man muss nur z.b. an Windows Server 2003 denken (Support von MS von 2003-2016?), welches heutzutage teilweise noch im Einsatz ist. (Gut, wohl grösstenteils innerhalb von privaten Netzwerken, eher seltener im öffentlichen Internet..) Ubuntu LTS find ich aber auch nicht schlecht in dieser Hinsicht, auch Red Hat bietet mit seinem "Enterprise Linux" etwas an was sich auf ne bestimmte Zeit bewährt. (=Investitionssicherheit)

Genau das ist der Punkt. Ältere Systeme kann man in geschlossenen Systemen weiter einsetzen, bei denen man genau kontrollieren kann, was an Daten ins Netz reinkommt - das kann man aber nur mit einem Punkt sicherstellen: Komplette Trennung von Internet.
Bezüglich Ubuntu LTS: Was viele dabei nicht bedenken, ist die Tatsache, dass sich das LTS nur auf das Haupt-Repository bezieht. Die Repositorys universe und multiverse bekommen auch bei der LTS nur wenige Monate Support. Will man Software daraus verwenden, muß man doch wieder alle 6 Monate updaten, um (Sicherheits-)Fixes zu bekommen.
Dazu kommt noch die durchaus berechtigte Kritik an Release-basierten Distributionen, dass diese i.d.R. nur Sicherheitspatches zurückportieren, die auch als solche beim Upstream gekennzeichnet wurden (so dass u.U. Sichersheitslücken bei der Distribution ungepatcht bleiben). Und das so ein Backport auch mal in die Hose gehen kann, hat Debian vor ein paar Jahren mit einem Backport für OpenSSL sehr eindrucksvoll bewiesen.

 

[jmar83]

Danke für Deinen Beitrag!