Looks like it's mostly DNS-based. Meh. But still, this underscores the importance of operating your own VPN if you want to maintain comms through the silly twitches of a gov't like this. The biggest VPN providers are the first to be targeted. Even just having an SSH host outside the country will do fine.
On another note, I recently set up a Tor bridge with pluggable transports to help those in choked areas. It was a fun homelab challenge, and a good way to spread my privilege of having a free connection.
A VPS with a simple SSH server on a nonstandard port, maybe with some port knocking if you think you might be scanned or targeted by accessing from the offending country will do the trick just fine, keeping things reaaaally low profile.
>simple SSH server on a nonstandard port, maybe with some port knocking if you think you might be scanned or targeted by accessing from the offending country will do the trick just fine, keeping things reaaaally low profile.
Sounds like security theater. Using port knocking isn't going to hide the fact there's a SSH connection between you and some server. If anything, having a non standard configuration (non standard port number or port knocking) makes you more suspicious.
I think you overestimate the desire, motivation and technical capability of sri lankan ISPs to start doing netflow analysis and DPI on individual subscribers' end user connections.
Unless you were to attract the attention of somebody in government, and they forced an ISP to escalate an issue to the 3rd or 4th tier of network engineering running the core of the bigger ASes there, they're not going to be doing that. It's not the chinese GFW.
Not only this, but there's a massive difference between stopping people from accessing the web via VPNs and stopping people from SSH'ing into their servers. You block SSH access and you're probably going to take a financial toll Country wide.
Assuming that nobody in Sri Lanka is implementing DPI on ISPs' edge interfaces, the safer solution would be to run your own vpn endpoint hosted in the USA or Europe, as openvpn in tcp mode, or wireguard, on port 443. Without pwning your client device, they're technically incapable of properly MITMing TLS1.2 and can't break the internet so thoroughly by blocking https/port 443 traffic (which would also break gmail, all other popular webmail, and a huge chunk of everything else with hugely popular public websites where port 80 is redirected to 443 for TLS end-to-end).
So unless somebody cares to inspect your traffic flow in particular and notices that it's openvpn traffic on 443 and not normal TLS1.2 traffic, it's likely to work.
I have a feeling theyve done some form of traffic analysis. My default open vpn setup on a digital ocean box with the port changed to 443 is blocked somehow with both major ISPs here.
Tried tcp too. Weirdly it refused to work. Haven't been able to fully check for configuration errors on my end here but i can't think of anything I did wrong either :)
It's also very much possible that the entire digitalocean /22, /20 or even /18 sized chunk of ipv4 space it's in has just been null routed, due to the documented presence of other VPN endpoints in it.
ssh over https, using proxytunnel works really good too. Looks like regular https traffic. And in addition to forwarding individual ports, openssh also has full vpn capability using tun/tap devices.
From what I can see, it's only for setting up a VPN provider, nothing else like Tor etc. (that may attract unwanted attention). It supports IKEv2 which isn't blocked by a lot of firewalls and supports far more VPS providers than Streisand.
I have my vpn served via port 443 on a server that also runs a website on that same port. But I think there's better ways to make it hard for attackers to block me.
It's actually infuriating this ban. I'm from SL, currently on Nord VPN which hasn't been blocked by 1 of the major ISPs. Both major ISPs are aggressively blocking standard open vpn traffic however. I'm not entirely sure how since this is not my knowledge domain but a default open vpn setup on digital ocean (even on port 443) results in a timeout when contacting the server
I don't understand why one ISP is still allowing Nord and express vpn through. If anyone is open to debug this and help create a work around I'd love help. Feels like a good time to test things.
In the meantime people are using dubious vpn providers and are opening themselves up as easy targets. I dread what would happen if a malicious party created a vpn with malicious intent and then spent some bucks on targeted advertising in SL on the app stores.
This block is such a shit move really. It's become the gov's default crisis time response in the name of national security.
OpenVPN, like many other VPN protocols, does not have censorship resistance as part of its design goals. So, I'm guessing that its traffic patterns are quite easy to detect.
You should have better luck with something like Shadowsocks, or even better, Shadowsocks over a SSH tunnel. There are probably better and more potent alternatives that I'm not familiar with. If you just want to do regular web browsing, a simple thing to try is to just use "ssh -D" for a SOCKS5 proxy and configure your browser to use the proxy.
Also, a possible first step in debugging is to run the same server setup in the same country as the client and see whether it allows you to connect to a domestic server. If it doesn't, it's probably a problem with your client/server setup as the state's firewall probably doesn't need to block domestic VPN connections.
In China, most of the solution would be cut down after days/weeks/months. Although the connection was encrypted, GFW would still try to guess if the connection behaviors match some VPN features according to some algorithms, then cut it down.
Currently, I'm using Algo[0] setting up VPN and use Wireguard[1] connect to it, both of them are working perfectly than other solutions I have used.
Thanks. I'll be taking a look at tunelling soon. The material around it is difficult to read and put together to be honest.
I'm right now using Nord via their ovpn files. Somehow it made its way through one ISP ruleset.
For my digital ocean box, I asked someone else to use tunnelblick with the ovpn file I provided them to see if it worked (they were in another country) and it worked. This makes me believe it's most likely a country level issue.
In general though I'd like to learn about networking more thoroughly and set up a censorship resistant option which I can help others to setup and share as well later on. Any primers/pointers are appreciated too. I'll start with all the things you mentioned though.
I suggest looking into WireGuard [1]. I found it easier to use than OpenVPN, and I think it will displace it as the de facto standard when it eventually gets merged into the Linux kernel. You'll have to use lower-level configuration tools to get started with it, which I am finding helpful to pursue the same goal of learning about networking more thoroughly.
While like Wireguard a lot, it won't displace Openvpn completely, for the simple reason that it only works over UDP, and cannot work over TCP, unlike Openvpn.
Transforming generic layer 3 datagrams into traffic that looks like something else is the general domain of obfuscation. Making WireGuard traffic look like TCP is one form of such obfuscation. Making it look like TLS or DNS or HTTP are other forms. (Actually putting layer 3 traffic into framing inside a legit TCP stream is inefficient and the wrong way to think about the problem domain.) No promises, but I'm expecting some nice things to come in this domain of generic obfuscation mechanisms to punch through various forms of filtering.
Inefficient as it may be, it is something I simply need for my use case - connecting home from a certain network which only allows outgoing connections on a handful of TCP ports.
No. You need your traffic to look like TCP, for your particular network filtering. But you do not need to achieve that by using the naive and inefficient approach of, "stick the packets into a TCP stream prefixed by a length field." Rather, there are more clever tricks for making your traffic look like TCP, which generally fall into the same realm as other obfuscation mechanisms.
ssh -D1234 remotehost gives you a local SOCKS proxy at port 1234 that goes through remotehost.
Other than that, do investigate DNS on HTTPS and DNS on TLS. I recommend setting up something like dnscrypt-proxy to serve as the DNS resolver for your LAN.
The sad fact is that oppressive governments don't really care. A few geeks who can pierce the firewall are no threat, the government just needs to choke the internet enough to prevent the general public from organising.
Fortunately for people who care about the health of the internet, I doubt that the Sri Lankan government has the technical acumen or sufficient budget to operate anything similar to the Chinese GFW's DPI abilities.
Speaking of shadowsocks, I really feel sorry for the author.. I believe his final words were "I hope one day I'll live in a country where I have freedom to write any code I like without fearing"
In the second incident listed above, social media was used both as a vector to spread hate speech and misinformation, and also to help mobs organize.
Regarding the current social media block: at the start, I felt this to be reasonable, as it made sense to slow the spread of misinformation/hate speech for a couple of days, until people's emotions cool down. However, the blocks still continue - and I see no clear justification for continuing them for so long.
I'm guessing this is just an attempt to make the social media blocks more effective. And I suppose the purpose of blocking social media is to suppress public discussion and criticism, which is intended to prevent social unrest like protesting, riots or a sudden change in government? I'm not too sure; it's hard to understand from within a society where it's considered a fundamental right to criticise the government.
Sometimes people just don't like each other, due to prejudice, differences in religion, some old beef between clans / ethnic groups / regional groups. This may have no relation to the government being oppressive or liberal.
Shutting down communication channels rarely helps defuse such situations, though. It leads to more isolation, more rumors, more enmity.
Legitimately curious response: have you tried thinking through the answer to this question, and if so, what seems like the likely answer in your view? If not, why not?
So I'm not sure what question you're asking if someone has put thought into, but assuming it was "What do they hope to achieve by this?"
shakes Magic 8 ball
My guess is it's a combination of what the Sri Lankan poster above mentioned combined with a reaction to further technical escalation by the citizenry.
Unfortunately, there are too many unknowns w.r.t. Sri Lanka's government/cultural values for me to even hazard a guess as to what the endgame is beyond minimizing net driven attempts to organize.
What I do see potentially transpiring, however, is someone figuring out how to host basic net based communication within the country; odds are though, the government feel themselves sufficiently equipped to take down in country rabble rousing, and possibly aim to keep outside influences from inflaming things further.
Best thing you can do if you want to get out, is find the IP addresses for your particular of site, and use that. DNS based blocking does squat if you're maintaining your own registry of IP->Domain Name bindings. If they catch on and start trying to IP block, well, welcome back to the pre/early internet days. Hopefully you know someone willing to host you a forwarding proxy.
I believe there's a lot of potential for CDNs and major sites to offer anti-censorship pass through traffic with HTTP/2 via CONNECT. By having a multiplexed protocol with multiple streams that spans "normal" traffic and tunneled traffic, it should be harder to identify. This would allow major sites or CDN providers to provide service to those people behind such bans and possibly require governments to break a significant portion of the web in order to institute those blocks. I think it's valuable to increase the damage done by government blocking so we can ensure that mainstream persons are sufficiently upset by this conduct. I also think CloudFlare and other major CDN providers should be the ones to provide this type of VPN access either as a product or as a special case offering for people in countries who censor the web.
I realize there are many businesses who wouldn't damage their primary offerings to provide such a secondary service. But it only takes one or two companies to increase the collateral damage of the bans, and thus make them much more costly for the governments imposing them.
Cloudflare also built and opensourced a rust implementation of wireguard which will likely back the service [0], but unfortunately, they didn't collaborate with upstream.
Yeah, I'm specifically pointing to the idea of leveraging HTTP/2's multiplexed streams to embed VPNs into the same connection as normal web traffic from CDNs. Things like 1.1.1.1 Warp don't attempt to hide the fact that they're a VPN and thus wouldn't really help with what I'm talking about.
Blocks like this are why I always recommend friends overseas to not use a VPN for which they've ever seen an advertisement. The small guys offer performance that's just as good and the big guys having ten times the number of servers doesn't help when their whole list can be blocked in an instant.
On another note, I recently set up a Tor bridge with pluggable transports to help those in choked areas. It was a fun homelab challenge, and a good way to spread my privilege of having a free connection.