Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Netwerk snelheid zakt 33% na het opbouwen van een VPN tunnel

Pagina: 1
Acties:

Vraag


  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Beste tweakers, ik heb een vraagje.

Een paar weken geleden heb ik voor de grap eens Windows Server 2012r2 op een pricewatch: Intel Desktop Board D945GCLF2 geinstalleerd met pricewatch: OCZ Vertex Turbo 120GB tezamen met 2GB ram (is weinig maar voldoende volgens mij) om eens wat uit te proberen. Maar al snel liep ik tegen een probleem aan waar ik na een paar weken rondzoeken zelf niet uit ben gekomen omdat Google me allemaal onzin aanbied.
Of mijn zoektermen zijn verkeerd of het is iets anders. Vandaar dat ik jullie hulp inroep.

Op dit systeem heb ik de ADDS, DNS, DHCP, WINS, en RAS roles geïnstalleerd. Er zijn geen users op de admin na natuurlijk want dit is een test environment. Ook weet ik niet of het aan de beperkte rekenkracht ligt. Echter geven de metingen me nogal tegenstrijdige resultaten.

Het probleem is dat de maximaal haalbare snelheid inzakt nadat er een VPN tunnel is opgezet. Als ik de atom server net heb opgestart en ik doe met iperf een test dan zijn dit de resultaten:


code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
c:\tools\iperf>iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.237.2.1, port 53215
[  5] local 10.237.1.1 port 5201 connected to 10.237.2.1 port 53216
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  96.5 MBytes   809 Mbits/sec
[  5]   1.00-2.00   sec  99.8 MBytes   838 Mbits/sec
[  5]   2.00-3.00   sec   105 MBytes   881 Mbits/sec
[  5]   3.00-4.00   sec   103 MBytes   861 Mbits/sec
[  5]   4.00-5.00   sec   110 MBytes   920 Mbits/sec
[  5]   5.00-6.00   sec   111 MBytes   930 Mbits/sec
[  5]   6.00-7.00   sec   110 MBytes   921 Mbits/sec
[  5]   7.00-8.00   sec   109 MBytes   912 Mbits/sec
[  5]   8.00-9.00   sec   109 MBytes   913 Mbits/sec
[  5]   9.00-10.00  sec   109 MBytes   913 Mbits/sec
[  5]  10.00-10.03  sec  2.89 MBytes   850 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.03  sec  1.04 GBytes   890 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------


Dus na een verse start haal ik hier ongeveer 900Mbit. Als ik dag 1, 2 en 3 na deze verse start een test uitvoer haal ik soortgelijke resultaten.

Nu komt het rare. Als ik een vpn tunnel opbouw naar deze server en ik heb het getest via meerdere externe verbindingen. Dan haal ik de maximaal haalbare snelheden vanuit de andere locatie. Echter als ik dan weer lokaal test via het zelfde systeem waarmee eerder is gemeten. Dan haal ik zichtbaar mindere snelheden. Zie de onderstaande log:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>cd c:/tools/iperf
c:\tools\iperf>iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.237.2.1, port 52771
[  5] local 10.237.2.200 port 5201 connected to 10.237.2.1 port 52772
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  72.9 MBytes   612 Mbits/sec
[  5]   1.00-2.00   sec  76.8 MBytes   644 Mbits/sec
[  5]   2.00-3.00   sec  77.4 MBytes   647 Mbits/sec
[  5]   3.00-4.00   sec  79.0 MBytes   663 Mbits/sec
[  5]   4.00-5.01   sec  79.3 MBytes   664 Mbits/sec
[  5]   5.01-6.00   sec  79.4 MBytes   668 Mbits/sec
[  5]   6.00-7.00   sec  81.6 MBytes   684 Mbits/sec
[  5]   7.00-8.00   sec  81.1 MBytes   680 Mbits/sec
[  5]   8.00-9.00   sec  81.5 MBytes   686 Mbits/sec
[  5]   9.00-10.00  sec  81.2 MBytes   681 Mbits/sec
[  5]  10.00-10.03  sec  1.85 MBytes   567 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.03  sec   792 MBytes   663 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------


