Wirtualne sieci prywatne, IPsec, FreeBSD

Wirtualne sieci prywatne, IPsec, FreeBSD
Zestawianie tunelu VPN pomiędzy dwoma sieciami w Internecie opartego na bramkach pracujących
pod kontrolą FreeBSD i IPsec.
VPN (ang. Virtual Private Network, Wirtualna Sieć Prywatna), można opisać jako "tunel", przez który
płynie ruch w ramach sieci prywatnej pomiędzy klientami końcowymi za pośrednictwem publicznej
sieci (takiej jak Internet) w taki sposób, że węzły tej sieci są przezroczyste dla przesyłanych w ten
sposób pakietów. Taki kanał może opcjonalnie kompresować lub szyfrować w celu zapewnienia
lepszej jakości lub większego poziomu bezpieczeństwa przesyłanych danych.
Ten dokument przedstawia krok po kroku proces uruchamiania IPsec oraz używania go w środowisku
maszyn pracujących pod kontrolą systemów FreeBSD oraz Microsoft® Windows® 2000/XP, tak aby
mogły się bezpiecznie ze sobą komunikować poprzez publiczną sieć Internet.
IPsec może być wykorzystany do bezpośredniego szyfrowania ruchu pomiędzy dwoma hostami
(znane jako Transport Mode) oraz budowania ”wirtualnych tuneli” pomiędzy podsieciami, co może być
zastosowane do komunikowania się dwóch sieci korporacyjnych (znane jako Tunell Mode) zwane
powszechnie jako Wirtualne Sieci Prywatne (VPN). Manulal ipsec(4) dokładniej opisuje implementację
protokołu IPsec wbudowanego w system FreeBSD.
Aby możliwe było korzystanie z IPsec w systemie FreeBSD, konieczne jest zmodyfikowanie kernela o
następujące parametry:
options
options
IPSEC
IPSEC_ESP
#IP security
#IP security (crypto; define w/ IPSEC)
Jeżeli chcielibyśmy załączyć tryb debugowania, do konfigu kernela dodatkowo należy dopisać:
options
IPSEC_DEBUG
#debug for IP security
Po uzupełnieniu pliku konfiguracyjnego o odpowiednie wpisy, należy kernel przekompilować i
ponownie uruchomić maszynę.
Scenariusz – dwie oddzielne sieci podłączone do Internetu, zachowujące się jak jedna
Wymagania:
•
•
•
•
•
•
dwie oddzielne sieci,
obydwie sieci zbudowane wewnątrz na bazie protokołu IP,
obydwie sieci podłączone do Internetu poprzez bramkę pracującą pod kontrolą FreeBSD,
bramka każdej z sieci posiada co najmniej jeden publiczny adres IP,
wewnętrzne adresy sieci mogą posiadać publiczne lub prywatne adresy IP, nie ma to żadnego
znaczenia, na bramce ich adresy mogą być poddawane translacji (NAT) na bramce,
klasy adresowe wewnętrznych sieci nie mogą ze sobą kolidować
Jeżeli zamierzasz połączyć dwie wewnętrzne sieci, używające tych samych prywatnych klas
adresowych (np. obydwie używają klasy 192.168.1.x) jedna z tych sieci musi być przeadresowana.
1
Schemat topologii sieci:
bramka 1
sieć
wewnętrzna 1
10.1.0.0/24
10.1.0.1
A.B.C.D
Internet
bramka 2
sieć
wewnętrzna 2
10.1.1.0/24
10.1.1.1
W.X.Y.Z
Drobna uwaga co do liter oznaczających adresy publiczne hostów, których będę używał w dalszej
części artykułu. Wszędzie gdzie będą one występowały, należy je zastąpić własnymi publicznymi
adresami IP. Należy również zauważyć, że bramki mają na interfejsie wewnętrznym adres IP .1 oraz,
to że dwie sieci, które chcemy złączyć używają oddzielnych klas (odpowiednio 10.1.0.x oraz 10.1.1.x).
Wszystkie maszyny w sieci wewnętrznej zostały skonfigurowane tak by używać maszynę .1 jako
swoją bramkę do Internetu.
Zatem zamiar jest taki by pomiędzy obiema sieciami wewnętrznymi istniała możliwość komunikacji tak
jak by były bezpośrednio podłączone do tego samego routera (z punktu widzenia rzeczywistości i
łącza którym na dzień dzisiejszy dysponujemy – dość wolnego routera).
Oznacza to, że komputer o numerze IP 10.1.0.12 będzie mógł wykonać
ping 10.1.1.31
i uzyska odpowiedź (przezroczyście) od komputera znajdującego się po drugiej stronie. Komputery z
systemem Windows będą mogły ”widzieć się” w sieci, będzie możliwe przeglądanie udostępnionych
katalogów tak jakby były w jednej sieci lokalnej.
Oczywiście cała komunikacja jest bezpieczna, to znaczy że wymiana danych pomiędzy sieciami jest
kodowana.
2
Utworzenie tunelu VPN pomiędzy sieciami to złożony proces, oto etapy:
1. Utworzenie wirtualnego połączenia pomiędzy sieciami poprzez sieć Internet. Przetestowanie
np. za pomocą polecenia ping(8), aby być pewnym, że tunel działa.
2. Zastosowanie polityki bezpieczeństwa aby zapewnić, że ruch pomiędzy dwoma sieciami jest
przezroczyście kodowany i dekodowany. Przetestowanie np. za pomocą narzędzia
tcpdump(1), aby upewnić się, że ruch jest kodowany.
3. Konfiguracja dodatkowego oprogramowania na serwerze FreeBSD, pozwalającego by
maszyny pracujące pod kontrolą Windows ”widziały” siebie nawzajem.
1. Utworzenie i testowanie wirtualnego połączenia
Będąc zalogowanym na maszynie pełniącej rolę bramki w pierwszej sieci (z publicznym adresem
IP A.B.C.D, prywatnym adresem IP 10.1.0.1), uruchamiamy ping 10.1.1.1, który jest
prywatnym adresem maszyny pełniącej rolę bramki w drugiej sieci o publicznym adresie W.X.Y.Z.
Co potrzebujemy by to zadziałało.
•
•
•
pierwsza bramka musi wiedzieć jak może ”zobaczyć” komputer o adresie 10.1.1.1, innymi
słowami musi mieć do niej trasę routingu,
prywatne adresy, postaci 10.x.x.x nie są używane w Internecie, oznacza to, że pakiety które
chcemy wysłać do 10.1.1.1 muszą być ”opakowane” w inne pakiety. Ów opakowany pakiet
musi przyjąć adres A.B.C.D i zostać wysłany do adresu W.X.Y.Z. Proces ten nazywany jest
enkapsulacją.
gdy już pakiet dotrze do adresu W.X.Y.Z konieczne jest by sostał od-enkapsulowany, oraz
dostarczony do adresu 10.1.1.1
Można więc powiedzieć, że potrzebujemy tunel pomiędzy dwoma sieciami. Dwie strony tunelu to
adresy IP A.B.C.D oraz W.X.Y.Z . Tunel ten transportować będzie pakiety z puli prywatnej,
poprzez publiczny Internet.
W systemie FreeBSD tunel tworzony jest używając interfejsu gif. Inaczej mówiąc interfejs gif
na każdej z bramek musi być skonfigurowany za pomocą dwóch adresów. Jednym z publicznej
puli, drugim z puli prywatnej adresów IP.
Obsługa interfejsu gif musi być wkompilowana w kernel na obydwu maszynach. Aby tak się
stało do configu Kornela należy dodać opcję:
device gif
oraz przekompilować kernel, zainstalować i uruchomić ponownie maszyny.
Konfiguracja tunelu następuje w dwóch etapach. Najpierw należy ustawić adresy zewnętrzne tunel
(publiczne IP), a następnie adresy, które będą przez nie transportowane (prywatne IP).
Na maszynie bramka 1 wykonujemy dwie komendy by skonfigurować tunel:
ifconfig gif0 create tunnel A.B.C.D W.X.Y.Z up
ifconfig gif0 inet 10.1.0.1 10.1.1.1 netmask 0xffffffff
analogicznie postępujemy na bramce 2:
ifconfig gif0 create tunnel W.X.Y.Z A.B.C.D up
ifconfig gif0 inet 10.1.1.1 10.1.0.1 netmask 0xffffffff
wykonując komendę:
ifconfig gif0
możemy zobaczyć jak wygląda nowo utworzony tunel:
więc na maszynie bramka 1 będzie to wyglądać następująco:
3
# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet A.B.C.D --> W.X.Y.Z
inet6 fe80::250:daff:fe8b:2cfb%gif0 prefixlen 64 scopeid 0x6
inet 10.1.0.1 --> 10.1.1.1 netmask 0xffffffff
Jak można zauważyć utworzony tunel pomiędzy adresami A.B.C.D oraz W.X.Y.Z pozwala na
przesyłanie danych pomiędzy adresami 10.1.0.1 oraz 10.1.1.1
Routing tables
Internet:
Destination
...
10.1.1.1
...
Gateway
Flags
10.1.0.1
UH
Refs
Use
710
3710
Netif Expire
gif0
Aby możliwe było również przesyłanie danych pomiędzy adresami z podsieci konieczne jest
dodanie trasy routingu:
bramka 1:
route add -net 10.1.1.0/24 10.1.1.1
bramka 2:
route add -net 10.1.0.0/24 10.1.0.1
Dzięki tym ustawieniom oddzielone przez Internet prywatne sieci mogą się komunikować.
Aby jednak ten tunel oraz tablica routingu ustawiana była przy uruchamianiu systemu, dopiszmy
do rc.conf:
bramka 1:
gif_interfaces="gif0"
gifconfig_gif0="A.B.C.D W.X.Y.Z"
ifconfig_gif0="10.1.0.1 10.1.1.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="-net 10.1.1.0/24 10.1.1.1"
bramka 2:
gif_interfaces="gif0"
gifconfig_gif0=" W.X.Y.Z A.B.C.D "
ifconfig_gif0="10.1.1.1 10.1.0.1netmask 0xffffffff"
static_routes="vpn"
route_vpn="-net 10.1.0.0/24 10.1.0.1"
2. Zabezpieczenie połączenia
Aby zabezpieczyć nasz tunel użyjemy protokołu IPsec. Na początku protokołu wspominałem, że
musimy wkompilować obsługę IPsec w jądro. Jeżeli mamy już tą rzecz za sobą, możemy zabrać
się za szyfrowanie tunelu. Do tego celu potrzebne będzie doinstalowanie ipsec-tools znajdujących
się w drzewie ports, więc:
cd /usr/ports/secuirity/ipsec-tools/
make install clean
Do rc.conf dopiszmy jeszcze:
racoon_enable="YES"
Wymianą kluczy zajmie się racoon, który do swojego prawidłowego działania wymaga utworzenia
kluczy zaufania na obydwu hostach, oraz prawidłowego pliku konfiguracyjnego (możemy użyć
standardowego pliku znajdującego się w przykładach), zatem:
4
cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/
oraz plik z kluczami psk.txt
bramka 1:
W.X.Y.Z
mojetajnehaslo
bramka 2:
A.B.C.D mojetajnehaslo
pamiętajmy, że plik ten może być jedynie czytany przez root-a więc:
chmod 0600 /usr/local/etc/raccoon/psk.txt
następnie w pliku ipsec.conf zdefiniujmy kodowanie tunelu:
bramka 1:
spdadd
10.1.0.0/24
W.X.Y.Z/require;
spdadd
10.1.1.0/24
A.B.C.D/require;
10.1.1.0/24
any
10.1.0.0/24
any
10.1.0.0/24
any
10.1.1.0/24
any
-P
-P
out
ipsec
esp/tunnel/A.B.C.D-
in
ipsec
esp/tunnel/W.X.Y.Z-
out
ipsec
esp/tunnel/W.X.Y.Z-
in
ipsec
esp/tunnel/A.B.C.D-
bramka 2:
spdadd
10.1.1.0/24
A.B.C.D/require;
spdadd
10.1.0.0/24
W.X.Y.Z/require;
-P
-P
Do rc.conf dopiszmy jeszcze:
ipsec_enable="YES"
Po załadowaniu reguł IPsec oraz starcie demona racoon, koniecznego do wymiany kluczy nasz
ruch pomiędzy sieciami jest kodowany. Możemy to sprawdzić używając fingując z bramki1
wewnętrzny adres bramki2 oraz podglądając transmisję pomiędzy tymi hostami programem
tcpdump, więc:
ping 10.1.1.1
a na kolejnej konsoli:
tcpdump dst host W.X.Y.Z
To co powinniśmy zobaczyć, to zakodowana transmisja po protokole ESP:
tcpdump dst host W.X.Y.Z
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
20:29:44.986706 IP A.B.C.D > W.X.Y.Z: ESP(spi=0x0103f965,seq=0x26), length 116
20:29:45.987570 IP A.B.C.D > W.X.Y.Z: ESP(spi=0x0103f965,seq=0x27), length 116
20:29:46.988421 IP A.B.C.D > W.X.Y.Z: ESP(spi=0x0103f965,seq=0x28), length 116
^C
3 packets captured
89 packets received by filter
0 packets dropped by kernel
5
i tak samo powinno to wyglądać dla każdej usługi:
# ftp 10.1.1.1
Connected to 10.1.1.1.
220---------- Welcome to Pure-FTPd [TLS] ---------220-You are user number 2 of 50 allowed.
220-Local time is now 20:38. Server port: 21.
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (10.1.1.1:jasiu):
331 User jasiu OK. Password required
Password:
230-User jasiu has group access to: wheel
230 OK. Current directory is /usr/home/jasiu
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
output z tcpdump:
# tcpdump dst host 192.168.1.60
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
20:32:36.975418 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xca),
length 100
20:32:36.977079 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xcb),
length 84
20:32:37.089883 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xcc),
length 84
20:32:41.942218 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xcd),
length 100
20:32:42.044149 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xce),
length 84
20:32:45.464018 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xcf),
length 100
20:32:45.603612 IP 192.168.1.11 > 192.168.1.60: ESP(spi=0x0103f965,seq=0xd0),
length 84
^C
7 packets captured
2416 packets received by filter
0 packets dropped by kernel
I już nie musimy się martwić, że przy sesji FTP przesyłamy hasło naszego konta otwartym
tekstem.
3. Konfiguracja dodatkowego oprogramowania,
Otoczenie sieciowe, SAMBA
W przygotowaniu.
autor: Janusz Pruszewicz <[email protected]>
źródła:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html
http://ipsec-tools.sf.net
http://ipsec.pl/ipsec/
6