VPN geblokkeerd d.m.v. DPI in Uganda?

[CB32]

Hallo,

ik woon zo'n 5 jaar in Uganda. Ik heb eerder een topic geopend over de belasting op Social Media en het blokkeren van VPNs: Facebook / Whatsapp / Twitter Belasting. Ik betaal die belasting netjes, maar tot mijn verbazing lijken mijn "private" VPNs nu ook geblokkeerd te zijn! Ik vraag mij af hoe deze geblokkeerd worden. Korte achtergrond:

VPN op VPS servers
Ik heb 3 VPNs tot mijn beschikbaar, elk opgezet op een VPS.

• Amsterdam (vpsserver.nl) - gebruik ik om remote in te loggen op machines op het kantoor organisatie. Heeft ongeveer een maand lang constant verbinding gehad.
• Amsterdam (virmach.com, spotgoedkoop) - voor de leuk. Bijna nooit gebruikt.
• Seattle (virmach.com, spotgoedkoop) - voor de leuk. Bijna nooit gebruikt.

Al deze VPNs draaien op een alternatieve poort en dus niet op de standaard 1194. Toegegeven, ze zijn simpel opgezet met een verder standaardconfiguratie via Nyr's OpenVPN-Install script. Was wel zo makkelijk.

Nu wil het zo dat plots op alle devices, naar alle drie de servers geen VPN verkeer mogelijk meer is. Tot nu toe had ik binnen enkele seconden een verbinding. Mijn diagnostische tests tot dus toe:

Poort check op alle drie de servers

code:

# nmap -sU -p 3555 MYHOST
PORT     STATE         SERVICE
3555/udp open|filtered razor

De poort staat dus wel open.

Foutmelding op server(s)
Op alle servers (en vergelijkbaar op de clients) zie ik de volgende foutmelding verschijnen in de log:

code:

# service openvpn@server status
● [e-mail] - OpenVPN connection to server
   Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-08-20 11:37:12 EDT; 10min ago

(PUBLIC IP) TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Het verzoek komt dus wel binnen op de VPS via mijn "publieke" IP (achter NAT, want 3G), maar de handshake wil niet. Volgens deze OpenVPN FAQ lijkt het op een Firewall Issue.

Wat ik geprobeerd heb

• VPS herstarten
• Certificaten opnieuw genereren
• VPN op willekeurige andere poorten
• Verbinden vanaf twee aparte WAN verbindingen (beide 3G en waarschijnlijk wel zelfde mast, zelfde ISP)

Wat ik nog wil proberen

• Iemand in laten loggen op mijn VPN vanuit een land anders dan Uganda.
• Opheldering vragen bij ISP, maar ervaring leer lage klantenservice en verschuilen achter "wij moeten".

Mijn stelling / vraag
Daar het lijkt dat op willekeurige poorten en willekeurige servers (althans, de twee "voor de leuk servers zijn zo weinig gebruikt dat ik die wel als willekeurig wil bestempelen") VPN niet tot stand kan komen, lijkt het er op dat er DPI gebruikt wordt. Kan dit kloppen, of hebben ze een andere manier, of ben ik te paranoia?

Edit: Zie ook mijn reactie ergens beneden, test met blanco servers, config connect wel vanuit Amsterdam maar niet vanuit Uganda

Deel twee, hoe kom ik hier om heen? Note: ik heb nog niet echt aan mijn onderzoeksplicht voldaan om deze vraag hier te mogen stellen . Heb al wel vluchtig geprobeerd via SSH te tunnelen maar zonder succes, dat kan ook aan mij liggen. laat deze vraag even achterwege, dit is een andere discussie. Centrale vraag: is dit DPI of zie ik iets anders over het hoofd?


Bedankt!

Groeten uit Uganda.

[ Voor 3% gewijzigd door CB32 op 20-08-2018 22:02 ]

[MrMonkE]

Ik heb het ook gehad, vanuit NL naar ander land.
Nooit op weten te lossen dus ik ga deze thread even volgen
Succes!


Zelf verdacht ik mijn OS het meest.

Grussen aus Holland!!

[Brahiewahiewa]

CB32 schreef op maandag 20 augustus 2018 @ 17:56:
... Note: ik heb nog niet echt aan mijn onderzoeksplicht voldaan om deze vraag hier te mogen stellen ...

