Nein, vergleichbare Probleme hab ich nicht. Aber dann ist es an der Zeit für eine detailliertere Analyse nach dem Vorschlag von ThomasChr. Schau dir mit tcpdump präzise an, wo die Pakete verloren gehen, ob eingehend oder ausgehend.
Beiträge von frank_m
-
-
das Problem hat aber in der Natur der Dinge in gewisserweise die selbe Ursache,
weil ja bei PPPoE ja auch ein Tunnel intern verwendet wird ..., nur etwas anders;
Ja, das sehe ich auch so. Es passiert immer, wenn man aus irgendwelchen Gründen die MTU bzw. MSS reduzieren muss, z.B. durch zusätzlichen Protokoll-Overhead.
axstet: Die Probleme mit dem Forum sind ja bekannt, und die auf deinem server1 hast du vermutlich selber zu verantworten.
-
Jedenfalls sind die MSS Probleme häufig auf zu strenge ICMPv6 Einschränkungen zurückzuführen. Kommt besonders gern an PPPOE Anschlüssen vor, liegt aber eher am Server.
-
Meinst du nicht, dass es eine gute Gelegenheit wäre, auf ein OS mit längerem Support zu wechseln? Aufgrund des absehbaren EOL von Cent OS 7 müsstest du ja eh bald aktualisieren.
Die Postfix Konfig wird man ja rüber kriegen, auch auf neuere Versionen.
-
Aus Freundlichkeit, OP darf gerne mit uns Deutsch üben wenn OP das möchte.
Wenn du in seine Beitragshistorie ab 2015 schaust: Er hat definitiv Deutsch als Muttersprache. Vielleicht mag das in der ursprünglichen Version des ersten Beitrags nicht deutlich geworden sein.
-
Warum reden wir hier jetzt eigentlich englisch, wo doch offensichtlich alle deutsch sprechen? Der erste Beitrag mag schlecht gewesen sein, wurde aber überarbeitet. Er ist nicht aus einem automatischen Übersetzer, so viel steht fest.
-
Ist das jetzt wirklich so schlimm? Ich finde, die Frage ist klar. Es geht darum, die Datenbank vom ursprünglichen Server zu lösen und auf einen eigenen Server auszulagern. Die Verbindung zwischen beiden Servern soll über ein VLAN erfolgen. Die Sorge ist, dass die VLAN Verbindung instabil ist, besonders bei kleinen Aufrufen.
Grundsätzlich hätte ich gesagt, dass ist der Weg, den man häufig geht, also die Datenbank auf einen eigenen Server auszulagern. Zur Stabilität des VLANs kann ich nur sagen, dass ich zwischen einem Windows Server und einem Linux Server bislang nie Probleme damit hatte. Aber die Verbindung ist auch nicht besonders ausgelastet gewesen. Von daher bin ich dafür der falsche Ansprechpartner.
-
Ich kann mir durchaus vorstellen, dass die Probleme was mit dem Patch zu tun haben. Immerhin werden RDP Probleme im Zusammenhang mit "Routing und Remote Access" im offiziellen Changelog als gelöst beschrieben. Vielleicht führt diese Lösung bei dir zu Problemen. Ausgelöst wurden die Probleme wohl durch den März Patch. Musstest du damals was umstellen? Da würde ich jedenfalls noch mal nachhaken.
Es kommt ja durchaus mal vor, dass Microsoft bei Patchdays Bugs einführt. Aber wenn es offiziell als Lösung gekennzeichnet ist, dann kann es sehr lange dauern, bis sich was tut. Falls es ein Bug ist und nicht doch nur das Aufdecken eines Konfigurationsfehlers.
-
Die Firewall ist ja die gleiche wie in der Pro Version, von daher bin ich dann wohl bestens "eingearbeitet" als jahrelanger Windows Nutzer.
Die Firewall ist nicht identisch. Und auch eine jahrelange Nutzung garantiert nicht ein umfassendes Wissen. Zu Hause betreibst du dein Windows mit großer Wahrscheinlichkeit nicht mit einer öffentlichen IP direkt am Internet und bist folglich nie in der Situation, die Firewall entsprechend einrichten zu müssen.
Der entscheidende Unterschied ist aber: Zu Hause kannst du nur dein Netz kaputt machen. Aber hier hängt mehr von deinen Entscheidungen ab. Wenn dein Server gehackt wird und die IP und das Subnetz deshalb auf irgendwelchen Blacklisten landen, dann können plötzlich haufenweise andere Nutzer ihre VPS nicht mehr nutzen wie vorgesehen. Das Forum ist voll davon, suche mal nach Mail in Zusammenhang mit Microsoft. Sei dir bewusst: Du bist verantwortlich für das, was mit deinem VPS passiert, bis hin zu finanziellen Entschädigungsforderungen und strafrechtlichen Konsequenzen.
Deshalb reagiert man hier im Forum sehr empfindlich auf offensichtliche Unerfahrenheit im Zusammenhang mit Windows Servern. Das sind nämlich in 90% dieser Fälle die Ursachen, die zusammenkommen müssen, um solche Probleme auszulösen.
-
Es ist ein Irrtum, zu glauben, ein Windows Server sei leichter einzurichten, als ein Linux Server. Das Gegenteil ist der Fall, Windows ist erheblich komplexer und fordert Größenordnungen mehr Einarbeitungszeit, als Linux, um es sicher und funktional hinzubekommen. Wenn dein Argument wirklich ist, dass du dich in der IT nicht auskennst, dann ist ein Windows Server das letzte, womit du anfangen solltest. Das gilt insbesondere für Themen wie Routing und Firewall.
-
Was man vielleicht bedenken sollte: Falls du mal planst, ein zusätzliches IPv6 Netz zu bestellen, dann ist das Routing Ziel für dieses Subnetz die standardmäßige IPv6, die vorgegeben ist. Die muss dann auf jeden Fall vorhanden sein.
Man kann allerdings problemlos mehrere IPv6 Adressen anlegen, und über die preferred_lft festlegen, welche bevorzugt für abgehenden Datenverkehr benutzt wird. In netplan sieht das so aus:
Codeethernets: eth0: addresses: - 46.38.XXX.YYY/24 - 91.204.XXX.YYY/32 - 2a03:4000:XX:YYY::1/64 - 2a03:4000:XX:YYY::2/64: lifetime: 0 - 2a03:4000:XX:YYY:ZZZZ:ZZZZ:ZZZZ:ZZZZ/64: lifetime: 0Da gibt es aber bestimmt auch was für die /etc/network/interfaces.
-
Es wäre nicht das erste Mal, dass ein Update einen Konfigurationsfehler aufdeckt, der vorher nicht auffiel. Aber bitte, du musst mit der Einschränkung leben.
Vielleicht eine gute Gelegenheit, das Setup als ganzes noch mal zu überdenken.
-
Heißt der Dienst wirklich "Routing and Remote Access"? Welche Windows Server Version verwendest du? Bekommt die noch Support?
Schuld ist der Patchday,
Das wage ich zu bezweifeln. Ich vermute eher eine falsche Konfiguration. Die von dir beschriebenen Probleme sind typisch für falsche Routen, überschneidende Subnetze usw. Da würde ich zunächst anfangen.
-
Inzwischen steht dort "no network access".
Und was hast du geändert?
ch kann ohne Probleme pingen als auch meinen Traffic von zu Hause über den Wireguard-Tunnel durch den Windows Server dann ins Internet NATen.
Ok. Damit ist Netcup dann auch raus, denn der Netzzugriff funktioniert ja offensichtlich.
D.H. hier macht nur RDP Probleme.
Dann musst du dort analysieren, woran es liegt. Läuft der Service, ist der Port offen, lauscht er auf dem richtigen Interface?
OpenVPN allerdings funktioniert gar nicht mehr richtig, das Bild bleibt einfach weiß, keine Log-Einträge, nichts.
Welches Bild? RDP?
Vielleicht hat ja MS die NAT-Funktionalität in WinServer gestern kaputt gemacht?
Oben hast du geschrieben, dass NAT funktioniert. Und für RDP brauchst du kein NAT.
-
Netcup ändert nur was am KVM Backend. Das hat auf deine Netzwerkverbindungen und Dienste in der VM keinen Einfluss. Wenn es da Probleme gibt, dann durch den Patchday. Ich persönlich vermute allerdings eher Konfigurationsfehler.
Tut sie halt nicht.
Dann würde ich da an deiner Stelle noch mal genauer draufgucken. Die Anzeige ist kein Zufall.
Du musst Schritt für Schritt analysieren: Netzwerkverbindung, VPN Tunnel, RDP Service. Alles noch da, wo es hingehört?
-
Ob die Wireguard Verbindung Internetzugang anzeigt, hängt davon ab, welche Routen du darüber leitest. Wenn die Default Route aufs VPN zeigt, dann gibt es dort auch Internet.
Die WG Verbindung selbst steht und ich leite darüber Traffic von zu Hause aus, also dass dieser Traffic die public WAN-IP des VPS nutzt.
Das machst du echt mit einem WIndows Server? Oh Mann. Das würde ich mir 2x überlegen.
-
... und Windows 7 vorinstalliert ...
-
Ja, Zerotier vereinfacht die Administration, besonders wenn es um komplexe NAT Szenarien geht. Das kann man nicht wegdiskutieren. Nutzerfreundlich ist es.
funktioniert (siehe Screenshot) .. aber mit 10.8.0.3 ist das ja nicht öffentlich.. wie gehts weiter ?
Ja, sieht doch gut aus. Dein Heimnetz ist also 10.8.0.0/24? Oder eine größere Subnetzmaske? Ist eigentlich auch egal. Dann folgendes:
Codeiptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.3:8080Wenn jetzt jemand an die öffentliche IP deines VPS auf Port 8080 ein Paket schickt, dann kommt es an einem Heimrechner auf Port 8080 an. So kannst du nun diverse Kombinationen aus Quellport, Zielport und Zieladresse generieren, und deine Dienste von außen erreichbar machen.
-
Komisch, das sieht so aus, als ob deine Pakete deinen VPS gar nicht verlassen.
Spielt dir da vielleicht eine Firewall einen Streich?
-
Bei Vodafone LTE gibts keine öffentliche IP, genau wie bei den meisten Kabelanbietern.
Ach, ich dachte, genau dafür sollte der VPN Tunnel sein.
Ich würde das technisch so lösen: Der VPS ist VPN Server und in deinem Heimnetz (auf dem Router oder auf einem dedizierten Gerät wie z.B. einem Raspi) ist der VPN Client. Dann baut der Client ausgehend eine Verbindung auf und hält die auch aufrecht. Über diesen Tunnel kannst du dann vom VPS aus deine Clients im Heimnetz jederzeit erreichen. Du musst lediglich im Routing Setup dafür sorgen, dass dein VPS weiß, wo es dein Heimnetz findet (hinter dem VPN Tunnel), und dass dein Heimnetz dein VPN Netz kennt (z.B. durch eine statische Route im Router, wenn der Router nicht selber VPN Client ist). Dann muss noch klar sein, dass VPN für interne Netze kein NAT macht und der Rest geht fast von allein.