Dus ik haal na een verse start ongeveer 900mbit. Ook na dag 1 tot 3, waarschijnlijk verder ook maar dat is niet getest. Als ik na dag 1, 2 of 3 een tunnel opzet van een willekeurig andere locatie en daar test dan haal ik de maximaal haalbare snelheden die de externe verbinding mogelijk maakt.

Als ik nadat er een VPN is opgebouwd naar deze server, lokaal weer een test doe, dan haal ik, zeg 66% van de "voordat er een tunnel is geweest" snelheid.
  • Nadat er een VPN is opgezet, dus de tunnel heeft bestaan en is nu verbroken. Dan halen we 600mbit.
  • Voordat er een VPN tunnel is aangemaakt halen we 900mbit.
Hoe kan het zijn dat dit verschil optreed?

[ Voor 12% gewijzigd door Core2016 op 30-03-2018 13:31 . Reden: Duidelijker verklaren van situatie. ]

Beste antwoord (via Core2016 op 27-03-2018 17:37)


  • colinator
  • Registratie: Maart 2010
  • Laatst online: 11:56
Ik krijg een beetje het gevoel dat dit een DNS issue is.

Zodra je VPN actief word, zal je server zijn VPN address (10.237.2.200) bij de DNS server aanmelden voor de FQDN van je server. Dit zal ook bekend zijn bij alle clients die dezelfde server ook gebruiken voor DNS.

Ik denk overigens dat de VPN interface altijd actief is op je server maar voor jou pas zichtbaar word zodra de VPN actief is geweest OF dat de interface pas actief word in Windows bij de eerste client die verbind met VPN maar daarna (ondanks de VPN clients disconnected zijn) nog steeds zijn interface actief houd waardoor het IP ook beschikbaar blijft.

Gezien je intern altijd naar de 1.1 zou moeten gaan (lijkt me?) kan je in de interface instellingen van de VPN adapter (10.237.2.200) het vinkje "Register this connections address in DNS" uitzetten - Dan zal de interface zich niet meer aanmelden en zou je domain naam altijd naar de 1.1 blijven verwijzen.

Als je VPN disconnect, blijft de DNS record gewoon bestaan die naar de .200 verwijst, waardoor je client ook naar de .200 zijn traffic stuurt. Omdat zowel de 1.1 als de 2.200 intern in het LAN netwerk zitten, is het niet gek dat je ze dus kan benaderen ook al staat VPN weer uit.

[ Voor 12% gewijzigd door colinator op 27-03-2018 13:31 ]

Alle reacties


  • GoldenBatt
  • Registratie: Januari 2006
  • Laatst online: 10:45
Wat doet je processor op het moment dat je test? VPN kan nogal CPU intensief zijn. Als de processor aan de server of client kant maximaal loopt te stressen in het logisch dat je geen hogere snelheden haalt :)

Specs!


  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Nee dat begrijp ik. Echter treed deze vertraging op nadat deze tunnel is verbroken. Nadat komt hij niet meer boven de 650mbit uit. Tijdens load kan ik dit begrijpen, het is maar een oude atom. Maar daarna is raar imho. Hier een screen tijdens de local test.

Afbeeldingslocatie: https://static.afbeeldinguploaden.nl/1803/385544/flIgpcSw.png

[ Voor 13% gewijzigd door Core2016 op 27-03-2018 01:29 ]


  • GoldenBatt
  • Registratie: Januari 2006
  • Laatst online: 10:45
Aah, ik begreep uit je text niet helemaal dat je snelheid "laag" bleef als je de VPN weer verbrak. Daar heb ik zo geen oplossing op

Specs!


  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Nadat de tunnel is verbroken blijft de snelheid laag.

[ Voor 134% gewijzigd door Core2016 op 27-03-2018 11:02 ]


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