Waar komt die claim van DPI vandaan? Ik zie daar niets over terug in je TS

[Thralas]

CB32 schreef op maandag 20 augustus 2018 @ 17:56:

• Iemand in laten loggen op mijn VPN vanuit een land anders dan Uganda.

Je hebt 3 VPS'en. Die 'iemand' kun je zelf gewoon zijn. Vervang dan wel de 'client' optie in de config door 'tls-client' en voeg 'route-nopull' toe zodat je je routes niet om zeep helpt.

TCP ook geprobeerd? Dat is sowieso wat makkelijk te debuggen.

Gezien je nog kunt SSH'en kun je je VPN over SSH tunnelen. Of met stunnel over TLS. Of installeer Wireguard. Opties genoeg.

[CB32]

Brahiewahiewa schreef op maandag 20 augustus 2018 @ 18:17:
[...]

Waar komt die claim van DPI vandaan? Ik zie daar niets over terug in je TS

@Brahiewahiewa: Mijn redenering:

1. Regering wil belasting op Social Media.
2. Bevolking zegt "Prima, wij gebruiken wel een VPN"
3. ISP zegt "Prima, gaan wij alle VPNs blokkeren, desnoods 1 voor 1"
4. Ik gebruik een host en een poort waarvan niet bekend is bij de ISP dat deze gebruikt word voor een VPN service
5. Deze lijkt geblokkeerd.
6. Mijn conclusie: mijn ISP blokkeert mijn VPN zonder via de host/poort te weten dat het om VPN gaat, dus lijkt het er op dat ze dat op een andere manier weten. DPI?

Thralas schreef op maandag 20 augustus 2018 @ 18:51:
Je hebt 3 VPS'en. Die 'iemand' kun je zelf gewoon zijn. Vervang dan wel de 'client' optie in de config door 'tls-client' en voeg 'route-nopull' toe zodat je je routes niet om zeep helpt.

@Thralas zo slim was ik nog niet. Woeps. Zojuist geprobeerd vanaf de Seattle VPS naar de Amsterdam.

Via SSH van de Seattle server een client van de Amsterdam Server gemaakt (met aangepaste opties zoals aangegeven) ingeladen, krijg opnieuw TLS Handshake error. Nu ben ik zeker geen expert en kan er ergens een fout in mijn opstelling zitten, maar ik heb alle drie de servers niet aangeraakt in de afgelopen weken.

code:

# openvpn --config MYFILE
Mon Aug 20 15:02:14 2018 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mon Aug 20 15:02:14 2018 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mon Aug 20 15:02:14 2018 Socket Buffers: R=[133120->133120] S=[133120->133120]
Mon Aug 20 15:02:14 2018 TUN/TAP device tun0 opened
Mon Aug 20 15:02:14 2018 TUN/TAP TX queue length set to 100
Mon Aug 20 15:02:14 2018 UDPv4 link local: [undef]
Mon Aug 20 15:02:14 2018 UDPv4 link remote: [AF_INET]AMSTERDAM_IP:3556
Mon Aug 20 15:03:14 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Aug 20 15:03:14 2018 TLS Error: TLS handshake failed
Mon Aug 20 15:03:14 2018 SIGUSR1[soft,tls-error] received, process restarting

Wellicht zie ik iets over het hoofd. Ik zal de Seattle VPS een fresh install geven, is mijn expirmenteer bakkie dus is niet erg.

Gezien je nog kunt SSH'en kun je je VPN over SSH tunnelen. Of met stunnel over TLS. Of installeer Wireguard. Opties genoeg.

Ik zie inderdaad ook veel mogelijkheden, vandaar dat ik schreef dat ik deze vraag nog niet mag stellen want ik heb nog geen onderzoek gedaan of daadwerkelijk proberen.

[laurens0619]

Je zou OpenVPN via SSL kunnen verbergen (DPI kan het nog zien) of nog een stapje verder via Stunnel

Dit is een zeer interessant artikel als je meer wilt leren hoe bv in china ze vpn blokkeren (en omzeilen;)) http://blog.zorinaq.com/m...-great-firewall-of-china/

[ Voor 47% gewijzigd door laurens0619 op 20-08-2018 21:36 ]

