A pandemic is raging in the world, people are buying toilet paper and buckwheat on an industrial scale, and most IT companies are transferring employees to a remote location. So did my employer - a German parastatal office.Basically, there were no problems, but one of our employees a month ago, when everything looked still not so scary, I went on vacation to my relatives in Egypt and was safely stuck there because of the border closure. Well, she’s healthy herself, a working laptop with her - she’s quarantined herself and works through a VPN. A week works, two ... On the third week, the VPN stopped connecting. The support of the first line checked the commonplace, like a reboot - it did not help. The second line began to diagnose: the connection goes into perpetual timeout at the TLS Handshake stage. Disabled a local firewall - it did not help. We tried another car - it does not work. Another provider does not work. At this point, the support team gave up and joyfully shoved the problem onto me according to the good old principle of “the network manager is to blame.”We look in the server logs: he does not see any attempts to reach it after answering the initial packet. Funny and pretty familiar. I called an employee, I was interested in how they deal with human rights in general and freedom of the Internet in particular. He says that things are bad, the Internet is blocking them so that the camels hiccup, and Roskomnadzor nervously smokes on the sidelines. Yeah ... A quick googling shows a bunch of complaints about similar VPN problems in Egypt since 2017. To complete the picture, I ask if the employee has been in the homeland for more than 2 weeks in recent years - no, she says, has not been. The puzzle begins to take shape.We raise a copy of the corporate VPN server on a free white IP - there is no connection. Expected.We change the port - there is no connection. This is sadder.We change the protocol - there is no connection. The puzzle has developed - in front of us is DPI like a great Chinese firewall.The employee is sad, the boss plaintively asks, "You are a Russian hacker, do something." Well ... Uncover Darknet's heavy artillery and rotate obfsproxy.For a server (CentOS 7), it looks like this:~ sudo pip install virtualenv
~ cd /etc/openvpn && virtualenv venv && source venv/bin/activate
~ sudo pip install obfsproxy
~ sudo -u openvpn /etc/openvpn/venv/bin/python /etc/openvpn/venv/bin/obfsproxy obfs3 --dest=127.0.0.1:1194 server 1.2.3.4:49416
For a client (MacOS) like this:~ brew install pip
~ pip install pyopenssl obfsproxy
~ obfsproxy obfs3 socks 127.0.0.1:8443
In the OpenVPN config on the client, add:socks-proxy-retry
socks-proxy 127.0.0.1 8443
Profit OpenVPN in obfsproxy wrapper is not detected by local signature detection algorithms, the session takes off, pings go, the traffic runs, the employee is happy. It remains only to add the obfsproxy client part to autoload in this “obvious” way (I hate poppies). I say goodbye to our prisoner in relief and write a letter to support in the spirit of "this problem is solved like this, but I can’t guarantee stability, and you can only use this workaround if there’s no other way out."Apparently, in Egypt there is a place to be especially cunning DPI, which for the first time does not block communication to new subscribers and / or traffic to new hosts, referring those to the conditional category “tourists”. And after a certain timeout expires, the user is categorized as “their own” and joyfully cuts traffic to please local kings.