Schnattis Server wird gewartet

[tobyps]

Teamviewer guckt sich dafür zb das Nutzungsverhalten an, ich wurde mit privater Nutzung schon fälschlich als gewerblich eingestuft
Dann musst du denen kurz schreiben was du machst und dann setzen sie die Verbindung zurück, wenn sie dir glauben und das passt.

Ginge es denn nicht prinzipiell auch mit Boardmitteln also dem Remotedesktop von Windows?
Ich habe den bisher nur innerhalb des eigenen Netzwerks genutzt, daher weiß ich nicht wie sicher der ist. Aber im Zweifel verbindest du die heimische Fritzbox mit der Fritzbox auf der Arbeit (VPN zwischen Fritzboxen ist relativ einfach und AVM hat da gute Anleitungen) und dann ist das nur intern.
Aber da kennt sich drdope vielleicht besser aus.

[Schnatti]

Naja, meine Aussage "Ich mache das hier nur um privat Ruhe zu haben." wird vermutlich nicht reichen, insofern weiß ich nicht ob es nicht Beschiss wäre. Wohlwissend, dass ich nicht vorhabe hier 17x im Monat Zugriffe zu haben. Es geht ja "nur" um Problemlösungen...aber die sind halt gewerblicher Natur.

Das mit dem Remotedesktop hatten wir schon mal hier im Thread, müsste ich mal suchen, war aber eine ganz widerliche Sache geworden und funktionierte überhaupt nicht.
Eine Tunnellung per Fritzbox-VPN über meinen Laptop klappt zwar, aber reicht leider nicht, weil die betriebliche Fritzbox im LAN-Szenario nur das äußerste Gerät und DSL-Modem ist und dahinter noch der BSB-Router kommt, der quasi im Stealth-Modus ist und nichts durchlässt...an dessen Port-Konfiguration rumzupopeln lasse ich lieber bleiben.
Ich komme also nicht tief genug in's Geschehen, auch nach Herstellen des VPN versanden sämtliche pings auf Geräte der Firma (auch der zweite Router selbst) im Nirgendwo.

Das geht also für mein Dafürhalten mit dem TeamViewer deutlich komfortabler, aber ist eben auf Mithilfe von innen angewiesen.
Früher ging der RDP-Zugriff über die Windows-OnBoard-Funktion sensationell einfach, aber auch das ist inzwischen eine Nullnummer - das muss dann denke ich der Router auch "wollen", sonst geht da nix.

[drdope]

Ich nutze hier kommerziell Anydesk Lite, weil es für meine Zwecke die günstigste Lösung ist und der Hersteller in .de sitzt (ich versuche wo immer mir möglich lokale/regionale Anbieter zu unterstützen).

--> https://anydesk.com/de/features
--> https://anydesk.com/de/bestellen

Ich sehe statische VPNs als eher kritisch, wenn man nicht genau weiss warum und weshalb man so was einrichtet.
Das ist quasi ein Blankoscheck an denjenigen, den man darauf Zugriff gewährt (da gehört schon eine große Menge Vertrauen an die Gegenseite dazu).
Worst Case -> der maligne/böswillige Ansatz wäre -> vorsätzliche Sabotage, um damit die eigene Dienstleistung zu verkaufen.

Ich halte es eher so, daß ich meine Kunden dahingehend erziehe, nach außen keinen permanenten Lücken (offne Ports) in ihrer Firewall zu haben, weil ich mich sonst auch auch für die dahinter liegenden Dienste und deren Pflege in Haftung sehe.

Sprich ich müßte darum kümmern, das weder die Router-Software selbst , noch der Dienst dahinter (hier der erreichbare VPN-Server), durch den offenen Port kompromittiert werden kann.
Das kann ich als Einzelperson für mehrere, unterschiedliche Endpunkte mit unterschiedlicher Software realistisch nicht darstellen.

[Schnatti]