[Thralas]

laurens0619 schreef op maandag 20 augustus 2018 @ 21:34:
Je zou OpenVPN via SSL kunnen verbergen (DPI kan het nog zien)

DPI ziet niets meer als je het in TLS wrapt.

Dat artikel slaat nergens op, zoals ook bovenaan staat - de auteur dacht dat je door het delen (port-share) van een poort met een HTTPS service je OpenVPN ook magisch onzichtbaar was.

Zo werkt dat natuurlijk niet. Het deelt alleen de poort, meer niet.

[CB32]

laurens0619 schreef op maandag 20 augustus 2018 @ 21:34:
Je zou OpenVPN via SSL kunnen verbergen (DPI kan het nog zien) of nog een stapje verder via Stunnel

@laurens0619 Ik ben de IT-afdeling van de hele NGO .

Ik heb zojuist het volgende uitgevoetd:

• SeattleVPS: clean install (Ubuntu 16.04). OpenVPN er op (poort 443), één client file gegenereerd.
• AmsterdamVPS: clean install (Ubuntu 16.04), OpenVPN er op en clientfile ingeladen. Maakt verbinding met SetalleVPS en authenticatie gaat goed.
• Laptop in Uganda (Ubuntu 18.04): Zelfde client file (zonder route-nopull). TLS Handhsake error.

Mijn hoofdvraag op dit moment blijft dus, doet mijn ISP hier aan DPI?

[ThinkPad]

Voor China lees je wel veel over 'Shadowsocks'. Is meer een soort proxy dan VPN, maar schijnt wel goed te werken.

Tijdens het opzoeken van meer informatie kwam ik deze handleiding tegen. Ziet er wel aardig technisch uit overigens

[True]

offtopic:
Ik zie dat je Nyr gebruikt, dat deed ik eerder ook tot ik deze vond: https://github.com/Angristan/OpenVPN-install voor je volgende installatie zou ik Angristan gebruiken wegens de security perspectieven van de default instellingen van OpenVPN.

[CB32]

@True Mijn vrouw doet net haar nachtlampje uit terwijl ik naast haar op bed zit met mijn laptop, ik neem het maar als een hint, maar ik zal dat ook proberen. En dan ook nog via TCP in plaats van UDP.

Ook vin ik nu https://openvpn.net/index...tatic-key-mini-howto.html. Beveiliding is dus wel minder. Mijn probleem zou zijn, als men DPI gebruikt, weet ik niet of ik bijvoorbeeld mijn Synology NAS zo makkelijk via een SSH Tunnel o.i.d. kan laten VPNen. Ik zou natuurlijk wel kunnen VPNen naar de RaspberryPI, en van daar weer naar de NAS, maar ik was erg blij met de simpele setup tot nu toe.

[Kabouterplop01]

Als je VPN opzet kun je dan eens tcpdumpen (verbose mode alleen om te kijken waarom) aan de andere kant, waar je je vpn naar toe opzet en op de kant waar je je client mee opzet?

[CB32]

Ik heb inmiddels een VPN connectie tot stand weten te brengen via een SSH Tunnel (TCP). Tunnel word gemaakt, krijg IP toegewezen maar kan geen data ontvangen. Het zou kunnen zijn dat mijn verbinding te slecht is om dit via 3G te laten verlopen (aangezien het nu over TCP gaat en niet over UDP, ik lees dat dat niet handig is voor VPN).

Ik heb contact opgenomen met mijn ISP:

Ik:
Dear ISP,

I have been using a private, non-commercial VPN connection to manage different systems. As of late I am not able to use this, or any other VPN connection. I have payed OTT tax on all devices but still cannot connect any commercial or private VPN. According to me these services should be unblocked once OTT Tax is payed. Please clarify to me why I am still not able to connect through any VPN.

ISP:
Hello Christian, sorry about this experience. Please note that you are not supposed to use VPN connections. Since you paid OTT tax, share with us the phone number in your device so we can make checks and advise.

Wordt vervolgd.

[Yucon]

De primaire zorg is dus belastingontduiking. VPN's hebben ook nog tig andere doelen, waaronder legitieme. Heeft men ook een visie hoe je in die situaties zou moeten werken?

[CB32]

