Jump to content

scnugg

Members
  • Gesamte Inhalte

    34
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von scnugg

  1. Hast Du dazu vielleicht nähere Infos? Wie kann ich am einfachsten steuern, welcher PC einen Member exklusiv erhält? Ich habe nur herausgefunden, dass ich das über die IP-Adresse einstellen kann. Aber so richtig verstanden und zufriedenstellend ist das irgendwie nicht. Ich habe dazu auch im Internet nichts weiter gefunden. Irgendwelche Tipps oder Tools? Danke. :)
  2. Hallo, danke für Deine Antwort. Mir ist schon klar, dass ein Paar nicht mehr als 1 GBit/s nutzen kann. Mehr erwarte ich auch gar nicht. Das Problem ist ein anderes. Nochmal zur Verdeutlichung: Ziehen client A und client B zugleich Daten von der NAS, haben sie beide 110 MB/s (wie gewünscht) => es wird 2 GBit/s ausgenutzt Ziehen client A und client C zugleich Daten von der NAS, haben sie beide 110 MB/s (wie gewünscht) => es wird 2 GBit/s ausgenutzt Ziehen client B und client C zugleich Daten von der NAS, haben sie beide 55 MB/s (unerwünscht!!) => es wird nur 1 GBit/s ausgenutzt Es sollten doch dem Switch und der NAS völlig egal sein, welche zwei clients zugleich Daten ziehen, so dass immer, wenn zwei beliebige clients die Daten von der NAS übertragen, die maximale Bandbreite von 2 GBit/s zur Verfügung gestellt werden sollte. Das ist bei mir aber eben nicht so, denn wenn client B und client C die Daten bekommen, wird nur 1 GBit/s statt 2 GBit/s ausgenutzt. Oder anders ausgedrückt: Für client A ist eine Bandbreite von 1 Gbit/s (110 MB/s) reserviert und alle anderen clients müssen sich das zweite 1 GBit/s (110 MB/s) teilen. Das ändert sich auch nicht, wenn noch ein vierter client D dazukommt. "Round-Robin" ist es bei mir insoweit nicht, denn die Verteilung erfolgt offensichtlich aufgrund von IP-Adressen. Oder habe ich Dich vielleicht nicht richtig verstanden? Dann sage ich "sorry" :cool: . Wenn die LAG-Funktionalität bei mir so, wie ich beschrieben habe, richtig ist, wäre für mich alles in Ordnung. Ich bin nur etwas verwundert, weil mal jemand gepostet hat, dass die gesamte LAG-Bandbreite immer GLEICHMÄSSIG auf alle clients verteilt wird... Wäre nur nett, wenn das jemand bestätigen könnte, der LAG im Einsatz hat, denn ich bin auf diesem Gebiet Newbie. :)
  3. Hallo, ich habe einen Netgear Switch GS108T (FW 5.4.2.22) und eine QNAP NAS TS-253A (FW 4.2.1). Netzwerkadapter und Kabel im Standard 1 GBit/s. Im Switch an zwei Ports und in der NAS ist LAG nach LACP (802.3ad) konfiguriert. Alle Clientrechner haben Windows 10 PRO 64Bit. Jetzt finde ich eine Sache etwas merkwürdig, die ich festgestellt habe: Nehmen wir an, ich habe drei Computer als clients wie folgt: client A IP=192.168.0.11 client B IP=192.168.0.12 client C IP=192.168.0.13. Wenn ich jetzt Daten von der NAS auf die drei clients zugleich übertrage, ist client B sozusagen der "Chef" und hat eine "garantierte" Übertraungsgeschwindigkeit von 1 GBit/s. das übrige 1 GBit/s aus dem LAG wird auf die clients A und C gleichmäßig verteilt, also ca. 110 MB/s bei clientB und ca. 55 MB/s jeweils bei clients A und C. Wenn allerdings z.B. nur die beiden clients A und C zugleich Daten von der NAS runterladen, haben beide nur 55 MB/s anstatt 110 M/s und das übrige 1 GBit/s, das dem client B "reserviert" ist, liegt ungenutzt brach. Auch wenn ich einen vierten client D in das Netzwerk integriere, bleiben bei clientB die 110 MB/s und die anderen drei Clients teilen sich entsprechend anteilig das übrige 1 GBit/s. Dieses ganze "Konstrukt" hat zwar den Vorteil, dass dem client B die Geschwindigkeit von 1 GBit/s "garantiert" ist, also privilegiert ist, egal, wieviele anderen clients zugleich Daten ziehen. Allerdings hat es ja auch den Nachteil, dass, wenn client B einmal nicht besetzt ist, die anderen clients auf 1 GBit/s des LAG verzichten müssen. Ich habe festgestellt, dass man über die Vergabe der IP-Adresse steuern kann, welcher client mit 1 GBit/s privilegiert ist und welche anderen clients die Bandbreite von 1 GBit/s teilen müssen, wenn client B einmal nicht besetzt ist. Dann ist mir noch aufgefallen, dass client B manchmal auch nur 55 MB/s hat, selbst wenn er als einziger PC Daten von der NAS zieht. Das weist dann für mich eher doch darauf hin, dass hier irgendetwas grottenfalsch läuft und die von mir vermutete "Privilegierung" eher ein Fehler statt Absicht ist. Wenn ich dann den Netzwerkadapter von client B deaktiviere und anschließend neuaktiviere, hat er wieder 110 MB/s. Kennt jemand diese Problematik und weiß, wie man es einstellen kann, dass, egal, welche clients Daten von der NAS ziehen, immer insgesamt 2 GBit/s zur Verfügung stehen und diese 2 GBit/s dann gleichmäßig auf alle clients verteilt werden? So hätte nämlich das LAG von der Funktionsfähigkeit auch eigentlich erwartet. Jedenfalls habe ich schon andere Netzwerkadapter, Windows Betriebssysteme, Netzwerkkabel und Einstellungen ausprobiert und komme an diesem Punkt einfach nicht weiter, bin daher für jeden Hinweis dankbar. Gruß :)
  4. scnugg

    IKEv2 13801

    Alles klar, dann viel Erfolg. Kannst ja mal berichten, was daraus geworden ist. Du siehst ja an meinem Beispiel, dass es grundsätzlich schon möglich ist, das Ganze zum Laufen zu bringen. Wird wohl irgendwas mit Deiner Zertifierungsstelle zu tun haben... Gruss :)
  5. scnugg

    IKEv2 13801

    Also mit Hyper-V Hosts hatte ich aber leider auch schon öfter Netzwerkprobleme, die mir unerklärlich waren und die ich meist nur durch Neuaufsetzen der VM lösen konnte. Hast Du alle Updates für server 2012 installiert? Ist auf dem server 2012 vielleicht irgendeine Software, die stört? Manchmal können sogar andere installierte Serverrollen/Features stören. Sonst würde ich an Deiner Stelle mal eine neue VM mit server 2012 frisch aufsetzen, als erstes Routing und RAS installieren und dann schauen, ob das Problem wieder auftritt. Ansonsten scheint wohl bei Deiner PKI irgendwo der "Wurm drin zu sein". Viel Erfolg beim Testen. :)
  6. scnugg

    IKEv2 13801

    Hat Dein Server-Computerzertifikat alle 3 Zwecke ? Siehe Bild ganz links sowie meine ausführliche Beschreibung auf Seite 2 dieses Themas. Dein Zertifikat auf Seite 1 (Themenbeginn) sieht nämlich etwas anders aus... Also bei mir hat die IKE-Verbindung jetzt über 4 Stunden geklappt, davon 2 Stunden mit mit der Einstellung "EAP" am client und 2 Stunden mit der Einstellung "Computerzertifikate verwenden" (siehe Bild ganz rechts). Der VPN-server 2012 ist in Hyper-V virtualisiert, der Windows 10 VPN-client physisch. Anbei die gewünschten Screenshots, einige Angaben aus Datenschutzgründen geändert.
  7. scnugg

    IKEv2 13801

    Also soll ich mal testweise jetzt meinen VPN-server neustarten, dann IKEv2 verbinden und schauen, wie lange die VPN-Verbindung hält? Wie wäre es, wenn Du Deinen server virtualisierst und dann z.B. vom Hyper-V Hoster aus eine VPN-Verbindung zum virtuellen server aufbaust? Damit könntest Du prüfen, ob das Problem beim Router vorliegt. Ich selber konnte auf diese Weise Probleme mit den VPN-Verbindungen ganz gut analysieren.
  8. scnugg

    IKEv2 13801

    Hi, ja, aber L2TP und IKE haben für die Konfiguration viel Gemeinsamkeit und deswegen wollte ich das Ganze mal komplett zusammenfassen. Vielleicht möchten ja auch einige user beide Methoden mal ausprobieren. Hier einige Vorschläge: Hast Du denn schon mal für VPN-Verbindung und serverzertifikat statt des DynDNS-Hosts direkt die öffentliche IP-Adresse eingetragen und es damit probiert? Ich würde auch mal bei der Zertifikatregistrierung den Host nicht nur als CN, sondern zusätzlich auch als Alternative Antragstellername/DNS-Name eintragen. Sind alle 3 Eigenschaften Serverauth/Clientauth und "IP-Sicherheits IKE, dazwischenliegend" in Deinem Computerzertifikat? Ich werde jetzt mal meine IKE-Verbindung 1 Stunde halten und dann schauen, ob sie ebenfalls einbricht....
  9. scnugg

    IKEv2 13801

    Hallo, wenn ich die Antwort-Postings hier in diesem Board so lese, muss ich mich regelmäßig darüber wundern, wie einige Experten entweder nur kurz und knapp antworten und/oder sich so mißverständlich ausdrücken, dass der Themenstarter immer wieder rückfragen muss und/oder das Thema ansich und die Kompetenz des Threadstarters in Frage stellen. Ist es denn wirklich so schwer, sich in die Lage des Fragenden hineinzuversetzen und ihn/sie zumindest ernstzunehmen? Aber bitte nicht mißverstehen, es ist nur als Verbesserungsvorschlag nett gemeint :) Aber zurück zum Thema: Ich habe mich mal intensiv mit dem Thema VPN-server 2012 über L2TP und IKEv2 beschäftigt und inzwischen funktionieren alle möglichen VPN-Verbindungen vom client (Windows 10) aus. Hier eine Checkliste für Leute, die damit Probleme haben. 1.) Habt ihr am Zielsystem eine Fritzbox als Router? Dann prüfen, ob in der Fritzbox bereits VPN-Verbindungen erstellt sind. Diese müssen unbedingt GELÖSCHT werden. Ein einfaches Deaktivieren (Haken rausnehmen) reicht nicht. Ansonsten will nämlich die Fritzbox die ipsec-Verschlüsselung übernehmen und es kommen keine L2TP/IKEv2-Verbindungen zustande. 2.) Den Regkey Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent] "AssumeUDPEncapsulationContextOnSendRule"=dword:00000002 am VPN client importieren. 3.) Im Router des VPN-Zielsystems die Ports 500 UDP, 4500 UDP, 1701 UDP+TCP und 443 TCP für SSTP an die lokale IP des VPN server weiterleiten. 4.) Sind die beiden Dienste IKE- und AuthIP IPsec-Schlüsselerstellungsmodule (IKEEXT) IPsec-Richtlinien-Agent (Policyagent) gestartet? 5.) Hat der AD-user, mit dem man sich anmeldet, im Register "einwählen" das Recht "Zugriff gestatten" ? 6.) Für das Serverzertifikat: Als Zertifikatvorlage "Computer" nehmen. Im Register "Erweiterungen" => Anwendungsrichtlinien aber noch "IP-Sicherheits IKE, dazwischenliegend" hinzufügen. Im Reiter "Sicherheit" das Recht zum "Registrieren"/"Automatisch Registrieren" erteilen (sonst erscheint bei der Zertifikatregistierung nicht die duplizierte Computer-Zertifikatvorlage) und bei "Antragstellername" die Option "Informationen werden in der Anforderung angegeben" erteilen. Dann über Zertifikate=>Lokaler Computer=>Eigene Zertifikate das Zertifikat anfordern. Als CN den DynDNS-Host oder die feste IP nehmen. Ich habe den Hostnamen zusätzlich noch als "Alternativen Antragstellernamen"=>DNS-Namen eingetragen, weil ich glaube, dass das bei der L2TP-Verbindung mit Zertifikat hilfreich war. Nach der Zertifikatregistrierung dann das Serverzertifkat im IIS an Port 443 binden und im Routing und RAS unter Eigenschaften/Sicherheit/SSL-Bindung auswählen. Für L2TP mit Zertifikat ist es zusätzlich nötig, ein Clientzertifikat auszustellen und am VPN-client unter Lokaler Computer=>Eigene Zertifikate zu importieren, für SSTP ist das nicht nötig. Natürlich muss (wie auch bei SSTP) zusätzlich noch das Zertifikat der Zertifizierungsstelle (CA) am client unter "Vertrauenswürdige Stammzertifizierungsstellen" importiert werden. 7.) Für L2TP mit Zertifikat muss im Routing und RAS unter Eigenschaften/Sicherheit das Feld "Benutzerdefinierte IPsec Richtlinie für LTP/IKE-Verbindungen" leer bleiben, also kein Passwort eingetragen sein. Das finde ich zwar eigentlich unlogisch, denn warum soll es nicht möglich sein, L2TP sowohl mit Schlüssel als auch mit Zertifikat zu nutzen? Aber es ist leider so... Kommt bei der Verbindung der Fehler "Verarbeitungsfehler bei der ersten Sicherheitsaushandlung", dann am client in der VPN-Verbindung unter Eigenschaften/erweiterte Eigenschaften das Feld "Die Namen- und Verwendungsattribute des Serverzertifikats überprüfen" deaktivieren, also den Haken rausnehmen. Alternativ statt einer DynDNS-Adresse direkt die öffentliche IP-Adresse als VPN-Ziel in der VPN-Verbindung am client eintragen, das Serverzertifikat dann auf die öffentliche IP-Adresse als CN ausstellen und am server registrieren. Wie gesagt muss auch für den Client ein Zertifikat erstellen und dort unter Lokaler Computer=>Eigene Zertifikate importieren. SSTP erfordert kein Clientzertifikat. Der Vorteil von SSTP gegenüber L2TP mit ipsec ist der schnelle File-Datentransfer (es wird fast der gesamte Upload ausgenutzt), alternativ könnte man natürlich auch FTP mit TLS nutzen, z.B. mit Filezilla server+client. Bei den IPSEC/IKE-Verbindungen ist der Filedatentransfer dagegen durchweg stark schwankend und gering, egal, ob diese Verbindungen direkt über ein Fritzbox-Profil oder aber über den VPN-server aufgebaut werden. NIcht benötigte oder doppelte, zuvor testweise von der CA ausgestellte Zertifikate aus dem Zertifikatspeicher "Lokaler Computer/Eigene Zertifikate" löschen. Kommt die VPN-Verbindung zustande, jedoch ist ein Anpingen oder RDP nicht möglich, dann den server neu starten. So, nun hoffe ich, dass meine Informationen einigen usern bei der Herstellung von VPN-Verbindungen zu einem Routing und RAS-Server helfen können, damit es schneller geht als bei mir (3 Tage Arbeit...) Hope this helps.. :)
×
×
  • Neu erstellen...