Všetky obrázky z blogu sú fuč kôli diskovej nehode a mojej lenivosti. Použite predstavivosť :) Sry

Big Brother is watching a človek nikdy nevie či práve nie na nás. Preto je dnes výhodné šifrovať čo sa dá. Ja osobne mám dobrý pocit ked viem, že mi t-com ropuchy nehľadia na traffic. V podstate má bežný človek dve možnosti: SSH tunel alebo VPN tunel. Zatiaľ čo pri prvom potrebujete len shell konto na nejakom "zvonku" adresovateľnom serveri, v druhom prípade už potrebujete
vlastný server (stačí malé VPS). SSH tunel má tú nevýhodu (alebo výhodu?), že cez tunel pôjde len ten traffic, ktorý tam sami nasmerujete a musíte sa všade babrať s konfiguráciou proxy a pod. Routovať všetok traffic VPN tunelom je v tomto omnoho  pohodlnejšie, aplikácie ani nevedia, že komunikujú šifrovane (teda aspoň časť "cesty" :)). Paradoxne sa nebudeme zaoberať  vytvorením VPN tunela, ale len tomu ako nastaviť routing. V podstate to všetko bude viesť len k trom krátkym príkazom, resp.  jednej konfiguračnej direktíve v konfiguráku naviac, ale kedže rád všetko obkecávam tak aj vysvetlím ako to fugnuje, akokoľvek  je to jednoduché.

-- VPN tunel --

Na vytvorenie VPN používam OpenVPN. Pokiaľ chcete jednorázový tunel medzi dvoma strojmi, postačí vám jednoduchá,  symetricky šifrovaná VPN. Ak ale chcete väčšiu sieť už sa tam zamotáva PKI, certifikáty a všelijaké iné kryptovýrazy. Ja osobne  používam druhú variantu, kedže mám pripojených aj kamarátov :). Všetky kryptozáležitosti tu uľahčuje balík easy-rsa2, ktorý je  (aspoň v debiane) štandardne pri OpenVPN. Ako vytvoriť jednoduchú vlastnú OpenVPN sieť je zrozumiteľne napísané  napríklad

http://www.jariq.sk/2008/10/14/vpn-siete-s-openvpn-1/ tu
http://www.jariq.sk/2008/10/20/vpn-siete-s-openvpn-2/ tu
http://www.jariq.sk/2008/11/11/vpn-siete-s-openvpn-3/ tu
http://www.jariq.sk/2008/12/01/vpn-siete-s-openvpn-4/ tu
http://www.jariq.sk/2009/01/21/vpn-siete-s-openvpn-5/ a tu

OpenVPN vytvorí v systéme nové virtuálne sieťové TUN/TAP rozhranie, ktorému bude pridelená IP zo segmentu vyhradeného pre lokálne siete (10/8, 172.16/12, 192.168/16). Server a klient sa následne budú javiť ako keby boli na jednom sieťovom  segmente. Budem sa zaoberať bridge-vanou VPN, teda rozhranie TAP a nie TUN.

-- Routing --

Predpokladajme nasledujúcu situáciu (celkom bežnú). Server má jedno rozhranie eth0 s  adresou 93.229.33.133, ktorým je pripojený do internetu , klient takisto (IP povedzme 192.168.1.11). Klient používa na prístup  do internetu bránu s adresou 192.168.1.1. Routovacia tabulka na klientovi vyzerá takto:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0

Prvý záznam zabezpečuje, že pakety smerujúce do sieťe 192.168.1.0/24 nebudú forwardované cez žiadnu bránu ale rovno  adresované príjemcovi (komunikácia na LAN). Záznam týkajúci sa rozhrania lo si všímať nemusíme. Posledný záznam je  najdôležitejší a zabezpečuje aby sa pakety smerujúce do akejkoľvek siete (0.0.0.0/0 pokrýva všetky IPv4 adresy) doručili bráne  192.168.1.1 (tá ich potom prepošle do internetu).

Linux používa tzv metódu "Longest prefix match", to znamená že ak v nejakom prípade vyhovuje viac routovacích záznamov,  použije sa ten viac špecifickejší (s "vyššou" maskou siete ).

Povedzme, že chcem poslať paket na další počítač v lokálnej sieti s IP 192.168.1.15. V tomto prípade vyhovuje aj záznam 192.168.1.0/24 aj 0.0.0.0/0 (ten predsa pokrýva všetky možné adresy). Kedže záznam 192.168.1.0/14 je ale špecifickejší,  routovať sa bude podľa toho. Schému našeho pripojenia na internet teraz vyjadruje nasledujúci vysoko profesionálny obrázok:



Teraz pomocou openvpn (alebo aj inak) vytvoríme VPN tunel medzi nami a naším serverom. Vytvorí sa akýsi vlastný samostatný  segment siete, ktorý sa bude javiť ako lokálna sieť, avšak dáta pôjdu šifrovane cez celý internet. OpenVPN vytvorilo nové sieťové  rozhranie a pridelilo mu IP z rozsahu 172.16.0.0/24 (záleží od toho ako ho nakonfigurujete) Routovacia tabuľka teraz  vyzerá nasledovne

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0


Vidíme, že pribudol nový záznam, ktorý hovorí o tom, že pakety do 172.16.0.0/24 sa nebudú forwardovať cez bránu do  internetu ale jedná sa o lokálnu sieť. V skutočnosti samozreme budú cez bránu prechádzať, operačný systém o tom ale nemá ani tušenie a VPN sieť sa mu javí ako lokálna sieť (o všetko sa stará OpenVPN). Upravená schéma vyzerá teraz takto:



Zo serverom môžeme komunikovať priamo cez VPN tunel, spojenia na ostatné serveri ale stále idú nešifrovane pôvodnou  cestou. Čakajú nás teda dve úlohy:

1. Zaistiť aby všetka komunikácia od nás prechádzala cez server
2. Zaistiť aby server preposielal našu komunikáciu dalej do internetu

Prvé, čo musíme urobiť, je nastaviť výchoziu bránu (0.0.0.0/0) na IP adresu VPN servera. Zmeníme teda routovací záznam  nasledujúcim príkazom 

# route add -net 0.0.0.0 netmask 0.0.0.0 gw 172.16.0.1

Problém však je, že keď sa pokúsime kontaktovať 172.16.0.1, OpenVPN sa pokúsi kontaktovať 93.229.33.133 (IP servera mimo  VPN tunel). Nepodarí sa mu to však kedže na to by musel kontaktovať bránu 192.168.1.1, ale v routovacej tabulke o nej žiadna  zmienka nie je. Musíme teda nastaviť routing tak, aby sa LEN pri pokuse kontaktovať 93.229.33.133 použila brána 192.168.1.1.  To presne robí nasledujúci príkaz

# route add -host 93.229.33.133 gw 192.168.1.1

Klientskú časť máme hotovú. Zostáva zabezpečiť aby server náš traffic preposielal ďalej. Kedže v routovacej tabuľke môžeme  kontrolovať smer paketov len na základe ich cieľovej adresy, musíme siahnuť po paketovom filtri integrovanom v jadre linuxu -  Netfilter, resp. konfiguračnom nástroji iptables. Konkrétne budeme modifikovať tabuľku nat v reťazci POSTROUTING. Musíme  zabezpečiť aby server pakety pochádzajúce zo subnetu 172.16.0.0/24 preposlal tak, že zmení ich zdrojovú IP adresu na IP pridelenú k eth0 a pri odpovedi na tieto pakety z internetu zase zmení cieľovú adresu na IP stroja zo subnetu 172.16.0.0/24,  ktorý spojenie začal. Tento postup sa volá IP maškaráda (IP masquerading) a linuxový netfilter ju samozrejme podporuje. Všetko  obstará nasledujúci príkaz

# iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE

HOTOVO! Všetok traffic od nás teraz bude prechádzať cez šifrovaný VPN tunel na server a až odtiaľ ku svojmu cieľu. Ale sme  to nandali tým T-komunistom. Ďalšia profesionálna schéma nesmie chýbať

-- DEFAULT GATEWAY HACK --

OpenVPN má zabudú konfiguračnú direktívu "redirect gateway def1", ktorá spôsobí , že na klientskom PC sa "sami od seba" pridajú rovnaké pravidlá ako sme si písali hore. Nemusíte teda nič robiť ručne, stači do konfiguračného súboru openvpn servera pridať "push "redirect-gateway def1"". OpenVPN ale neprepisuje pôvodný routovací záznam, namiesto toho využíva pravidlo  "Longest prefix match" (viď hore) a definuje rozsah, ktorý pokrýva všetky možné IPv4 adresy presnejšie, ako 0.0.0.0/0. Ako je to  možné? Používa dvojicu rozsahov 0.0.0.0/1 a 128.0.0.0/1. Každý z týchto rozsahov pokryje presne polovicu celého IPv4  adresného priestoru. Kedže platí pravidlo čím vyššia sieťová maska (v tomto prípade 128.0.0.0), tým väčšiu váhu záznam má,  pre defaultný routing bude teda použitá brána nastavená pri týchto rozsahoch. Je to chytrý spôsob ako prepísať výchoziu bránu  bez toho aby sme prepisovali pôvodný záznam a museli si pametať pôvodné hodnoty. Po tomto "hacku" vyzerá routovacia tabuľka  nasledovne

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
93.229.33.133   192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         172.16.0.1      128.0.0.0       UG    0      0        0 tap0
128.0.0.0       172.16.0.1      128.0.0.0       UG    0      0        0 tap0
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0

Pre prechod do pôvodného stavu teda stačí len vymazať pridané záznamy.

Konfiguračná direktíva redirect-gateway v OpenVPN síce uľahčuje robotu, ak ste ale napr. programátor a potrebujete analyzovať  sieťové protokoly, nebude to bohužiaľ jednoducho možné kedže všetko je šifrované. Preto túto direktícu nepoužívam a radšej  mám napísany skript ktorým jednoducho vypínam a zapínam routovanie trafficu po VPN. Skript je veľmi jednoduchý a vyzerá  nasledovne

#!/bin/bash

ORIGGW=192.168.1.1
OVPNS=93.229.33.133
VPNGW=172.16.0.1

if [ "$1" = "start" ];then
ACTION=add
elif [ "$1" = "stop" ];then
ACTION=del
else
echo "Usage: $0 (start|stop)"
exit 1
fi

route $ACTION -host $OVPNS gw $ORIGGW &&
route $ACTION -net 0.0.0.0 netmask 128.0.0.0 gw $VPNGW &&
route $ACTION -net 128.0.0.0 netmask 128.0.0.0 gw $VPNGW

Lepším riešením je samozrejme vytvárať VPN tunel až na vychozej bráne, nie každý však disponuje "VPN capable" routerom :).