VPN over SSH tunnel is inmiddels gelukt, was vergeten tls-client toe te voegen aan de client config. Heb de server + client nu als TCP geconfigureerd. Opnieuw proberen direct te verbinden:

@Kabouterplop01 TCP Dump:

TCPDump vanaf Client

code:

16:56:39.181564 IP christian-ubuntu.60734 > SERVER_IP.3556: Flags [S], seq 583448297, win 29200, options [mss 1460,sackOK,TS val 389841721 ecr 0,nop,wscale 7], length 0
16:56:39.458842 IP SERVER_IP.3556 > christian-ubuntu.60734: Flags [S.], seq 3911856871, ack 583448298, win 28960, options [mss 1400,nop,wscale 6,nop,nop,sackOK,nop,nop,TS val 14191390 ecr 389841721], length 0
16:56:39.458892 IP christian-ubuntu.60734 > SERVER_IP.3556: Flags [.], ack 1, win 229, options [nop,nop,TS val 389841999 ecr 14191390], length 0
16:56:40.181989 IP christian-ubuntu.60734 > SERVER_IP.3556: Flags [P.], seq 1:89, ack 1, win 229, options [nop,nop,TS val 389842722 ecr 14191390], length 88
16:56:40.418766 IP SERVER_IP.3556 > christian-ubuntu.60734: Flags [.], ack 89, win 453, options [nop,nop,TS val 14191392 ecr 389842722], length 0
16:56:40.418792 IP SERVER_IP.3556 > christian-ubuntu.60734: Flags [R.], seq 1, ack 89, win 453, length 0
16:56:45.419689 IP christian-ubuntu.60736 > SERVER_IP.3556: Flags [S], seq 2870423003, win 29200, options [mss 1460,sackOK,TS val 389847959 ecr 0,nop,wscale 7], length 0
16:56:45.646864 IP SERVER_IP.3556 > christian-ubuntu.60736: Flags [S.], seq 4053785532, ack 2870423004, win 28960, options [mss 1400,nop,wscale 6,nop,nop,sackOK,nop,nop,TS val 14192938 ecr 389847959], length 0
16:56:45.646912 IP christian-ubuntu.60736 > SERVER_IP.3556: Flags [.], ack 1, win 229, options [nop,nop,TS val 389848187 ecr 14192938], length 0
16:56:46.420122 IP christian-ubuntu.60736 > SERVER_IP.3556: Flags [P.], seq 1:89, ack 1, win 229, options [nop,nop,TS val 389848960 ecr 14192938], length 88
16:56:46.648860 IP SERVER_IP.3556 > christian-ubuntu.60736: Flags [R.], seq 1, ack 89, win 453, length 0
16:56:46.648898 IP SERVER_IP.3556 > christian-ubuntu.60736: Flags [.], ack 89, win 453, options [nop,nop,TS val 14192940 ecr 389848960], length 0
16:56:46.648935 IP christian-ubuntu.60736 > SERVER_IP.3556: Flags [R], seq 2870423092, win 0, length 0
16:56:51.649774 IP christian-ubuntu.60738 > SERVER_IP.3556: Flags [S], seq 1199944526, win 29200, options [mss 1460,sackOK,TS val 389854189 ecr 0,nop,wscale 7], length 0
16:56:51.888983 IP SERVER_IP.3556 > christian-ubuntu.60738: Flags [S.], seq 3859452684, ack 1199944527, win 28960, options [mss 1400,nop,wscale 6,nop,nop,sackOK,nop,nop,TS val 14194495 ecr 389854189], length 0
16:56:51.889025 IP christian-ubuntu.60738 > SERVER_IP.3556: Flags [.], ack 1, win 229, options [nop,nop,TS val 389854428 ecr 14194495], length 0
16:56:52.650215 IP christian-ubuntu.60738 > SERVER_IP.3556: Flags [P.], seq 1:89, ack 1, win 229, options [nop,nop,TS val 389855190 ecr 14194495], length 88
16:56:52.889039 IP SERVER_IP.3556 > christian-ubuntu.60738: Flags [R.], seq 1, ack 89, win 453, length 0
16:56:52.889078 IP SERVER_IP.3556 > christian-ubuntu.60738: Flags [.], ack 89, win 453, options [nop,nop,TS val 14194497 ecr 389855190], length 0
16:56:52.889110 IP christian-ubuntu.60738 > SERVER_IP.3556: Flags [R], seq 1199944615, win 0, length 0

