Blog
Podsieć /48, czyli jak Krzysztof stał się bogaty...
06.04.2008 - Niedziela - 21:15
...w adresy IPv6 ;-)
W piątek złożyłem "podanie" o przydzielenie podsieci do mojego tunelu. Poczekałem dwie godziny i załoga SixXS przydzieliła mi pulę adresów z podsieci /48.
Krzysztof dostał podsieć 2001:6a0:14d::/48, a to oznacza, że mam możliwość zapisania adresów hostów na 80 bitach. Właściwie to mam 2^16 adresów sieci, a w każdej 2^64 adresów hostów, co daje razem 2^80 unikalnych adresów IPv6. Daje to dokładnie 1208925819614629174706176, ale dla prostoty zaokrąglimy to do 1,208*10^21 adresów IPv6, czyli 1,2 tryliarda adresów IP. Dla porównania, cała pula adresowa IPv4 to 2^32 adresów, czyli 4,2 miliarda adresów. Trochę mało, prawda? ;-)
Oczywiście nie posiadam tylu urządzeń, żeby móc wykorzystać nawet 1% tych adresów, ale może kiedyś... ;-) Ogólnie w protokole IPv6 chodzi o to, żeby każde urządzenie miało swój własny unikalny adres IPv6 i żeby nie stosować maskarady i innych podobnych rozwiązań. Jedna z metod autokonfiguracji interfejsu polega na tym, że adres sprzętowy (48-bitowy MAC w przypadku Ethernetu) rozszerza się do 64 bitów (ostatnie 64 bity adresu IP to Device ID) i tak spreparowany adres wstawia się do adresu sieci. Taka sieć oczywiście musi być /64. Jest to tak zwany mechanizm Stateless autoconfiguration, który wykorzystuje specjalne wiadomości ICMPv6: Router Advertisement, Router Solicitation, Neighbor Advertisement i Neighbor Solicitation. Pod Linuksem obsługą tego mechanizmu zajmuje się demon radvd (Router Advertisement Deamon) i spełnia podobne funkcje co DHCP w sieciach IPv4 (istnieje również DHCPv6). W ten sposób, każde dołączone do sieci urządzenie automatycznie dostaje swój własny, unikalny adres IPv6 i jest konfigurowane do routowania ruchu IPv6 na odpowiednie interfejsy.
Sieć SixXS pozwala również na przejęcie odwrotnej strefy DNS dla używanej podsieci. Oczywiście też już sobie skonfigurowałem i w sieci IPv6 mój komputer jest widoczny jako wifi.ed74.sawicki.eu.org, a nie jako 2001:6a0:14d:1:215:afff:fe2d:d813 ;-) Wykorzystałem do tego serwer DNS na SGH (FreeDNS).
Cała konfiguracja IPv6 do działania na routerze linuksowym i na linuksowych stacjach jest banalna. Pod Windowsem XP (jeden z moich komputerów niestety chodzi pod tym przeklętym systemem) też nie jest problemem. Ale ilość opcji pod Windowsem jest nadzwyczaj skąpa. Cóż wymagać od Microsoftu.
Udało mi się nawet skonfigurować OpenVPN do stworzenia wirtualnego ethernetu (nie tunelu), w którym każde (wirtualne) urządzenie również dostaje automatycznie adres IPv6.
OpenVPN - prosta i szybka konfiguracja
09.02.2008 - Sobota - 21:57
Chciałbym napisać w jaki sposób połączyć siecią wirtualną dwa komputery działające pod kontrolą systemu GNU/Linux i wykorzystujące oprogramowanie OpenVPN.
Podstawową sprawą jest posiadanie OpenVPN. Ten program nie ma wydzielonej części serwerowej i klienckiej. W zależności od zawartości pliku konfiguracyjnego może działać jako klient lub serwer (a nawet jako jedno i drugie). Ja, Ubunciarz z wyboru, nie parałem się kompilacją programu ze źródeł. Po co? ;-) Wklepałem po prostu apt-get install openvpn i po chwili miałem już zainstalowane oprogramowanie.
Całość konfiguracji sprowadza się do kilku prostych czynności. Pierwszą jest wygenerowanie klucza, który będzie używany do szyfrowania danych przesyłanych przez VPN. Jak? Banalnie...
root@eu07:~# openvpn --genkey --secret plik.key
Plik z kluczem przekopiowałem do katalogu /etc/openvpn zarówno w jednym jak i drugim komputerze. Wiem, że ten plik powinien być "secret", ale kto mi go przeczyta? Ja sam? ;-)
Następnie należy stworzyć pliki konfiguracyjne serwera i klienta. OpenVPN w trakcie startu przeszukuje /etc/openvpn w poszukiwaniu plików *.conf, a następnie je analizuje i uruchamia się wedle ich zaleceń. Jeden plik - jedna instancja OpenVPN, klienta lub serwera.
Zatem vi /etc/openvpn/server1.conf
dev tun secret /etc/openvpn/plik.key proto tcp-server ifconfig 192.168.11.1 192.168.11.2 daemon verb 4 log-append /var/log/openvpn.log keepalive 10 900 inactive 360000 comp-lzo
W pierwszej linijce pliku konfiguracyjnego wskazujemy OpenVPN, żeby korzystał z mechanizmu TUN, czyli enkapsulacji pakietów w warstwie trzeciej (sieci). Istnieje możliwość pracy w warstwie drugiej (łącza danych) przy pomocy mechanizmu TAP. Oczywiście TAP/TUN musi być obsługiwane przez jądro. Kolejna linia to wskazanie pliku zawierającego klucz. Linijka proto to wybór protokołu. Próbowałem opcji UDP, ale z nieustalonych jeszcze przeze mnie przyczyn nie nawiązałem transmisji pomiędzy komputerami wpiętymi w sieć VPN. Linijka ifconfig to linia wskazująca adresy IP węzłów sieci. Pierwszy adres to adres komputera, na którym jest ta instancja uruchamiana, drugi to adres komputera odległego. Interfejsy są konfigurowane w trybie point to point, a więc nie można podłączyć kilku komputerów do jednego serwera. Według dokumentacji jest to możliwe, ale mi nie wyszło. Linia daemon może pozostać bez wyjaśnienia ;-) Następnie poziom gadatliwości w logach - maksymalnie gadatliwy to dziewiątka; ścieżka do pliku logów i czasy utrzymywania serwera i interfejsów bez transmisji. Wartość inactive polecam ustawić dość dużą, jeśli serwer VPN nie będzie miał cały czas podłączonego klienta wymieniającego dane. No i na końcu wkazujemy, że chcemy wykorzystać kompresję danych.
Teraz należy zadbać o odblokowanie portu 1194 (domyślnego portu OpenVPN) dla transmisji TCP na maszynie, która będzie służyć za serwer.
root@eu07:~# iptables -A INPUT -p tcp --dport 1194 -s 0/0 -j ACCEPT
Cóż pozostaje zrobić teraz? Skonfigurować klienta: vi /etc/openvpn/client1.conf
dev tun proto tcp-client remote adres.serwera.net 1194 secret /etc/openvpn/plik.key ifconfig 192.168.11.2 192.168.11.1 keepalive 10 60 route 192.168.0.0 255.255.255.0 route 192.168.1.0 255.255.255.0 comp-lzo
Wyjaśnić należy linijkę remote, w której zapisany jest adres serwera (ten zewnętrzny, w sieci Internet) oraz port na, którym działa serwer. Różnica jest w linijce ifconfig - adresy zapisane są w odwrotnej kolejności, ale nadal pierwszy to adres końca lokalnego, a drugi końca odległego. Linijki route to informacje, że ruch do podsieci tam wymienionych ma być realizowany z wykorzystaniem VPN. W tym przypadku to adresy sieci rzeczywistych, które są osiągalne z serwera (który pełni dla nich funkcję routera z NAT).
Teraz tylko trzeba wszystko wystartować:
root@eu07:~# /etc/init.d/openvpn start
krzysztof@ed74:~$ sudo /etc/init.d/openvpn start
Teraz można sprawdzić czy VPN działa:
krzysztof@ed74:~$ ping 192.168.11.1 PING 192.168.11.1 (192.168.11.1) 56(84) bytes of data. 64 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=6.42 ms 64 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=5.61 ms 64 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=5.26 ms --- 192.168.11.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 5.262/5.765/6.420/0.484 ms
Widzą się, ale...
krzysztof@ed74:~$ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. --- 192.168.0.1 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9008ms
Mimo, że wskazaliśmy komputerowi, że do tej sieci ma pakiety puszczać przez VPN transmisji nie ma. Istotnie wszystkie pakiety, które wysyłamy do 192.168.0.1 są puszczane przez VPN, ale na serwerze nie ma regułek przekazywania pakietów pomiędzy sieciami.
root@eu07:~# iptables -A FORWARD -s 0/0 -d 192.168.11.0/24 -j ACCEPT root@eu07:~# iptables -A FORWARD -s 192.168.11.0/24 -d 0/0 -j ACCEPT
Dopiero po takim posunięciu komputer-serwer potraktuje VPN jak każdą inną sieć podpietą do niego i będzie przekazywał pakiety do innych sieci. Nie ma sensu włączać maskarady (NAT) dla tej podsieci, bo wciąż poruszamy się w zakresie adresów z puli prywatnej, które w sieci wewnętrznej będą śmigały aż miło.
