Eida.cz - Bezpečný cestovní routing a PACka na cibulky

Bezpečný cestovní routing a PACka na cibulky

Eida

Mít všude VPN je skoro jako sen. Sen z farmy. Dlouhou dobu nebyla na iOS možnost provozovat mezi mezi VPNkami mimo vestavěných běžných L2PT, PPTP a nějakých těch 3rd od Cisca taky OpenVPN, což se sice už dávno od dob iOS 5 změnilo, ale pořád nebyl čas se k tomu dostat a něco s tím konečně udělat. On teda formálně není čas kvůli přípravám ani teď, ale co už. Možnost použít telefon jako zabezpečenou bránu za to stojí.

V první řadě vznikaly nebetyčné potíže s nasazením především kvůli tomu, že pod iOS může být virtuálním adaptérem jenom zařízení tun a stávající server se všemi certifikáty a nastaveními už běžel na tap a změny a úpravy by zabraly vyloženě zbytečně moc času a úsilí. S postupnou restrukturalizací sítě a rozšířením o další VPN k jiným účelům už najednou nevypadlo tak zle si spustit ještě jednu další, vyhrazenou prakticky jen pro telefon.

Postupuje se u toho obvyklým způsobem generováním certifikátů pro CA, server a klienty, a to jak ručně, tak klidně i přes EasyRSA. Ale chce to, aby délka DH k zajištění PFS byla alespoň 2048 bitíků, jinak by to nestálo za nic. Konfigurace klienta by měla být co možná nejjednodušší, aby se nic už nemuselo měnit. Přípona konfigurace klienta je .ovpn, cesty k certifikátům jsou relativní a všechno se to v iTunes hodí do odpovídajícího místa dokumentů OpenVPN aplikace.

client.conf 134 bajtů
client
dev tun
proto udp

remote <server> 4500
resolv-retry infinite
nobind

ca ca.crt
cert client.crt
key client.key

comp-lzo
verb 1
OpenVPN - konfigurace tun klienta

Konstrukce serveru může mít ale svoje úskalí, pokud by to mělo celé běžet jako multi-tap+tun. Routování přes zařízení tun se totiž chová poněkud jinak a může se stát, že OpenVPN démon po startu nové tun vůbec nevytvoří. To se dá obejít specifikováním topology subnet a pokud už v routovací tabulce celého systému existuje cesta k místní síti, v tomto případě na eth0, pak je možné ji vynechat. Oproti jednoduchému klientovi je celá konfigurace přísná a musí klienty řídit. Obyčejně k tomu slouží push pro předhození parametrů a nejdůležitějším z nich je redirect-gateway local def1, zajišťující směrování veškerého datového toku telefonu z mobilních i WiFi sítí přes VPN tunel.

server.conf 522 bajtů
dev tun
topology subnet
mode server
tls-server
port 4500
proto udp

ca ca.crt
cert server.crt
key server.key
dh dh.pem

client-config-dir ccd
ifconfig-pool-persist ipp.txt
server 10.9.9.0 255.255.255.0
client-to-client

#route <eth0 network> 255.255.255.0
push "route <eth0 network> 255.255.255.0"
push "dhcp-option DNS <DNS IP>"
push "dhcp-option PROXY_AUTO_CONFIG_URL http://<IP>/proxy.pac"

push "redirect-gateway local def1"

keepalive 10 120

persist-tun
persist-key

verb 3
status /var/log/openvpn-tun.log

comp-lzo
OpenVPN - konfigurace tun serveru

Toto směrování může být žádoucí, ale je potřeba nezapomínat, že VPN není obvykle zapnutá neustále, takže se nemusí vztahovat na všechen provoz na pozadí. Dává taky smysl přiřadit VPN tunelu takový port, který bude pravděpodobně dostupný ze všech možných míst, kde je přísně filtrován provoz a omezeny jsou třeba streamy, IM a nestandardní porty. Protože smyslem VPN je vytvoření chráněné díry do systému, musí být ještě zakomponována do firewallu v duchu minule popisovaného whitelistu, tady ještě s nedávným upgradem fail2ban, který změnil název svého chainu.

firewall.conf 534 bajtů
*filter
:INPUT DROP [0:0]
...
:f2b-sshd - [0:0]
...
-A INPUT -i lo -j ACCEPT
-A INPUT -s <LAN IP>/24 -j ACCEPT
-A INPUT -s 10.9.9.0/24 -j ACCEPT
...
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
...
-A INPUT -j whitelist
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
...
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.9.9.0/24 -d <LAN IP> -o eth0 -m conntrack --ctstate NEW -j ACCEPT
...
-A f2b-sshd -j RETURN
...
COMMIT
*nat
...
-A POSTROUTING -s 10.9.9.0/24 -o eth0 -j MASQUERADE
...
COMMIT
Doplnění iptables s ohledem na whitelist

Kromě přístupu do LAN či ostatních sítí intranetu a do Internetu přes výchozí bránu serveru ještě stojí za zmínku možnost prohlížení darknetu Toru přímo v mobilním prohlížeči. DHCP v OpenVPN serveru se chová naprosto standardním způsobem a nic nebrání celosíťové specifikaci Proxy auto-config skriptu - a to je nesmírná výhoda, jelikož PAC v iOS jdou nastavit akorát tak na konkrétní WiFi.

Tor je primárně SOCKS, takže je vhodné vytvořit HTTP(S) proxy třeba přes Polipo nebo velkorážní Squid, záleží na vkusu. A pokud jde pouze o Tor a zároveň není potřeba anonymizovat skutečně všechen webový provoz pod VPN, umožňuje skript nastavit PACku jenom na cibulky, tedy vyfiltrování podle .onion domény.

proxy.pac.txt 219 bajtů
function FindProxyForURL(url, host)
{ 
	if (shExpMatch(url, "*.onion/*"))
	{
		# Polipo jako HTTP(S) proxy se socksParentProxy = "localhost:9050" - Tor
		return "PROXY <LAN IP>:<PORT>";
	} else {
		return "DIRECT";
	}
}
Automatická konfigurace proxy pro domény .onion

Je to celé nesmírně příjemné a zajišťuje všestranné použití telefonu v soukromých i krizových situacích z jakékoliv adresy na světě. Zahrnuje jak přístup do chráněných intranetových míst a řízení SSH a Minecraftu, tak vystupování v rámci LAN, šifrování všeho provozu a maskování se za konkrétní veřejnou IP serveru a v neposlední řadě i velmi pohodlnou možnost prohlížení Toru přímo na displeji.

Bezpečný cestovní routing je mocná zbraň a už za pár dní se ukáže, jak moc účinný bude v ostrém bitevním provozu našeho síťově filtrovaného velitelství a hlavně následně na velkolepě plánovaném výletě a dýmení za jízdy.

Tento článek přečetlo již 832 čtenářů (0 dnes).

Komentáře

Nový komentář