TCPDump vanaf Server

code:

16:56:19.407258 IP SERVER_IP.3555 > h1127.n1.ips.mtn.co.ug.21216: Flags [P.], seq 3475082094:3475082138, ack 3419513957, win 623, options [nop,nop,TS val 14186378 ecr 389821693], length 44
16:56:19.407306 IP SERVER_IP.3555 > h1127.n1.ips.mtn.co.ug.21216: Flags [P.], seq 44:152, ack 1, win 623, options [nop,nop,TS val 14186378 ecr 389821693], length 108
16:56:19.407371 IP SERVER_IP.3555 > h1127.n1.ips.mtn.co.ug.21216: Flags [P.], seq 152:188, ack 1, win 623, options [nop,nop,TS val 14186378 ecr 389821693], length 36
16:56:19.637284 IP h1127.n1.ips.mtn.co.ug.21216 > SERVER_IP.3555: Flags [.], ack 0, win 1444, options [nop,nop,TS val 389821939 ecr 14186376], length 0
16:56:19.647221 IP h1127.n1.ips.mtn.co.ug.21216 > SERVER_IP.3555: Flags [.], ack 44, win 1444, options [nop,nop,TS val 389821952 ecr 14186378], length 0
16:56:19.656778 IP h1127.n1.ips.mtn.co.ug.21216 > SERVER_IP.3555: Flags [.], ack 152, win 1444, options [nop,nop,TS val 389821954 ecr 14186378], length 0
16:56:19.666706 IP h1127.n1.ips.mtn.co.ug.21216 > SERVER_IP.3555: Flags [.], ack 188, win 1444, options [nop,nop,TS val 389821954 ecr 14186378], length 0
16:56:39.458205 IP h1127.n1.ips.mtn.co.ug.4308 > SERVER_IP.3556: Flags [S], seq 583448297, win 29200, options [mss 1400,nop,wscale 7,nop,nop,sackOK,nop,nop,TS val 389841721 ecr 0], length 0
16:56:39.458246 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4308: Flags [S.], seq 3911856871, ack 583448298, win 28960, options [mss 1460,sackOK,TS val 14191390 ecr 389841721,nop,wscale 6], length 0
16:56:39.648681 IP h1127.n1.ips.mtn.co.ug.4308 > SERVER_IP.3556: Flags [.], ack 1, win 228, options [nop,nop,TS val 389841721 ecr 14191390], length 0
16:56:40.418330 IP h1127.n1.ips.mtn.co.ug.4308 > SERVER_IP.3556: Flags [P.], seq 1:89, ack 1, win 229, options [nop,nop,TS val 389841723 ecr 14191390], length 88
16:56:40.418366 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4308: Flags [.], ack 89, win 453, options [nop,nop,TS val 14191631 ecr 389841723], length 0
16:56:40.418482 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4308: Flags [P.], seq 1:101, ack 89, win 453, options [nop,nop,TS val 14191631 ecr 389841723], length 100
16:56:40.607369 IP h1127.n1.ips.mtn.co.ug.4308 > SERVER_IP.3556: Flags [R], seq 583448386, win 0, length 0
16:56:45.648681 IP h1127.n1.ips.mtn.co.ug.4511 > SERVER_IP.3556: Flags [S], seq 2870423003, win 29200, options [mss 1400,nop,wscale 7,nop,nop,sackOK,nop,nop,TS val 389847959 ecr 0], length 0
16:56:45.648724 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4511: Flags [S.], seq 4053785532, ack 2870423004, win 28960, options [mss 1460,sackOK,TS val 14192938 ecr 389847959,nop,wscale 6], length 0
16:56:45.840001 IP h1127.n1.ips.mtn.co.ug.4511 > SERVER_IP.3556: Flags [.], ack 1, win 228, options [nop,nop,TS val 389847960 ecr 14192938], length 0
16:56:46.647900 IP h1127.n1.ips.mtn.co.ug.4511 > SERVER_IP.3556: Flags [P.], seq 1:89, ack 1, win 229, options [nop,nop,TS val 389847961 ecr 14192938], length 88
16:56:46.647937 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4511: Flags [.], ack 89, win 453, options [nop,nop,TS val 14193188 ecr 389847961], length 0
16:56:46.648059 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4511: Flags [P.], seq 1:101, ack 89, win 453, options [nop,nop,TS val 14193188 ecr 389847961], length 100
16:56:46.838266 IP h1127.n1.ips.mtn.co.ug.4511 > SERVER_IP.3556: Flags [R], seq 2870423092, win 0, length 0

