Also wenn ich raten müsste: Die eine Richtung wird durch den Upload beschränkt, die andere durch eine 100 MBit/s Verbindung. Wobei, letzteres kann Zufall sein.
Beiträge von frank_m
-
-
Nein, das ist nicht wirklich falsch, da man mit diesem Schalter auch sehr schnell und sehr übersichtlich den tatsächlichen Durchsatz pro Stream sehen kann.
Sagt aber am Ende nichts über die Leistungsfähigkeit der Verbindung aus, sondern eher über deine TCP Settings. Man sollte sich halt Gedanken darüber machen, was man messen will und wie man das am besten erreicht. Hier geht es eindeutig um die Übertragungskapazität zwischen zwei Endpunkten, und die misst man nicht zuverlässig mit einem Stream, da allein schon unterwegs dafür zu viel schief gehen kann.
-
Reverse Name Lookup hat ja nichts mit der Domain zu tun, sondern mit der IP. Und die landet so oder so bei Netcup.
-
Nee. Spätestens um 18 Uhr ist Ende. Aber wenn weg, dann weg. Auch schon um 13 Uhr.
-
DHCP hat er ja nicht, warum auch immer.
also beim WS hab ich eine DNS von 192.169.1.1
Das ist vermutlich ein Tippfehler, richtig? Es dürfte 192.168.1.1 sein.
-
-P 1 ist falsch. Mindestens 4, besser 10.
-
Ach, hast du vielleicht das DNS Setup vergessen? Das ist das Problem bei manueller Konfiguration: Man muss an alles selber denken.
-
Dann führe auf dem WS doch mal "tracert http://www.heise.de" aus, um zu sehen, wie weit du kommst.
-
Ok. Wenn du an der OPNSense nicht so allzuviel herumgespielt hast, dann müsste Windows darüber ins Internet kommen, ausgehend. Eingehend ohne Portweiterleitung natürlich nicht.
-
Ich rede von den Routen. Wie hast du die Routen auf dem Windows Server eingerichtet? Das ist ja auch der entscheidende Punkt für den Zugriff via VPN.
-
Bist du dir sicher, dass du die brauchst? OPNSense bietet eigentlich für seine Clients automatisch Netzzugriff via NAT. Ich hätte den Konfigurationsbedarf eher auf Windows Seite gesehen, da du ja mit einer statischen Konfiguration arbeitest.
-
Nein, das habe ich in der Firewall noch nicht eingestellt.
Das solltest du erst mal ändern, bevor du dich um VPN kümmerst. Der Weg vom Windows Server über seine Firewall inklusive aller notwendigen Routen ist essenziell, vorher brauchst du mit VPN und anderen Zugängen nicht anzufangen. Das wird dann eh nicht klappen, darüber auf den Windows Server zu kommen.
also VPN funktioniert nach wie vor nicht.
Was heißt "funktioniert nicht"? Die VPN Verbindung? Zugriff über VPN auf die OpenSense? Zugriff über VPN auf den WS? Letzteres kann noch nicht funktionieren, siehe oben.
-
Und du kannst auch vom WS über den OpenSense ins Internet?
-
D.h., es läuft jetzt alles?
-
die LAN Ip auf dem Opnsense Server ist weg also nur noch 0.0.0.0
Oha. Das hat aber weder was mit VLAN noch mit OpenVPN zu tun. Da stimmt ja die Basiskonfiguration noch nicht.
und auf dem WS war die IP wieder auf automatisch gestellt.
Das hätte ich auf dem VLAN auch so erwartet. Und das native Interface ist ja eh deaktiviert. Ist es doch hoffentlich, oder?
-
Vermutlich bis du die Informationen zur Verfügung stellst.
-
Ich fasse noch mal zusammen, was ich verstanden habe:
- Du hast einen Windows Server, der hinter einem anderen VPS mit OpenSense hängt. D.h., der Windows Server hat die priämre Netzwerkkarte deaktiviert und kommuniziert nur über ein VLAN mit der OpenSense. Die OpenSense ist auch Defaultgateway für den Windows Server
- Auf der OpenSense läuft ein OpenVPN Server für die Verbindungen von außen
- Wenn keine VPN Verbindung besteht, kannst du vom Windows Server aus die OpenSense pingen
- Wenn eine VPN Verbindung besteht, geht es nicht mehr.
Ist das soweit korrekt?
Ist auf beiden Seiten des VLANs ein passende IP aus dem gleichen Subnetz eingerichtet? Stimmen die Routen auf dem Windows Server und auf der OpenSense?
Wird für die VPN Clients NAT gemacht auf der OpenSense oder routest du den VPN Traffic vollwertig?
-
Ich wüsste nicht, was man da im SCP einstellen könnte. Das /64 Netz ist immer standardmäßig drin, und editieren kann man eigentlich nur die Reverse Name Lookups.
Hast du die Firewall überprüft?
-
Das hier kennst du?
Zusätzliche IP Adresse konfigurieren – netcup Wiki
Leider weiß ich nun nicht wie ich diese am Server konfigurieren soll, da die neuen IPs ein anderes Gateway als die inkludierte IP verwendet.
Üblicherweise werden diese Zusatz-IPs auf deine bereits vorhandene IPv4 Adresse geroutet. Ein eigenes Default Gateway etc. haben sie nicht (Subnetzmaske /32). Deshalb wird abgehend auch immer die ursprüngliche IP des Servers verwendet. Die zusätzlichen IPs dienen nur der zusätzlichen Erreichbarkeit aus dem Internet.
Die hat er immer noch. weil ich mir dachte, irgendwann fällt mir mal was ein, wozu ich sie verwenden könnte.
Mehrere konkurrierende Serverdienste auf dem gleichen Port sind ein Argument, z.B. ein OpenVPN Server auf TCP Port 443 parallel zum Webserver.
-
Welche Domain wird denn in der Anfrage an den nginx genannt? Die duckdns oder die netcup Doman? Das müsstest du in den Logs des nginx ja sehen können. Wenn es die netcup Domain ist, dann fehlt dem Proxy vielleicht nur die Konfiguration für die 2. Domain.