... een vpn-verbinding ...
wat voor vpn-verbinding? RRAS?
En als die vpn-verbinding is in- en uitgeschakeld, wat zijn dan de verschillen?
(behalve de downloadsnelheid). Draaien er extra services? Worden er interfaces toegevoegd? Of routes?

QnJhaGlld2FoaWV3YQ==


  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Het gaat hier over de Windows VPN service.
  • Het betreft een schone installatie met de volgende roles: ADDS, DNS, DHCP, WINS en RRAS
  • Remote Acces Service is geïnstalleerd en ingesteld met custom configuration -> VPN only.
  • De ports in RRAS zijn allemaal gelimit van 128 naar 16
  • IPv6 is disabled
  • IPv4 static range ingesteld: 10.237.2.200 tot 10.237.2.254
Als ik voordat een tunnel is opgebouwd, na een verse start, lokaal iperf draai van client op 10.237.2.1 naar server op 10.237.1.1 (Beide zitten op de zelfde switch) dan haal ik 900/900.

Als ik extern een tunnel naar deze server opzet krijgt die externe client een ip uit de static scope in RRAS.

Als ik terwijl de VPN tunnel actief is naar de server op 10.237.1.1, vanuit de lokale client op 10.237.2.1 iperf uitvoer naar de server halen we nog steeds die 900/900.

Als ik nu de vpn connectie verbreek en lokaal weer iperf uitvoer vanuit de zelfde client op 10.237.2.1
Haalt deze client 600mbit en niet meer de 900mbit.

Er gaat een lampje branden nu door je opmerking over services en routes.

Het valt me nu op dat iperf na het verbreken van de vpn tunnel in de log laat zien dat er connect word naar 10.237.2.200 ipv 10.237.2.1
Zie deze screenshot.

Afbeeldingslocatie: https://static.afbeeldinguploaden.nl/1803/385597/BsXGDSYp.png

En op de serverlog lijkt de verbinding niet te gaan naar local 10.237.1.1 maar naar local 10.237.2.200
Zie deze screenshot.

Afbeeldingslocatie: https://static.afbeeldinguploaden.nl/1803/385570/KZkzJhM8.png

De test voer ik uit vanuit de client op 10.237.2.1. Ik connect trouwens niet met een ip maar met een FQDN die in de DNS server een a record heeft naar 10.237.1.1, ook is er een A record dat ook verwijst naar deze server maar dan naar 10.237.2.200. Dat heb ik nog niet vermeld, woeps.

De snelheden vergeet ik idd even want als ik nu iperf doe naar een ip (10.237.1.1) ipv de FQDN dan haal ik wel altijd die 900/900, met, zonder, op, onder, voor of na de vpn tunnel heeft bestaan. Het maakt niet uit. Dus het is geen probleem. Een deel is opgelost/verduidelijkt.

De vraag blijft wel staan maar is aangepast.
  • Waarom 900mbit over ip 10.237.1.1?
  • Waarom 600mbit over ip 10.237.2.200?



Het volgende is nu dus dat als ik ping met een FQDN ipv een ip dat hij het 10.237.2.200 ip gebruikt en niet 10.237.1.1. Dit gebeurt pas nadat er een vpn tunnel is opgezet.

Als ik de RRAS service restart en die zelfde ping uitvoer met de FQDN dan kom ik weer bij 10.237.1.1 uit.
Als ik een tunnel opzet en weer verbreek.
Om daarna weer die zelfde ping met de FQDN uit te voeren dan kom ik weer bij 10.237.2.200 uit.
  • Dus ping voor tunnel is 10.237.1.1
  • Ping tijdens tunnel is 10.237.1.1
  • Ping na tunnel is 10.237.2.200
In de DNS server zijn ook 2 host A's te vinden.
Een A met 10.237.2.200 en een A met 10.237.1.1 naar de servernaam.