OpenVPN Log Client

code:

16:56:39 Unrecognized option or missing or extra parameter(s) in test.ovpn:15: block-outside-dns (2.4.4)
16:56:39 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10
16:56:39 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
16:56:39 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
16:56:39 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
16:56:39 TCP/UDP: Preserving recently used remote address: [AF_INET]SERVER_IP:3556
16:56:39 Socket Buffers: R=[87380->87380] S=[16384->16384]
16:56:39 Attempting to establish TCP connection with [AF_INET]SERVER_IP:3556 [nonblock]
16:56:40 TCP connection established with [AF_INET]SERVER_IP:3556
16:56:40 TCP_CLIENT link local: (not bound)
16:56:40 TCP_CLIENT link remote: [AF_INET]SERVER_IP:3556
16:56:40 Connection reset, restarting [-1]
16:56:40 SIGUSR1[soft,connection-reset] received, process restarting
16:56:40 Restart pause, 5 second(s)
16:56:45 TCP/UDP: Preserving recently used remote address: [AF_INET]SERVER_IP:3556
16:56:45 Socket Buffers: R=[87380->87380] S=[16384->16384]
16:56:45 Attempting to establish TCP connection with [AF_INET]SERVER_IP:3556 [nonblock]
16:56:46 TCP connection established with [AF_INET]SERVER_IP:3556
16:56:46 TCP_CLIENT link local: (not bound)
16:56:46 TCP_CLIENT link remote: [AF_INET]SERVER_IP:3556
16:56:46 Connection reset, restarting [-1]

Wat ik zie terugkomen met mijn lekenogen:

• Verbinding komt tot stand
• Pakketjes gaan verloren (server regel 14, dan herhaald op 21, op de client regel 6, dan herhaald op 11)
• Client blijft opnieuw proberen (vandaar herhaling vanaf server 14 / client 11, niet gepost)

---

Ook nog antwoord van ISP:

Ik:
Why am I not supposed to use VPN services as I have payed OTT Tax? These services are widly used to ensure safe connections between different machines. I have already payed the tax and am not trying to circumvent anything. I simply need to connect to some devices remotely.

The phone number is ###

ISP:
Checks from our side shows all is okay. Kindly restart the device in use and test usage. Number has been re-provisioned.[/b]

Beetje de standaardreactie van de ISP, "we hebben alles gereset, doet u dat ook even?". Geen verschil. Ook leuk dat ze gaan van "je mag geen VPN gebruiken" naar "moet nu werken!"

@Yucon Tja, dat weet ik, dat weet jij, maar ik vermoed dat de regering een andere agenda heeft. Daarbij komt dat ik een consumenten lijn gebruik, wellicht is het anders voor business lijnen, maar die zijn moeilijk te krijgen en duur.

---

Als ik via een SSH Tunnel wel een VPN verbinding kan opzetten, en zonder niet, kan ik er dan van uit gaan dat ergens onderweg mijn 'blote' VPN geblokkeerd word?

[Thralas]

In principe wel.

Maar je tcpdumps bewijzen het onomstotelijk:

De eerste reply van de server met payload wordt blijkbaar gefingerprint:

code:

16:56:40.418482 IP SERVER_IP.3556 > h1127.n1.ips.mtn.co.ug.4308: Flags [P.], seq 1:101, ack 89, win 453, options [nop,nop,TS val 14191631 ecr 389841723], length 100

Die wordt gedropped, en vervolgens gaat er een RST naar beide kanten:

code:

16:56:40.418792 IP SERVER_IP.3556 > christian-ubuntu.60734: Flags [R.], seq 1, ack 89, win 453, length 0
16:56:40.607369 IP h1127.n1.ips.mtn.co.ug.4308 > SERVER_IP.3556: Flags [R], seq 583448386, win 0, length 0

