Твърдо убеждение на хора с тоталитарен и милиционерски манталитет е, че всеки, който ползва криптография или други средства за защита на комуникацията е вероятен престъпник. Дали обектът на вниманието им наистина укрива нещо или използва здравия си разум и оценява стойността на информацията си и риска от разкриването ѝ на трети страни е без значение за тях. Нуждата от лично и интимно пространство на интереси, знания или разговори е нещо, което притежаващите властта да наблюдават, не желаят да разберат. А аргументът, че правото на анонимност е гаранция за свобода на словото, за тях е по-несъмнено доказателство за вина от самопризнанието.

При ситуация, в която отношението като към престъпник и убеждението във вероятната вина се определят единствено от отказа на субекта да осигури възможност да бъде наблюдаван и контролиран, е подходяща идея да се планира не само въвеждането и използването на средства за защита на връзката, но и прикриването на тяхното използване. Изграждането на VPN тунели е надеждно средствo за защита на тайната на обменяната информация, но фактът на самото му присъствие може да послужи като основание за привличане на внимание и да предизвиква милиционерска намеса в частния живот.

Приемайки, че най-лошия вариант е да бъдете наблюдаван от позицията на вашия интернет доставчик, искам да предложа начини за прикриване съществуването на VPN и на времето на неговото използване.

1. Маскиране на тунела
Последните версии на OpenVPN поддържат възможност за маскиране на VPN сървъра като уеб сървър, използващ SSL. От гледна точка на наблюдаващия, вашата VPN връзка ще изглежда като нормална https сесия. Ако наблюдаващия опита да зареди адреса, с който сте се свързали, може да го посрещне някаква уеб страница, която е логично да бъде защитена със SSL. Съвместяването на две услуги на един порт функционира като VPN сървъра посреща заявката, проверява протокола и авторизацията и препраща към уеб-сървъра, ако зададените изисквания не бъдат изпълнени. Функционалността на OpenVPN се нарича споделяне на порт (port-share) и това е извадка от примерна конфигурация на сървъра:

# Режим на сървър, ползващ tcp
proto tcp-server
# Порт за VPN сървъра
port 443
# При неуспешна аутентикация препраща на:
port-share 127.0.0.1 4443

Възможността на OpenVPN работи отлично, като единствения проблем, който забелязах, че когато openvpn препраща към httpd подменя и IP адреса на потребителя със своя (т.е. 127.0.0.1 в примера). Не е сериозен проблем, но трябва съобразите привидните уеб приложения, които ще прикриват VPN-a.

2. Прикриване на активността
Въпреки че наблюдаващият не може да разбере какви данни се обменят във VPN тунела, наличието активност може да му даде информация кога потребителят е ползва тунела и какви приблизителни обеми данни обменя. Ако наблюдаващият знае кога потребителя е активен и къде се намира, то това може да му послужи, за да го атакува по време, когато има най-голям шанс да достъпи обменяните данни. Сещам се за два принципни подхода да се прикрие времето активността: създаване на постоянен, непроменяем в зависимост от активността трафик и създаване на постоянен случаен по обем трафик, който да прикрие пиковете, когато връзката се ползва.
2.1. Постоянен трафик
Идеята е да имаме постоянен трафик (примерно 1 Mbps) в тунела, който да се състои от шум и полезен трафик. Шумът е с по-нисък приоритет и когато се появи полезен трафик, шумът се „свива“, като остава общият трафик от 1 Mbps непроменен. Тъй като всичко извън компютъра ви се разглежда като потенциално враждебно, приоритизацията е най-подходящо да се осъществи с tc. Не се оправям с ползването на tc и когато разпитах за възможни решения Зак и Светла ми предложиха следния скрипт:

dev=“tun0″
# Root
tc qdisc del dev $dev root
tc qdisc add dev $dev root handle 1: htb default 5 r2q 1
#Common class
tc class add dev $dev parent 1:0 classid 1:10 htb rate 1mbit burst 128k
tc qdisc add dev $dev parent 1:10 handle 10: sfq perturb 10
# ICMP
tc class add dev $dev parent 1:10 classid 1:20 htb rate 768kbit ceil 1mbit burst 96k cburst 128k
tc qdisc add dev $dev parent 1:20 handle 20: sfq perturb 10
tc filter add dev $dev parent 1:0 protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:20
# All
tc class add dev $dev parent 1:10 classid 1:30 htb rate 256kbit ceil 1mbit burst 32k cburst 128k
tc qdisc add dev $dev parent 1:30 handle 30: sfq perturb 10
tc filter add dev $dev parent 1:0 protocol ip prio 51 u32 match ipdst 0.0.0.0/0 flowid 1:30

2.2. Случаен трафик
Постоянният трафик може да ви се струва като разхищение, да вярвате повече на случайността, да нямате възможност да осигурите постоянен канал или да имате някаква друга причина да не харесвате горното решение. Случайните пикове и спадове също могат да направят полезния трафик неотличим за външен наблюдател, като един от най-лесните начини да се създаде случаен шум е следния bash скрипт, който Васил предложи:

while /bin/true ; do num=$RANDOM; len=$RANDOM; ping -c $num -s $len remote & ; sleep 1; done

И в този и в горния случай предпочитам да използвам ICMP за създаване на шум в тунела, защото той може да бъде по-лесно моделиран и отделен от „нормалния“ трафик.

За това се сещам, но съм сигурен, че има други и по-добри начини да се направи. Ако имате корекции и допълнения – ще ги науча с интерес.