Ubuntu: traag internet bij VPN voor niet-VPN gebruikers

[Berrick]

Mijn vraag:

Recentelijk heb ik een VPN verbinding op mijn router ingesteld voor één enkele gebruiker (user: pia). Sindsdien is internet voor andere users op de server traag, bijvoorbeeld bij het draaien van speedtest-cli.

Gek genoeg krijg ik wel acceptabele resultaten als ik speedtest als pia run (sudo -u pia speedtest-cli). Overigens is het internet van clients op het LAN (achter de router) gewoon goed.

Alle suggesties zijn welkom

Relevante software en hardware die ik gebruik:
Ubuntu 16.04.3 LTS als server/router

Wat ik al gevonden of geprobeerd heb
Ik krijg het gevoel dat om de een of andere reden speedtest verkeer langs de VS oid gaat (ik gebruik PIA DNS servers). Latency die de speedtest geeft is 260ms terwijl de testserver op 3km afstand staat. Ook wanneer ik als gewone gebruiker google ping krijg ik:

64 bytes from yul02s05-in-f14.1e100.net (172.217.13.142): icmp_seq=1 ttl=53 time=116 ms

maar als user pia krijg ik

64 bytes from dh-in-f113.1e100.net (209.85.203.113): icmp_seq=1 ttl=48 time=32.2 ms

Wanneer ik echter 209.85.203.113 als een gewone user ping zie ik een latency van slecht 22 seconden, dus qua dns lookup gaat er al iets mis lijkt.

[Mijzelf]

Je kunt als beide users een nslookup doen om te zien welke DNS server ze gebruiken. Je kunt een traceroute doen om te zien welke route de ping pakketjes nemen. Je kunt

wget -4 http://icanhazip.com/ -q -O -

doen om te zien welk publieke IP adres ze gebruiken.

[Berrick]

Tnx. User pia krijgt zoals bedoeld een ander ip adres terwijl de regular user mijn Wan ip kijkt.

Nslookup Google.com geeft dezelfde DNS server (die van PIA) maar geeft dus een ander adres voor Google.com...

[ Voor 5% gewijzigd door Berrick op 09-12-2017 10:15 ]

[Thralas]

Berrick schreef op vrijdag 8 december 2017 @ 23:45:
Recentelijk heb ik een VPN verbinding op mijn router ingesteld voor één enkele gebruiker (user: pia). Sindsdien is internet voor andere users op de server traag, bijvoorbeeld bij het draaien van speedtest-cli.

Ja, maar in dat proces heeft PIA je DNS-servers vervangen voor StupidDNS.

$ dig @209.222.18.222 google.com

;; ANSWER SECTION:
google.com.		80	IN	A	172.217.13.142

Oplossing: gebruik een DNS-server van een partij die wel goed is met internet. Google bijvoorbeeld.

[CR2032]

Kijk eens of je een DNS-leak hebt of verkeer anders wordt omgeleid: https://ipleak.net

Heb je openresolv goed ingesteld met of zonder systemd?
https://wiki.archlinux.org/index.php/OpenVPN#DNS

[Blokker_1999]

doe eens een traceroute naar een gekende site met en zonder VPN en vergewis je er zo eerst van hoe het verkeer exact loopt.

[Berrick]

Dank voor de reacties.

Als ik de VPN uit zet (en DNS van mijn provider gebruik) blijft speedtest nog steeds even traag gek genoeg (ook voor de VPN gebruiker nu). de inefficiënte dns lookup is wel verdwenen, eveneens als ik wel VPN aan heb staan maar google's DNS servers gebruik ipv die van PIA. Dat is dus tenminste iets.

Als ik een grote file download (met wget) gaat hij wel gewoon snel (200+Mbps, maar na 5sec. te hebben moeten wachten op resolving) maar speedtest haalt nauwelijks 1 Mbps. Als VPN user haal ik ongeveer 90Mbps. Als ik een website curl duurt het als gewone gebruiker ongeveer 5 seconden voordat ik resultaat krijg terwijl dit met de VPN user instantaan is.

Misschien handig om te vermelden dat dit de guide is die ik (min of meer) heb gevolgd voor het op zetten van split tunnel VPN.

CR2032 schreef op zaterdag 9 december 2017 @ 11:35:
Kijk eens of je een DNS-leak hebt of verkeer anders wordt omgeleid: https://ipleak.net

Heb je openresolv goed ingesteld met of zonder systemd?
https://wiki.archlinux.org/index.php/OpenVPN#DNS

Het is een headless server, dus ik kan niet op een website dnsleak testen, maar in mijn /etc/resolv.conf staan alleen de ingestelde dns servers dus dit zou goed moeten zijn. Deze DNS servers definieer ik in /etc/openvpn/update-resolv-conf welke ik na wat andere script run wanneer de VPN up gaat.

Blokker_1999 schreef op zaterdag 9 december 2017 @ 12:00:
doe eens een traceroute naar een gekende site met en zonder VPN en vergewis je er zo eerst van hoe het verkeer exact loopt.

traceroute ziggo.nl geeft 8 hops zowel met als zonder vpn (regular user) en lijkt in Nederland te blijven.


Huidige status is dus dat curl en wget dus traag resolven als normale gebruiker (ping en nslookup niet), en speedtest erg traag is, terwijl dit alles als VPN gebruiker niet zo is.

Edit: Na nog wat verder zoeken merk ik dat als ik curl dwing ipv4 te gebruiken hij wel snel resolved. Door de regel

code:

options single-request-reopen

toe te voegen in mijn /etc/resolv.conf gaat wget en curl wel soepel. Speedtest is echter nog steeds traag als normale gebruiker (en bovendien weet ik niet hoe ik dit persistent moet maken).. Kan dat in mijn /etc/openvpn/update-resolv-conf script?

[ Voor 8% gewijzigd door Berrick op 12-12-2017 01:06 ]

[Hero of Time]

Informatie over speedtest-cli:

Note: This tool accesses speedtest.net over http, while the web-based client uses websockets. This tool has shown to become increasingly inacurate with high-speed connections. For more information, see the readme on:
https://github.com/sivel/speedtest-cli

Oftewel, het is niet ideaal om je snelheid te testen. Voor mij op werk gaat het wel redelijk goed, down 500 Mbps, up zo'n 320. De website versie doet echter down 675 en up 750. Dat wijkt dus redelijk af.

Voor je resolv.conf optie, hoe krijgt je server z'n DNS settings? Is dat handmatig of via DHCP van je router/modem? In geval van DHCP, dan kan je dat als extra optie mee laten geven in dhclient.conf om toe te voegen.

[Berrick]

Klopt, maar 1-10 Mbps down vs 400Mbps vind ik een iets te groot verschil. Zeker raar dat de VPN user een snellere verbinding heeft.

Resolved.conf krijgt zijn waarden initieel via DHCP en wordt vervolgens geüpdatet door /etc/openvpn/update-resolve-conf. Ik zal eens kijken of ik iets toe kan voegen in dhclient.conf. Het blijft echter een workaround. Ik snap niet hoe dit probleem is ontstaan. Ik begin het vermoeden te krijgen dat het niet direct iets met de VPN te maken heeft maar dat ik onbedoeld iets met ipv6 heb gedaan. Ik heb alleen geen idee wat

[CR2032]

Zet ipv6 eens helemaal uit, maakt dat verschil? Daar kun je soms heel vreemde issues door krijgen.