En er gebeurt iets raars met de TCP timestamps - of ik snap TCP timestamps niet, maar dat lijkt me sowieso vooral bijzaak.

[ Voor 9% gewijzigd door Thralas op 22-08-2018 19:01 ]

[CB32]

Bedankt allen voor het meedenken en de antwoorden.

Ik ga er verder niet achter aan. Ik zou het kunnen aangeven bij de UCC (Uganda Comminucation Comission) en hen laten oordelen; maar het is het niet waard. Het doel van mijn VPN was (vooral) simpel even "inbellen" op de apparatuur op kantoor als ik in het buitenlan o.i.d. ben. Ik krijg dat doel vast nog wel werkend, maar met zo veel bruggetjes dat ik er ook zelf ter plaatse moet zijn mocht het een keer hangen... dus nee.

Sommige dingen in dit land moet je maar tegen jezelf zeggen: "Zucht. Zo is het nu eenmaal.".

Ik heb in ieder geval veel geleerd over SSH tunnels. Ik kan nu vanuit de hele wereld de RaspberryPI naast mijn nachtkastje bereiken. Nu nog een functie om het ook daadwerkelijk nuttig te maken anders dan "omdat het kan".

[Kabouterplop01]

Thralas schreef op woensdag 22 augustus 2018 @ 18:56:

En er gebeurt iets raars met de TCP timestamps - of ik snap TCP timestamps niet, maar dat lijkt me sowieso vooral bijzaak.

daar zitten soms raar lange responses tussen.

@TS,
Wat voor een soort verbinding is dat?

[Anoniem: 718429]

Afgaande op de post van Thralas: Dit soort RST-injectie is precies waarmee comcast de hele netneutraliteit-discussie liet losbarsten. En het is ongeveer de stomste en meest achterbakse manier van traffic management die je kan verzinnen. Je kan dus wel stellen dat "de internetgemeenschap" dit soort onzin niet tolereert.

Dus gooi er eigenlijk maar wel een berichtje naar de regulator tegenaan, ook al ga je ervanuit dat er niets van komt.

[Napsju]

Heb je het al eens met een andere mobiele aanbieder getest? Er is zo te zien genoeg keuze.

[CB32]

@Kabouterplop01 De verbinding is een 3G verbinding. Via een PPP-modem aan mijn mooie ASUS-RT[iets] router en dan over Wifi.

@Anoniem: 718429 Vergeet niet de UCC deel is van dezelfde overheid waarvan ik vermoed dat ze een dubbele agenda hebben met dit hele gedoe. Zal eens met onze baas praten om te kijken of dat dingen omver gaat halen die ik liever niet omver wil halen als buitenlander met een werkvergunning dat in december verloopt.

@Napsju Het aanbod is op papier groot. De lijst uit je link mist zelfs nog wel wat aanbieders en netwerken, Vodafone, MTN en ook Smile hebben inmiddels een 4G aanbod.
Wij zitten echter op een locatie vrij dicht bij een studentenstad, maar net zo ver buiten de stad, in de heuvels, met te weinig (interessante) klanten dat er eigenlijk maar één netwerk het echt doe op 2G en 3G: MTN. Andere netwerken zijn zelfs matig op 2G en 3G is er eigenlijk niet.

[-Tim-]

ThinkPadd schreef op maandag 20 augustus 2018 @ 21:50:
Voor China lees je wel veel over 'Shadowsocks'. Is meer een soort proxy dan VPN, maar schijnt wel goed te werken.

Tijdens het opzoeken van meer informatie kwam ik deze handleiding tegen. Ziet er wel aardig technisch uit overigens

Hier in China is dit inderdaad de way to go. Het kan wat ingewikkeld lijken om zelf op te zetten, maar het moet te doen zijn als je al weet hoe je een VPS moet draaien.
Een trouwens makkelijkere en nette implementatie van Shadowsocks kan je doen met Outline. Ze geven je een script dat Docker installeert met Shadowsocks en alles er op en er aan (zoals een autoupdater van de software). Uiteindelijk kan je met de Outline client en app verbinden, of met native Shadowsocks software.

[Anoniem: 718429]