Das mit dem "Wartungstool" kann ich vertagen, bis meine größeren Sorgenkinder mal temporär schlafen gegangen sind und hier wieder Normalität eingekehrt ist.
Aktuell nagt einfach die inaktive Server-VM und das ätzende Verbindungsproblem.

Solange noch folgendes:
Das Standard-Wartungsmodell des Softwareanbieters sieht die Fernwartung über permanente VPN seit ich die Firma kenne generell vor, wobei seit ein paar Jährchen auch dererseits vermehrt der TeamViewer samt Aktivierung der Sessions durch uns Endnutzer zum Einsatz kommt.
Ich vermute jetzt einfach mal, dass die Fernwartung per Standleitung in erster Linie für die Pflege von Server und Backuprechner vonnöten ist. Bei beiden habe ich ja die "doofe" Situation, dass nur per Konsole ein Hauch einer Oberfläche visuell ausgespuckt wird, die eigentlichen Betriebssysteme dahinter sind für mich (und Kollegen in meiner Lage) ja unerreichbar, man sieht sich stets nur in der Branchensoftware werkeln.
An dem Modell werde ich nichts ändern können...das ist quasi ein Oligopol und bei der Konkurrenz geht es teils noch restriktiver zu.
Und solange ich nicht weiß, was der Server an Portfreigaben benötigt, um regulär funktionieren zu können, solange komme ich bzgl. der Annullierung bestehender Portfreigaben oder dem Rausschmiss des zweiten Routers nicht voran und würde es vermeintlich auch nicht wollen.

Um nochmal den Fokus auf Brennpunkt Nr. 2 zu legen, Brennpunkt Nr. 1 wird sich ja nur von außen lösen:



Ist sowas normal?
Dass quasi ohne konkrete Angabe eines DNS der nslookup nicht funktioniert und auch ein "Server: unknown" zustandekommt?
Ich werde den Verdacht nicht los, dass mein Server-per-LTE-Problem irgendetwas mit dem DNS oder DynDNS zu tun hat.



Hier mal ein Log aus der FritzBox, zeitlich von unten nach oben zu lesen.

[drdope]

Kann es sein, daß in den APN-Einstellungen für die o2-Sim keine Login-Daten hinterlegt sind (lt. o2 braucht man die nicht; aber die Fritzbox braucht die zwingend, oder hast du einen ggf. gebrandeten Huawei E1550 Stick).
Siehe:
--> https://www.o2apn.de/#qelp-apn-settings

sowie Punkt 3 und 4 hier:

3 Zugangsdaten in FRITZ!Box eintragen
Die FRITZ!Box stellt ohne Zugangsdaten keine Internetverbindung her. Tragen Sie in der FRITZ!Box daher auch dann Zugangsdaten ein, wenn diese für den Internetzugang Ihres Mobilfunk-Betreibers eigentlich nicht erforderlich sind:

4 Fehler von Huawei E1550
Beim Einsatz des Mobilfunk-Sticks Huawei E1550 erhält die FRITZ!Box vom Mobilfunk-Stick keine DNS-Server. Die Namensauflösung von Internetadressen (z.B. avm.de) und der Zugriff auf Internetserver sind dadurch nicht möglich. Es handelt sich dabei um einen Fehler in der Firmware des Mobilfunk-Sticks.

--> https://avm.de/service/fritzbox/frit...nicht-moglich/

[Schnatti]

Als Surfstick ist ein Huawei E3372 im Einsatz. (Support scheint es quasi kaum zu geben vom Hersteller, die Webseite ist ja ein wenig...spartanisch).