Ik heb weet dat ik maar een A heb aangemaakt en dat is die 10.237.1.1 tijdens dcpromo en het configureren van de DNS server.

Die 10.237.2.200 is het start ip uit de static scope in RRAS, daar heb ik namelijk het volgende ingesteld:

Afbeeldingslocatie: https://static.afbeeldinguploaden.nl/1803/385604/uD5Xf5My.png

Komt dit door dat ik een static scope heb ingesteld in RRAS, dat hij daarom dat ip toevoegd?

Hoe ga ik het voor elkaar krijgen dat hij na het verbreken van de vpn tunnel lokaal de DNS server niet het 10.237.2.200 ip weg geeft maar 10.237.1.1 aanhoud? Het heeft lokaal toch geen nut om naar 200 te gaan?

Het rare is dus dat ik wel altijd de server aan kan via de FQDN ook al is er wel of geen tunnel. Ook voordat er een tunnel is geweest, of erna. Alleen point de FDQN na de tunnel naar 10.237.2.200 ipv 10.237.1.1.

Ik snap het beetje, bij beetje maar begrijp het niet helemaal.

[ Voor 64% gewijzigd door Core2016 op 29-03-2018 23:37 . Reden: Een hoop onduidelijkheid eruit ]


  • colinator
  • Registratie: Maart 2010
  • Laatst online: 11:56
Heb je al een traceroute gedaan om te kijken hoe je verkeer loopt? Zowel voor als, tijdens als na de VPN connectie. Het zou misschien kunnen dat je verkeer een andere route neemt nadat de VPN verbroken is.

  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Nee dat heb ik nog niet gedaan.

Tracert voor VPN verbinding:
code:
1
2
3
4
5
6
7
8
c:\tools\iperf>tracert ares.home.hendrikx