Okee, dan laat je wellicht iemand die geen last heeft van "oeps niet verlengde" werkvergunningen het bericht sturen, of die maakt er eerst een storm van "op de social", ofzo.

En, hm, is het wellicht een idee om zelf een straalverbinding (bv. 2,4 of 5 GHz) op te zetten naar een punt dichterbij die studentenstad waar je betere dekking hebt of zelfs toegang tot een (glas)draadje? Moet je mischien ergens een paar vierkante meter grond kopen en een paal neerzetten waarop je dan een tussenstation op een zonnepaneel optuigt. Geen idee of dat stand houdt, maar het is mischien te proberen.

[CB32]

Anoniem: 718429 schreef op dinsdag 28 augustus 2018 @ 10:14:
Okee, dan laat je wellicht iemand die geen last heeft van "oeps niet verlengde" werkvergunningen het bericht sturen, of die maakt er eerst een storm van "op de social", ofzo.

En, hm, is het wellicht een idee om zelf een straalverbinding (bv. 2,4 of 5 GHz) op te zetten naar een punt dichterbij die studentenstad waar je betere dekking hebt of zelfs toegang tot een (glas)draadje? Moet je mischien ergens een paar vierkante meter grond kopen en een paal neerzetten waarop je dan een tussenstation op een zonnepaneel optuigt. Geen idee of dat stand houdt, maar het is mischien te proberen.

We hebben een offerte gekregen voor een directe straalverbinding, 2mpbs gegarandeerd, voor €300/maand. Daar zou nog apparatuur bij komen om deze verbinding over de compound te delen.

En dan vraag ik me af, wil ik 2mbps dat "altijd werkt" gaan verdelen over de compound (met eigenlijk maar 10 gebruikers), met alle kosten onderhoud vandien, of neem ik genoegen met een paar losse verbindingen die af en toe wel, af en toe niet, werken voor €30 per maand en soms wel een snelheid van 3mpbs?

[Ludwig005]

@CB32 2mbps garantie vind ik zelf behoorlijk traag zeker voor 300 euro per maand zijn er hoeveel kosten snellere verbindingen?

[Kabouterplop01]

CB32 schreef op dinsdag 28 augustus 2018 @ 07:51:
@Kabouterplop01 De verbinding is een 3G verbinding. Via een PPP-modem aan mijn mooie ASUS-RT[iets] router en dan over Wifi.

Ik vond die MTU van 1500 al interessant nl.!

[CB32]

Ludwig005 schreef op dinsdag 28 augustus 2018 @ 19:10:
@CB32 2mbps garantie vind ik zelf behoorlijk traag zeker voor 300 euro per maand zijn er hoeveel kosten snellere verbindingen?

Duur is het inderdaad. Wij zitten, qua internet gezien, toch vrij afgelegen. Uganda heeft de vaste verbindingen een beetje gemist. We konden meer snelheid bijkopen maar die prijzen wil ik al helemaal niet weten. En hier is het motto vaak nieuwe klanten zijn goud waard, als je eenmaal klant bent kun je stikken.

In Kampala ligt er wel glas en koper her en der. Er loopt ook glasvezel zo'n 1200m voorbij onze hoofdpoort, maar die bedient geen consumenten / bedrijven zover ik weet (loopt naar een sattelietstation), en ook dat zal wel heel duur zijn met alle apparatuur van dien.

[Anoniem: 718429]

Gegarandeerde SLAs zijn duur, zeker op plekken waar die garanties nakomen lastig is. Maar er zijn wel meer mogelijkheden dan dat of braaf de consument spelen.

Heb je al uitgezocht van wie die kabel-op-1200-meter is, van waar naar waar hij loopt, wat voor kabel dat is, en als het bijvoorbeeld een tegenwoordig vrij gangbare buis-met-losse-glasvezels is, of er mischien een glasvezeltje bijin te blazen is? Dan zal je daar waar je glasvezel uitkomt interconnect moeten regelen en bandbreedte moeten inkopen. En voor 300 euro in de maand over je afschrijvingsperiode kan je vrij veel apparatuur zelf regelen. Routertje, switch, paar SFPs zijn de kosten niet, tenminste als je handig inkoopt. Je moet alleen wel weten wat je doet.