VPN dla Windows Phone 8.1 korzystając z Raspberry Pi
Windows Phone 8.1 wprowadził, jako długo oczekiwaną nowość, obsługę sieci VPN, co pozwala w najogólniejszym przypadku na bezpieczne (bo szyfrowane) połączenie się z zewnątrz do naszej sieci firmowej (lub domowej). A w nieco bardziej szczegółowym przypadku pozwala również, aby cały ruch internetowy przechodził przez naszą sieć, co jest niezłym rozwiązaniem z punktu widzenia bezpieczeństwa - ze względu na szyfrowane połączenie możemy z mniejszymi obawami korzystać z otwartych hot-spotów, a nasz ruch będzie NSA dopiero odczytywać po wyjściu z domowego routera.
Jak wygląda konfiguracja mojej domowej sieci, na której przykładzie będę demonstrował uruchomienie VPN?
Sieć ma adresację 172.27.13.0/24. Serwerem DHCP jest domowej klasy router firmy Linksys, z oryginalnym oprogramowaniem, który znajduje się pod adresem 172.27.13.1, i to on nadaje adresy komputerom w sieci. Raspberry Pi (w moim przypadku model B, rev. 2) jest podłączone do routera i samo posiada adres 172.27.13.17, ale nie jest to specjalnie istotne w tym poradniku. Nieco bardziej istotny jest fakt, że używam dystrybucji Arch Linux. W sumie niezbyt istotny jest nawet fakt, że posiadam Raspberry Pi, bo wystarczy dowolne urządzenie z Linuksem - ale tutaj koncentruję się na fakcie mojej rzeczywistej konfiguracji.
Windows Phone 8.1, w tym momencie, obsługuje tylko jeden rodzaj sieci VPN, są to sieci oparte o protokół IKEv2, którego najważniejszą zaletą jest to, że został zaprojektowany dla sytuacji, w których mogą występować problemy z połączeniem - a sieci komórkowe akurat do takich mogą należeć. Sam Windows Phone ma możliwość dodania obsługi innych protokołów VPN, ale obecnie żadna taka aplikacja nie znajduje się w Sklepie (zapewne z powodu niezakończonego wdrożenia tej wersji platformy). IKEv2 jest jednym z protokołów z gałęzi IPsec, więc niezbędny nam będzie serwer IPsec - w przypadku Archa moim wyborem był strongSwan.
StrongSwan jest jednak dostępny tylko w ramach AUR, a nie w oficjalnych repozytoriach. Aby go zainstalować można skorzystać np. z yaourt, który jest wygodną w użyciu nakładką na AUR, ze składnią poleceń podobną do menadżera pakietów pacman.
yaourt -S strongswan
Konfiguracja strongSwan
Dalej, niezbędne będzie skonfigurowanie naszego strongswana. Do tego celu należy zedytować plik /etc/ipsec.conf - ja używam takich opcji konfiguracyjnych, które znalazłem w innym poradniku na ten temat.
config setup strictcrlpolicy=no conn rw-mschapv2 ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 keyexchange=ikev2 left=%any leftsubnet=0.0.0.0/0 leftid=<ADRES ALBO DOMENA> leftcert=vpn.crt leftauth=pubkey leftfirewall=yes right=%any rightsourceip=<SIEĆ VPN> rightauth=eap-mschapv2 rightsendcert=never eap_identity=%any auto=start compress=yes
Znajdują się tutaj jednak dwie zmienne, które koniecznie należy zmienić - <ADRES ALBO DOMENA> musi być nazwą serwera (w postaci pełnej domeny poprzedzonej znakiem @, np. @example.com) lub adresem IP, do którego będzie się łączyć nasz telefon. Ja mam tutaj domenę i niestety nie próbowałem robić opcji bez nazwy domenowej - która będzie potrzebna w jeszcze jednym kroku.
Drugą zmienną jest <SIEĆ VPN> - należy tutaj podać identyfikator podsieci (w postaci adres/maska), z której zostanie telefonowi przyznany adres. Ja mam tutaj wartość 172.29.13.0/24. Jest możliwe nadawanie urządzeniom adresów z głównej puli, ale ja tutaj używam wydzielonej podsieci - podobną mam również dla drugiego mojego rozwiązania VPN. Podobno dla Windows Phone niezbyt dobrze działa używanie jednego DHCP - zwłaszcza uniemożliwia to połączenie z VPN z wewnątrz domowej sieci.
Istotna jest jeszcze nazwa certyfikatu - vpn.crt, widoczna powyżej. Tę nazwę pliku trzeba będzie nadać.
Dalej, trzeba będzie przekazać telefonowi adresy serwerów DNS. Konfigurujemy to w pliku /etc/strongswan.d/charon/attr.conf dodając adresy wewnątrz sekcji attr. Przykładowo:
dns = 8.8.8.8, 8.8.4.4
Krok kolejny, to nazwa konta użytkownika i hasła dostępu do sieci VPN. Konfigurujemy to w pliku /etc/ipsec.secrets i tutaj pojawia się pewien haczyk - telefon nie wysyła nazwy konta np. "ktos", ale wysyła nazwę urzędzenia i nazwę konta, podobnie jak w logowaniu domenowym w Windows - np. "Narra\ktos" w moim przypadku. Nazwa urządzenia jest widoczna po jego podłączeniu do komputera, a także jest nazwą Bluetooth i standardowo ma postać nazwy modelu, np. "Lumia 820".
W pliku ipsec.secrets można skonfigurować konta, np.:
: RSA vpn.key "Narra\ktos" : EAP "bardzotajnehaslo" "Lumia 820\billg" : EAP "haslodlainnegousera"
Pierwsza linijka będzie dodatkowo określać nazwę pliku z kluczem certyfikatu serwera.
Konfiguracja OpenSSL
Połowę konfiguracji OpenSSL ja osobiście mam za sobą, ponieważ już posiadam własne, autoryzowane tylko dla mojej sieci domowej, Centrum Autoryzacji, którym podpisuję swoje własne certyfikaty i którego certyfikat główny jest już zainstalowany na moich komputerach i telefonach. Nie jest to jednak bardzo skomplikowane.
Warto zrobić sobie kopię pliku /etc/ssl/openssl.cnf w jakimś podkatalogu katalogu domowego i na nim wykonywać prace. Należy w konfiguracji, w sekcji o nazwie [v3_ca], dodać (albo odkomentować) kilka dodatkowych instrukcji:
basicConstraints = critical, CA:true extendedKeyUsage = serverAuth keyUsage = critical, keyCertSign, cRLSign
Windows jest bardzo "czuły" na certyfikaty i muszą one zawierać pewne dodatkowe atrybuty.
Jeżeli nie posiadacie własnego CA, trzeba je stworzyć:
openssl genrsa -out ca.key 1024 openssl req -new -x509 -key ca.key -out ca.crt -days 1095 -config openssl.cnf
Druga komenda zada wiele pytań - o kraj, o województwo, o nazwę - warto wpisać sensowne rzeczy, aby było wiadomo, że to na pewno jest nasz certyfikat, zwłaszcza w sekcji Common Name.
Te dwie komendy stworzą certyfikat ca.crt i klucz prywatny certyfikatu ca.key ważne przez 3 lata. Jest to certyfikat własnego centrum certyfikacyjnego. Ten certyfikat, ca.crt, należy zainstalować na telefonie - można go zapisać na telefonie i uruchomić aplikacją Pliki, przesłać e-mailem, wystawić w Internecie.
Certyfikat dla VPN
Teraz, możemy stworzyć certyfikaty dla naszego serwera VPN, podpisane przez nasze Centrum Autoryzacji. Aby być pewnym, że Windows przyjmie dobrze nasze certyfikaty, trzeba stworzyć plik konfiguracyjny, np. vpn.conf i podać w nim dodatkowe atrybuty dla certyfikatu:
extendedKeyUsage = serverAuth subjectAltName = DNS:<NAZWA DOMENY> authorityKeyIdentifier=keyid
Tutaj należy zmienić <NAZWA DOMENY> na nazwę domeny naszego serwera VPN.
Dalej, generujemy i podpisujemy certyfikat dla serwera VPN:
openssl genrsa -out vpn.key 1024 openssl req -new -key vpn.key -out vpn.csr openssl x509 -req -days 1094 -in vpn.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out vpn.crt -extfile vpn.conf
I znów opcja openssl req zapyta nas o wiele szczegółów - najważniejsze tutaj jest, że opcja CommonName (CN) MUSI BYĆ IDENTYCZNA Z DOMENĄ NASZEGO SERWERA VPN. Wygenerowany certyfikat będzie ważny 3 lata.
Należy skopiować odpowiednie pliki w odpowiednie miejsca:
cp ca.crt /etc/ipsec.d/cacerts/ cp vpn.crt /etc/ipsec.d/certs/ cp vpn.key /etc/ipsec.d/private/
I jesteśmy prawie gotowi. Pamiętajcie o zainstalowaniu ca.crt na telefonie - bez tego odrzuci certyfikat serwera VPN, jako niezaufany.
Konfiguracja routingu
Skoro telefon wyląduje w podsieci 172.29.13.0/24, a moja sieć jest w 172.27.13.0, to coś musi dane pomiędzy podsieciami przesłać. I będzie to Raspberry Pi. Niezbędne będzie ustawienie kilku flag w /etc/sysctl.conf, które uaktywnią mechanizmy routingu:
net.ipv4.ip_forward = 1 net.ipv4.conf.default.proxy_arp = 1 net.ipv4.conf.default.arp_accept = 1 net.ipv4.conf.default.proxy_arp_pvlan = 1
(po edycji sysctl.conf należy wykonać restart albo sysctl -p /etc/sysctl.conf, albo w zasadzie dla testów wystarczy spokojnie echo 1 > /proc/sys/net/ipv4/ip_forward)
Oraz włączenie NAT, poprzez wydanie polecenia:
iptables —table nat —append POSTROUTING —jump MASQUERADE
Jesteśmy prawie na końcu. IKEv2 korzysta z portów UDP 500 i 4500, należy je przekierować na routerze do naszego Raspberry Pi.
Testy
Należy skonfigurować teraz opcję VPN na telefonie, dodając nowy profil - podając nazwę serwera, nazwę użytkownika (bez nazwy telefonu, np. samo "billg") i hasło, oraz nazwę profilu sieci dla rozróżnienia.
Przetestować serwer można łatwo uruchamiając go bezpośrednio, przez co wszystkie komunikaty diagnostyczne pojawią się na konsoli:
/usr/bin/ipsec start —nofork
Tutaj można również sprawdzić, jaka jest nazwa telefonu - połączenie się nie powiedzie z komunikatami w konsoli postaci "13[IKE] received EAP identity" i będzie tam podane jak telefon próbował się przedstawić naszemu serwerowi, więc można wykonać odpowiednie zmiany w /etc/ipsec.secrets.
Jeżeli połączenie się powiedzie, zostaje tylko przerwać pracę serwera testowego i skonfigurować go do normalnej pracy, np.:
systemctl enable strongswan systemctl start strongswan
Podsumowując
Nie jestem pewien, czy poradnik jest idealnie poprawny i czy wszystkie opcje zostały ustawione jak trzeba - niemniej, działa. Zapewnia dostęp zarówno do sieci zewnętrznej z wykorzystaniem mojego prywatnego łącza, jak również do zasobów sieci wewnętrznej, co jest równie ważne jak moja prywatność przy korzystaniu z otwartych sieci.