Tracing route to ares.home.hendrikx [10.237.1.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ARES [10.237.1.1]

Trace complete.


Tracert tijdens VPN verbinding
code:
1
2
3
4
5
6
7
8
9
C:\Users\rekordbox>tracert ares.home.hendrikx

Tracing route to ares.home.hendrikx [10.237.2.200]
over a maximum of 30 hops:

  1    <1 ms     *       <1 ms  ARES [10.237.1.1]
  2    <1 ms    <1 ms    <1 ms  ARES [10.237.2.200]

Trace complete.



Tracert na VPN verbinding
code:
1
2
3
4
5
6
7
8
9
c:\tools\iperf>tracert ares.home.hendrikx

Tracing route to ares.home.hendrikx [10.237.2.200]
over a maximum of 30 hops:

  1    <1 ms     *       <1 ms  ARES [10.237.1.1]
  2    <1 ms    <1 ms    <1 ms  ARES [10.237.2.200]

Trace complete.


Het ip 10.237.2.200 bestaat niet voordat er een VPN tunnel is aangemaakt.
Ik ga het eens proberen met zonder static range in RRAS. Kijken wat hij dan doet.

Het probleem is dat tijdens en na een tunnel het ip adres van de server veranderd van 10.237.1.1 naar 10.237.2.200 waar ik dus dit snelheids verlies heb opgemerkt. Anders was ik niet eens aan dit verhaal begonnen.

Misschien kom ik er heel laat mee maar.
Er zit trouwens maar een NIC in de server. Kan het hier mee te maken hebben? Nooit problemen mee gehad eigenlijk totdat ik op snelheid ben gaan testen waardoor ik in deze test situatie ben uitgekomen.

[ Voor 255% gewijzigd door Core2016 op 27-03-2018 10:51 ]


  • Predator
  • Registratie: Januari 2001
  • Laatst online: 14:06

Predator

Suffers from split brain

Jouw VPN tunnel wordt niet afgesloten, anders kan je nooit de laatste traceroute doen.

Everybody lies | BFD rocks ! | PC-specs


  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
In de RRAS console blijft deze verbinding die er niet meer is actief? Dit terwijl ik toch echt de VPN tunnel verbreek op de externe apparaten. Ik ben nu eens aan het refreshen gegaan. Het blijkt dat deze wel verbroken word maar dat duurt een minuut of 2 ongeveer.

Hier een log na 5 minuten wachten: Er is een VPN tunnel actief geweest, maar op dit moment al 5 minuten niet meer actief.
Afbeeldingslocatie: https://static.afbeeldinguploaden.nl/1803/385659/0vtOh3N5.png

Dit is de log
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
c:\tools\iperf>tracert ares.test.local

Tracing route to tracert ares.test.local [10.237.2.10]
over a maximum of 30 hops:

  1    <1 ms     *       <1 ms  ARES [10.237.1.1]
  2    <1 ms    <1 ms    <1 ms  ARES [10.237.2.10]

Trace complete.

c:\tools\iperf>iperf3 -c ares.test.local
Connecting to host ares.test.local, port 5201
[  4] local 10.237.2.11 port 57789 connected to 10.237.2.10 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  68.6 MBytes   574 Mbits/sec
[  4]   1.00-2.00   sec  68.4 MBytes   574 Mbits/sec
[  4]   2.00-3.00   sec  69.5 MBytes   584 Mbits/sec
[  4]   3.00-4.00   sec  72.5 MBytes   608 Mbits/sec
[  4]   4.00-5.00   sec  70.8 MBytes   594 Mbits/sec
[  4]   5.00-6.00   sec  71.5 MBytes   599 Mbits/sec
[  4]   6.00-7.00   sec  71.8 MBytes   602 Mbits/sec
[  4]   7.00-8.00   sec  71.4 MBytes   598 Mbits/sec
[  4]   8.00-9.00   sec  71.4 MBytes   599 Mbits/sec
[  4]   9.00-10.00  sec  70.8 MBytes   593 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   706 MBytes   593 Mbits/sec                  sender
[  4]   0.00-10.00  sec   706 MBytes   593 Mbits/sec                  receiver

iperf Done.

c:\tools\iperf>


Nu heb ik RRAS herstart en is dit de log:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
c:\tools\iperf>tracert ares.test.local

Tracing route to ares.test.local [10.237.1.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ARES [10.237.1.1]

Trace complete.

c:\tools\iperf>iperf3 -c ares.test.local
Connecting to host ares.test.local, port 5201
[  4] local 10.237.2.11 port 57847 connected to 10.237.1.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   102 MBytes   854 Mbits/sec
[  4]   1.00-2.00   sec  96.4 MBytes   809 Mbits/sec
[  4]   2.00-3.00   sec  94.8 MBytes   795 Mbits/sec
[  4]   3.00-4.00   sec   105 MBytes   880 Mbits/sec
[  4]   4.00-5.00   sec  98.2 MBytes   824 Mbits/sec
[  4]   5.00-6.00   sec   102 MBytes   853 Mbits/sec
[  4]   6.00-7.00   sec   100 MBytes   838 Mbits/sec
[  4]   7.00-8.00   sec  90.1 MBytes   756 Mbits/sec
[  4]   8.00-9.00   sec   103 MBytes   862 Mbits/sec
[  4]   9.00-10.00  sec  97.1 MBytes   815 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   988 MBytes   829 Mbits/sec                  sender
[  4]   0.00-10.00  sec   988 MBytes   829 Mbits/sec                  receiver

iperf Done.

c:\tools\iperf>

[ Voor 185% gewijzigd door Core2016 op 27-03-2018 11:24 ]


  • colinator
  • Registratie: Maart 2010
  • Laatst online: 11:56
Het 10.237.2.200 IP adres is van je VPN verbinding en het is logisch dat je die gebruikt zodra de tunnel actief is, dat wordt namelijk het eindpunt van je verbinding.

Als je nadat je de verbinding verbreekt nog steeds over dat IP gaat, is de tunnel toch ergens nog actief in de background.
Daarnaast is het logisch dat je snelheid omlaag gaat wanneer het verkeer over de VPN tunnel gaat, als die dan toch ergens nog actief is, is het logisch dat je snelheid hetzelfde blijft.

Misschien een rare vraag tussendoor maar zie ik het correct dat je nu een VPN verbinding opzet over je eigen LAN netwerk?

  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Nee, geen rare vraag hoor. De server heeft de gateway op 10.237.0.1 naar buiten. Verbind met een laptopje en mobiel over 4G.

Maar wat me inmiddels duidelijk is, is dat lokaal toch gewoon nadat en tijdens er connecties zijn de volledige snelheid benut moet kunnen worden? Scheelt dat VPN dan over alles zoveel snelheid? Dus ook lokaal als er geen connecties meer zijn?

En lokale clients in de 10.237.2.1-199 range dacht ik dat die altijd moeten verbinden met 10.237.1.1 en niet met 10.237.2.200? Wat hebben die daar mee van doen, dit zijn geen VPN clients. Of veranderd de hele situatie nadat er een tunnel is aangemaakt.

Voordat er connecties tot stand zijn gebracht blijft de server te vinden via 10.237.1.1
Hoe sluit ik de tunnel in de background dan? Want nogmaals, na een RASS restart werkt het "weer goed".

Nu na een half uur ongeveer blijft hij 10.237.2.200 geven. Ik ik snap hier echt niets van. Ik ga het eens anders uitproberen. Het zal hier binnenkort wel bij komen staan. Dank jullie!

[ Voor 103% gewijzigd door Core2016 op 27-03-2018 12:05 ]


Acties:
  • Beste antwoord

  • colinator
  • Registratie: Maart 2010
  • Laatst online: 11:56
Ik krijg een beetje het gevoel dat dit een DNS issue is.

Zodra je VPN actief word, zal je server zijn VPN address (10.237.2.200) bij de DNS server aanmelden voor de FQDN van je server. Dit zal ook bekend zijn bij alle clients die dezelfde server ook gebruiken voor DNS.

Ik denk overigens dat de VPN interface altijd actief is op je server maar voor jou pas zichtbaar word zodra de VPN actief is geweest OF dat de interface pas actief word in Windows bij de eerste client die verbind met VPN maar daarna (ondanks de VPN clients disconnected zijn) nog steeds zijn interface actief houd waardoor het IP ook beschikbaar blijft.

Gezien je intern altijd naar de 1.1 zou moeten gaan (lijkt me?) kan je in de interface instellingen van de VPN adapter (10.237.2.200) het vinkje "Register this connections address in DNS" uitzetten - Dan zal de interface zich niet meer aanmelden en zou je domain naam altijd naar de 1.1 blijven verwijzen.

Als je VPN disconnect, blijft de DNS record gewoon bestaan die naar de .200 verwijst, waardoor je client ook naar de .200 zijn traffic stuurt. Omdat zowel de 1.1 als de 2.200 intern in het LAN netwerk zitten, is het niet gek dat je ze dus kan benaderen ook al staat VPN weer uit.

[ Voor 12% gewijzigd door colinator op 27-03-2018 13:31 ]


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

colinator schreef op dinsdag 27 maart 2018 @ 13:26:
Ik krijg een beetje het gevoel dat dit een DNS issue is...
Precies. Als er een vpn-sessie gestart is, resolved je server ineens naar het vpn-adres van je server.
Probeer, nadat je de vpn hebt afgesloten,
iperf3 -c 10.237.1.1
en daarna
iperf3 -c 10.237.2.200

In het laatste geval gaan de pakketjes dus drie keer over de netwerkkaart van je server. Kennelijk haalt die 2 Gb/s. Per saldo hou je dan ca. 700 Mb/s over

QnJhaGlld2FoaWV3YQ==


  • Core2016
  • Registratie: Oktober 2017
  • Laatst online: 12-11-2021
Volgens mij gaan we de goede richting op. Hier die logs: (dank voor de cmd tag uit de quote :) ).
In de client zit een PCIe intel NIC en in de server een onboard Realtek PCIe NIC. Allebij Gbit

C:\Users\rekordbox>c:/tools/iperf/iperf3 -c 10.237.1.1
Connecting to host 10.237.1.1, port 5201
[  4] local 10.237.2.1 port 58992 connected to 10.237.1.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   102 MBytes   853 Mbits/sec
[  4]   1.00-2.00   sec   106 MBytes   893 Mbits/sec
[  4]   2.00-3.00   sec   107 MBytes   897 Mbits/sec
[  4]   3.00-4.00   sec   100 MBytes   840 Mbits/sec
[  4]   4.00-5.00   sec   101 MBytes   844 Mbits/sec
[  4]   5.00-6.00   sec   100 MBytes   844 Mbits/sec
[  4]   6.00-7.00   sec   104 MBytes   876 Mbits/sec
[  4]   7.00-8.00   sec  95.9 MBytes   805 Mbits/sec
[  4]   8.00-9.00   sec   102 MBytes   854 Mbits/sec
[  4]   9.00-10.00  sec   101 MBytes   849 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1020 MBytes   855 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1020 MBytes   855 Mbits/sec                  receiver

iperf Done.

en:
C:\Users\rekordbox>c:/tools/iperf/iperf3 -c 10.237.2.200
Connecting to host 10.237.2.200, port 5201
[  4] local 10.237.2.1 port 58994 connected to 10.237.2.200 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  69.1 MBytes   580 Mbits/sec
[  4]   1.00-2.00   sec  68.5 MBytes   575 Mbits/sec
[  4]   2.00-3.00   sec  69.0 MBytes   578 Mbits/sec
[  4]   3.00-4.00   sec  69.5 MBytes   583 Mbits/sec
[  4]   4.00-5.00   sec  69.5 MBytes   583 Mbits/sec
[  4]   5.00-6.00   sec  68.5 MBytes   575 Mbits/sec
[  4]   6.00-7.00   sec  70.4 MBytes   591 Mbits/sec
[  4]   7.00-8.00   sec  68.6 MBytes   576 Mbits/sec
[  4]   8.00-9.00   sec  69.5 MBytes   583 Mbits/sec
[  4]   9.00-10.00  sec  69.5 MBytes   583 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   692 MBytes   581 Mbits/sec                  sender
[  4]   0.00-10.00  sec   692 MBytes   580 Mbits/sec                  receiver

iperf Done.


Maar dit deed hij ook vanaf het begin al zo. Alleen voordat er een vpn tunnel was opgebouwd kon ik die iperf -c 10.237.2.200 niet uitvoeren omdat dat niet werd gevonden.

Het probleem is dus dat hij tijdens en na deze vpn tunnel met een fdqn: ares.test.local resolved naar 10.237.2.200 ipv 10.237.1.1. Lokale clients hoeven toch helemaal niets met die 2.200 te doen?

Dankzij jullie tips en wat rond zoeken op internet heb ik het volgende aangepast op de server.
  • Op de enige NIC op deze server, TCP/IP Properties -> Advanced -> DNS - > "Register this connections Address in DNS" afvinken.
  • In DNS console Ares aan tikken, Action -> Properties en bij interfaces -> "listen on only the following IP addresses" aangevinkt en daar 10.237.2.200 verwijderd.
  • Bij Zone properties -> Nameserver tab: Daar staan 2 maal de fqdn met 10.237.1.1 en 10.237.2.200. Die 200 heb ik verwijderd.
  • Daarna heb ik de 10.237.2.200 verwijderd uit de DNS server manager zelf onder forward lookup zones.
  • op de client "ipconfig /flushdns" en "ipconfig /registerdns"
En hij lijkt het nu goed te doen tijdens de tunnel. Want nu, zowel voor als tijdens tunnel vanaf 10.237.2.1 (lokale client):
C:\Users\rekordbox>c:/tools/iperf/iperf3 -c ares.test.local
Connecting to host ares.test.local, port 5201
[  4] local 10.237.2.1 port 59038 connected to 10.237.1.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  95.6 MBytes   802 Mbits/sec
[  4]   1.00-2.00   sec   107 MBytes   897 Mbits/sec
[  4]   2.00-3.00   sec  95.6 MBytes   802 Mbits/sec
[  4]   3.00-4.00   sec   107 MBytes   900 Mbits/sec
[  4]   4.00-5.00   sec  98.2 MBytes   825 Mbits/sec
[  4]   5.00-6.00   sec   106 MBytes   886 Mbits/sec
[  4]   6.00-7.00   sec  98.2 MBytes   826 Mbits/sec
[  4]   7.00-8.00   sec   101 MBytes   850 Mbits/sec
[  4]   8.00-9.00   sec   110 MBytes   924 Mbits/sec
[  4]   9.00-10.00  sec  99.6 MBytes   836 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1019 MBytes   855 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1019 MBytes   855 Mbits/sec                  receiver

iperf Done.


En na de tunnel via die zelfde client (ik heb hier een paar minuten gewacht todat de sessie ook uit RASS verdween):
C:\Users\rekordbox>c:/tools/iperf/iperf3 -c ares.test.local
Connecting to host ares.test.local, port 5201
[  4] local 10.237.2.1 port 59046 connected to 10.237.1.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  96.9 MBytes   812 Mbits/sec
[  4]   1.00-2.00   sec   104 MBytes   874 Mbits/sec
[  4]   2.00-3.00   sec  96.4 MBytes   808 Mbits/sec
[  4]   3.00-4.00   sec  98.9 MBytes   830 Mbits/sec
[  4]   4.00-5.00   sec   103 MBytes   861 Mbits/sec
[  4]   5.00-6.00   sec   103 MBytes   861 Mbits/sec
[  4]   6.00-7.00   sec   103 MBytes   864 Mbits/sec
[  4]   7.00-8.00   sec   100 MBytes   841 Mbits/sec
[  4]   8.00-9.00   sec   107 MBytes   902 Mbits/sec
[  4]   9.00-10.00  sec   101 MBytes   846 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1013 MBytes   850 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1013 MBytes   850 Mbits/sec                  receiver

iperf Done.


Als ik dan weer de
iperf3 -c 10.237.1.1
en
iperf3 -c 10.237.2.200
uitvoer dan zijn de resultaten gelijk als die 2 logs van boven aan deze post.

Als ik RASS restart (dus er is nu geen enkele vpn tunnel opgezet geweest) en weer die 2 iperf testen uitvoer dan geeft de
iperf3 -c 10.237.1.1
de zelfde resultaten als voorheen.

De
iperf3 -c 10.237.2.200
geeft een timeout. Want die bestaat niet. Na het verbinden van een vpn client dan bestaat het wel en kan ik lokaal weer 10.237.2.200 testen met bijhorende lagere snelheden.

Als ik dan ares.test.local iperf op de lokale client dan pikt hij het ip 10.237.1.1 op wat ook de bedoeling is.

Voor de zekerheid alles eens een reboot gegeven en het nog eens geprobeerd.
Resultaten zijn wederom het zelfde.

Dat hij de gbit niet volledig vol trekt ligt aan een goeiekope 25meter cat5e kabel omdat ik die server naast me heb staan. Als ik test met een metertje dan haalt hij wel 990 tot 1000mbit.

Het is opgelost lijkt. Dank jullie zeer allemaal! Ik heb weer een hoop bijgeleerd vind ik.
_/-\o_

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

Lees nog even https://blog.mikejmcguire...eive-you-dont-trust-them/
en pas de registry aan zoals beschreven

[ Voor 45% gewijzigd door Brahiewahiewa op 27-03-2018 18:35 ]

QnJhaGlld2FoaWV3YQ==

Pagina: 1