Die von dir verlinkten APN-Daten sind für den ursprünglichen LTE-Zugang der SIM per privater IP korrekt und hatte ich auch initial drin, daraufhin schimpft aber der DynDNS-Dienst. (letzter Screenshot)
Nach dem kostenpflichtigen Upgrade auf eine öffentliche IP benötigt man andere APN-Zugangsdaten, die ich in der Fritzbox auch eingetragen habe. Das war ein bisschen Gefriemel, weil sowohl der Surfstick (eigene Konfig bei USB-Konnektion) als auch die Fritzbox (APN netpublic und Einwahlnummer *99#, die sonst wie von dir verlinkt eigentlich nicht gebraucht wird) noch ein wenig gestreichelt werden wollten, aber es funktionierte.

Laut Fritzbox werden dann in diesem Szenario angeblich auch DNS-Server zugeteilt, siehe u.a. Screenshot



(da war zwar noch der verkehrte Telekom-Login irgendwie, aber das hat sich inzwischen gegeben)

Die Fritzbox hat nun also bei LTE-Zugang zugewiesene DNS-Server, ich habe nun aber das Gefühl, dass die im Rahmen der Ethernet-Konfiguration nicht an den Server durchgereicht werden.

Der gemeinsame und jeweils in den Netzwerkadapteroptionen hinterlegte Gateway aller LAN-Rechner ist der bintec-Router 10.65.147.90. Für meine Windows-Klient-PCs kann ich das so behaupten, beim Server gehe ich davon aus, weil die Technik-Hotline so a la "na wir tragen nur den Gateway ein und wenn der sich nicht geändert hat ist da nix" geblafft hat, als ich danach fragte.

Vielleicht hat nun im "verkabelten DSL-Szenario" der bintec die DNS-Server-Funktion onboard am Laufen und alles geht schick (ich wüsste jedenfalls nicht im FritzOS gesehen zu haben, dass die Fritzbox da auch DNS-Server vermittelt) - und im "LTE-Szenario" wiederum ist die Fritzbox plötzlich mit DNS-Servern seitens o2 konfiguriert (?) und es klemmt - so in der Art?

Wenn ich nicht wüsste, dass es wieder potentielles Technik-Harakiri ist, könnte man den bintec ja mal komplett überspringen, den Switch direkt an die Fritzbox klemmen und letzterer die feste IP des Netzwerk-Gateway/bisherigen bintec zuweisen.
Dann sollten doch weiter alle Rechner online sein und ich hätte definitiv nur eine Router-Instanz im System, die DNS-Server konfiguriert hat.

[drdope]

Wenn ich nicht wüsste, dass es wieder potentielles Technik-Harakiri ist, könnte man den bintec ja mal komplett überspringen, den Switch direkt an die Fritzbox klemmen und letzterer die feste IP des Netzwerk-Gateway/bisherigen bintec zuweisen.
Dann sollten doch weiter alle Rechner online sein und ich hätte definitiv nur eine Router-Instanz im System, die DNS-Server konfiguriert hat.

Häng doch einfach mal ein Rechner oder Laptop direkt per Kabel an die Fritzbox (unter Umgehung der restlichen Netzwerkstruktur);
Wenn es dann läuft weißt du, daß das Problem hinter selbiger (aller Wahrscheinlichkeit nach der Bintec) zu suchen ist.
Hast du die gleichen Probleme wie aktuell, liegt irgendwas in der Konfiguration der Fritzbox selbst im argen.

Das wäre (imho) die einfachste Variante die Fehlerquelle einzugrenzen.

[Schnatti]

So werde ich's mal machen, vielleicht bringt es Erhellung...
Wobei die Kniffligkeit ja am Server liegt und nicht an meinem Laptop, so dass ich mal schauen muss mit welchen indirekten Aussagen ich mich dann zufrieden geben muss.

Jetzt bin ich aber erstmal heimgeradelt und muss - so schnell komme ich da ad hoc sowieso nicht wieder hin.
Wobei freundlicherweise der angeschriebene Techniker mir zum Sonntagmittag während meiner Rückfahrt den ESXi-Login übermittelt hat. (zumindest das Passwort hat er gemailt, wehe der Nutzername ist nicht root...)
So dass ich eh überlegen muss, evtl. heute Abend nochmal hinzugondeln, um die Nerven meiner Kollegen morgen ein stückweit zu wahren.

Werde berichten...

[Schnatti]

Also in einer nächtlichen Aktion habe ich den Server per ESXi-Shell wieder gestartet, war unkritisch.
Hat trotzdem lange gedauert, eh das Früchte trug, weil in Abwesenheit des Servers das Backup-System sich dessen IP-Adresse (vermutlich irgendwie virtuell) krallt und Server light spielt. In dem Moment wo ich mit frisch gestartetem Server reingrätsche, der von Haus aus die dann gleiche IP mitbringt, ist das LAN-technisch nicht so der Traum...
Bis ich dann (vermutlich eher zufällig) die Backup-VM angehalten, dann die Server-VM und dann erst wieder die Backup-VM neugestartet habe, hat das dann doch noch ein wenig gedauert...aber ab da läuft dann alles wieder schnuckelig.

Dann brauchte es nur noch die DB-Synchronisierung beider VM und mit der kannte ich mich (wenngleich per Konsole ersichtlich) gleich gar nicht aus. Hat die Hotline dann heute gemacht...nach 8 Stunden warten mit 2 Knopfdrucks.
Wer sich an Seite 16 des Threads erinnert, das war das Interface hier:



Blöderweise hat es bei den ganzen Server-Aktionen dann auch noch die System-Uhrzeiten verhagelt, so dass die ganzen Buchungen heute fast um 7 Stunden nach vorne zeitversetzt stattfanden. Und da ich an die Server ja nicht rankomme, war ich auch hier wieder an die Technikabteilung gebunden. Läuft.

Das positive noch:
Ich habe meinen quasi defekt geglaubten alten Laptop ausgebuddelt, der noch mit Win 7 läuft und über den im SlowMo-Modus (Installation vom vSphere-Client 15min ) tatsächlich Zugriff auf den Server-ESXi bekommen.
Ich war so frei und habe die Server-VM auf autostart bei ESXi-Start gestellt, sonst fange ich ja nächstes Mal wieder an zu kräpeln...eigentlich hatte ich da noch eine Frage zu, finde aber gerade den Screenshot nicht.

[drdope]

Das Backupsystem hat (imho im Rahmen dessen, was es kann) gemacht was es soll, in dem es die IP des Server "geklaut" hat.
Ich gehe (u.A. wg des DOS-GUIs) davon aus, daß die Clients den Server via einer statischen IP-Adresse erreichen und nicht via Hostname.

Wenn der Backupserver eine andere IP hätte, würde das bedeuten, daß du jede Clientkonfig ändern müßtest.

Ich behaupte mal es gibt ein definitiv Procedere seitens des BSB für die Übergabe von Hauptserver zu Backupserver und zurück im laufenden Betrieb und zurück, daß dein Szenario (2 Systeme mit gleicher IP befinden sich im gleichen LAN) ausschließt.

Der SloMo-Modus des alten Laptop ist vermutlich dessen nicht vorhandener SSD geschuldet.
Sobald man sich dran gewöhnt hat, mit einem SSD-basierten System zu arbeiten, ist jedwedes System ohne SSD/mit HDD einfach nur noch qualvoll langsam.

[Schnatti]

Ich behaupte mal es gibt ein definitiv Procedere seitens des BSB für die Übergabe von Hauptserver zu Backupserver und zurück im laufenden Betrieb und zurück, daß dein Szenario (2 Systeme mit gleicher IP befinden sich im gleichen LAN) ausschließt.

Das übrigens hat der Mitarbeiter heute am Telefon negiert.
Es gibt dererseits keine Abgleichroutine für die Server, beim Start im Falle einer bereits vergebenen gleichen IP "hängen zu bleiben" oder einen Plan B bei der Netzwerkanmeldung zu initiieren. Laut ihm ist das ein bekanntes internes Problem, dass das nicht entsprechend gescriptet ist. Beide Server wären dann seiner Aussage nach wirklich mit gleicher IP angemeldet.
Wenn man dann also am Klient-PC Warenbuchungen o.ä. machen würde hätte er schon öfter erlebt, dass daraus traumhafte Szenarien entstehen, weil die Clients dann nicht wissen auf welchem Server der Vorgang die DB füllen soll und dann kommen sensationelle Puzzles bei raus...
Warum das keiner ändert, wenn es schon bekannt ist...?

[drdope]

Warum das keiner ändert, wenn es schon bekannt ist...?

Ist Aufwand und kostet Geld; und daraus resultierende Probleme kann man ja dem (unwissenden) Kunden in Rechnung stellen -> Win-Win für den Anbieter!


Was du dir def. für die Zukunft merken mußt -> bevor der Backup-Server in den Produktiv-Betrieb geht muß der Hauptserver offline sein und anders herum (zwei Systeme mit gleicher IP sind bäh...).
Vermutlich handhaben die das intern genau so; es werden manuell IPs geändert, um das Problem zu umgehen; den zeitlichen Aufwand dafür berechnet man Kunden...


Und ja ich ich gerade wieder mit einem negativen Menschenbild unterwegs.

[Schnatti]

Ich war so frei und habe die Server-VM auf autostart bei ESXi-Start gestellt, sonst fange ich ja nächstes Mal wieder an zu kräpeln...eigentlich hatte ich da noch eine Frage zu, finde aber gerade den Screenshot nicht.

Da Isser!



So habe ich jetzt also den ESXi hinterlassen, vorher war die VM auf "Manueller Start" vom Techniker belassen (oder absichtlich gesetzt?) worden. Daher mein Wochenendproblem...

Ist es nur ein Darstellungsfe ler des vSphere Client oder warum taucht die Zeile da 3x auf?
Und was bringen mir die 60 Sekunden (oder mehr oder weniger) Delay?

[Schnatti]

Ich gehe derweil mal von einem Darstellungs-Bug aus, hier im letzten Satz unter Automatisches Starten aktivieren wird auch von ähnlichem gesprochen, und ggf. erst nach Neustart eine korrekte Abbildung erfolgt.

Die Bedeutsamkeit von Verzögerungszeiten habe ich angelesen, sind aber hier in diesem Szenario irrelevant, da erstens nur 1 VM läuft und zweitens keine anderweitigen Skripte im Vorfeld abgearbeitet werden müssen.

[Schnatti]

Nachdem ich bis heute immer noch keine Rückinfo seitens BSB habe, warum der Hauptserver keine Internet-Konnektivität zu zeigen scheint, habe ich derweil den Support des DynDNS-Service angemailt und um kurze Überprüfung gebeten.

Kompliment an dieser Stelle an selfhost.de , ich bin da (obwohl gar nicht direkter Kunde) nicht auf taube Ohren gestoßen und habe tatsächlich (und vglw. ungefragt) recht schnell recht viel Input bekommen, auch wenn man irgendwie zuerst das Problem zwischen meinen Ohren und nicht anderswo vermutete.
Die vermeintliche Lösung der nicht erfolgenden Aktualisierung der Fritzbox an den Nameserver trotz regelmäßiger Neuvergabe der IP-Adresse lag - nicht lachen - im kompletten Neustart der Fritzbox nach ein paar Minuten Trennung vom Netzteil.

Ich hielt

Starten Sie die Fritzbox einfach mal neu Stromausfall simulieren ca 1 bis 2 Minuten also kein Neustart per Klick.
Das löst so manches Problem.
Vorraussetzung ist natürlich das Sie an den DynDns Einstellungen der Fritzbox nichts verändert haben.

zwar zuerst nur für einen flapsigen Kommentar, aber siehe da...

Die dynamischen Nameserver-Rückmeldungen geschehen inzwischen wieder korrekt, das Fritzbox-Log schaut bspw. so aus:



Und inzwischen ist sogar auch - wie man im Log sieht - hier von daheim wieder ein Remote-Zugang auf die Box per Fritz-Fernzugang möglich, das ging die letzten Tage nicht. Fritzbox-Konfiguration einsehen von daheim.

Jetzt fehlt für's Erste "nur noch" die Lösung des DNS-Problems, zu dem ich gleich noch ein paar Daten liefere, vielleicht kann noch jemand helfen...