Autor poniższego rozwiązania użytkuje bardzo chętnie portal Netflix, jednakże mieszkając w Kanadzie ma ograniczoną możliwość oglądania tam filmów, w związku z czym korzystał z VPNa na terenie USA. Niedawno nabył Chromecasta, co znacznie ułatwiło mu oglądanie materiałów strumeniowanych w sieci na TV, ale niestety urządzenia tego nie można podłączyć do VPNa, a jedynie do lokalnej sieci WiFi. Jako że autor miał już uruchomiony serwer na Raspberry Pi zdecydował się na wykorzystanie RPi do przekierowania ruchu sieciowego z Chromecasta poprzez zewnętrzny VPN.
Projekt ten miał w sobie szereg wyzwań, jednakże najpoważniejszym z nich był fakt, że RPi musi funkcjonować nadal jako serwer. W sieci autora zajmuje się on obsługą nadchodzącej poczty e-mail, synchronizacją plików z syncthing i kilkoma innymi zadaniami. Oznacza to, że RPi musi być dostępne z sieci LAN i poprzez publiczne IP sieci, jednocześnie przekierowując część ruchu sieciowego poprzez VPN.
Powyżej pokazany jest schemat sieci domowej autora. Jak widać serwer na RPi egzystuje w trzech sieciach - LAN, VPN oraz we własnej sieci WiFi o SSID 'dietrich', która ma za zadanie przekierować ruch na VPN.
W rozwiązaniu zastosowano szereg elementów, które współpracują ze sobą:
Serwer OpenVPN z NAT i maskaradą sieci
Klient OpenVPN
Punkt dostępowy sieci WiFi
hostapd do obsługi zabezpieczeń sieci WiFiy
dnsmasq do obsługi DNSa i DHCP
iptables do maskarady sieci NAT
Tabele Routingu
Serwer OpenVPN
Serwer OpenVPN działa na VPS z RamNode na systemie Debian Jesse. OpenVPN zainstalować można można pod linuksem poprzez
apt-get install openvpn# autor wyedytował z pliku oryginalne komentarze
# ale warto je zostawić, bo są przydatne
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key # Ten plik musi pozostać tajny
dh keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
comp-lzoSerwer uruchamia demona w trybie serwerowym na określonej podsieci, co daje mu interfejs VPN an IP 10.8.0.1. Serwer konfiguruje klienta tak, że VPN skonfigurowany jest jako brama domyślna, co powoduje że ruch sieciowy kierowany jest poprzez VPN. Pozwala to na zapewnienie bezpiecznego połączenia poprzez publiczną, otwartą sieć WiFi. Na serwerze na RPi można to wyłączyć.
Maskarada i NAT
Jako że wykorzystana w rozwiązaniu jest maskarada sieci poprzez sieć publiczną skonfigurować trzeba IP forwarding i NAT w następujący sposób:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j MASQUERADEvenet0 jest publicznym interfejsem VPS. W typowym serwerze najczęściej byłoby to eth0, ta linijka umożliwia IP forwarding w jądrze, a druga z kolei wykorzystuje iptables do konfiguracji.
Uruchomienie tych komend spowoduje ustawienie tego do restartu, aby działało to przy każdym uruchomieniu serwera trzeba wpisać to w init systemu.
Klient OpenVPN
Na Raspberry działa system Raspbian, na którym musimy zainstalować musimy pakiet openvpn, poprzez apt-get.
Serwer generuje wszystkie klucze i certyfikaty, certyfikat dla tego klienta nazwany został client-pi.crt a klucz client-pi.key. Pliki te, wraz z ca.crt należy przenieść na Raspberry Pi do folderu /etc/openvpn/keys.
Plik /etc/openvpn/client.conf powinien wyglądać następująco:
client
route-nopull
proto udp
remote dietrich 1194 # wpisz tutaj swój własny serwer
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client-pi.crt
key /etc/openvpn/keys/client-pi.key
ns-cert-type server
comp-lzo # ro musi zgadzać się z serwerem
script-security 2
#up /etc/openvpn/routing.shPunkt Dostępowy WiFi
To rozwiązanie zostało zaadaptowane z opisu na elinux.org i tyczy się uruchamiania hotspota na RPi. Wprowadzono pewne zmiany, w szczególności dotyczące wykorzystania dnsmasq zamiast udhcpd do obsługi DNSów.
Najpierw uruchomić trzeba interfejs wlan0, dodajemy w /etc/network/interfaces:
iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0Nadaje to wlan0 adres statyczny. Należy się upewnić, że nasza podsieć jest inna, niż ta w jakiej jest LAN. U autora 192.168.0.0 to sieć domowa, więc jako sieć bezprzewodowa wybrano 192.168.1.0. Demony odpowiedzialne za działanie WiFi to hostapd i dnsmasq. Konieczna jest instalacja iptables -
apt-get install hostapd dnsmasq iptableshostapd
Aby skonfigurować hostapd plik /etc/hostapd/hostapd.conf musi zostać skonfigurowany następująco:
interface=wlan0
#driver=nl80211
ssid=Dietrich
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=ITSASECRET
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMPa w /etc/default/hostapd, ustawiamy DAEMON_CONF="/etc/hostapd/hostapd.conf".
Zależnie od karty sieciowej linijka "driver=" może być potrzebna w hostapd.conf. Google pomoże odpowiedzieć na pytanie, czy wykorzystana karta sieciowa tego wymaga czy można pozostawić tą linijkę zakomentowaną.
dnsmasq
Ostatnim krokiem konfiguracji punktu dostępowego jest odpowiednia obsługa zapytań DHCP od łączących się maszyn. Wybrano do tego celu dnsmasq, a nie udhcpd, jako że jest to bardzo mało zasobożerny pakier i obsługuje DHCP i DNSy przy bardzo prostej konfiguracji. Plik konfiguracyjny (/etc/dnsmasq.conf) wygląda następująco:
server=8.8.8.8
server=8.8.4.4
no-dhcp-interface=eth0
addn-hosts=/etc/hosts.dns
dhcp-range=192.168.1.50,192.168.1.75,12hJako serwer DNS wykorzystano publiczny serwer Google, gdyż serwer DNS ISP nie byłby dostępny poprzez VPN. DHCP na sieci przewodowej jest wyłączone i ma działać tylko poprzez WiFi. Z kolei addn-hosts odpowiedzialne jest na DNS dla juju i dostęp do serwera pocztowego.
maskarada iptables i NAT
Aby uruchomić maskaradę sieci poprzez NAT na interfejsie tun0 musimy zrobić dokładnie to samo, co na zdalnym serwerze, jednakże dla tun0, a nie venet0:
root@pi# echo 1 > /proc/sys/net/ipv4/ip_forward
root@pi# iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEOczywiście chcemy to robić za każdym bootowaniem systemu, więc piszemy skrypt (/etc/init.d/ip_forward):
#!/bin/bash
### BEGIN INIT INFO
# Provides: ip_forward
# Required-Start: $remote_fs $syslog $network $openvpn
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
I uruchamiamy go poprzez:
update-rc.d ip_forward enableJeśli routing VPNu to wszystko co ma robić RPi to właśnie skończyliśmy konfigurację sieci.
Tabele routingu
To była najtrudniejsza dla autora część pracy. Na poniższym obrazku widać strukturę sieci, wraz z adresami IP.
Musimy skonfigurować dwie niezależne tabele routingu, pracujące równolegle. Jednak dla sieci lokalnej, a druga dla sieci VPN/WiFi. Aby to zrobić edytować należy plik /etc/iproute2/rt_tables. Zawiera on w sobie kilka domyślnych tablic, których nie zmieniamy. Dodajmy jedynie dwie kolejne, o tak:
123 ether
124 vpn_hotspotNastępnie konfigurujemy routing czterema blokami kodu w /etc/openvpn/routing.sh, który wspominany jest wyżej w /etc/openvpn/client.conf.
Najpierw konfigurujemy główną tabele, tak aby host wiedział gdzie znajdują się poszczególne sieci. Każdy z wpisów po prostu łączy sieć do odpowiedniego interfejsu. Jedyną nieoczywista rzeczą na tym etapie jest adres 10.8.0.21, który nie jest adresem IP ani hosta VPN, ani interfejsu VPN. Jest to adres tun0 na RPi, jak ustawiono w jego ifconfig, dzięki czemu działa to jako brama dla VPNa.
# main routing table
ip route add 192.168.0.0/24 dev eth0 src 192.168.0.3
ip route add 10.8.0.0/16 dev tun0 src 10.8.0.22
ip route add 10.8.0.1 via 10.8.0.21
ip route add default via 192.168.0.1Następnie konfigurujemy sieć lokalną: wszystko z 192.168.0.3 (eth0) idzie przez sieć 192.168.0.0/24 a bramą domyślną tej tabeli (ether) jest 192.168.0.1.
# routes on local routing table
ip route add 192.168.0.0/24 dev eth0 src 192.168.0.3 table ether
ip route add default via 192.168.0.1 table etherTabel dla hotspota i VPNu wygląda następująco - tun0 idzie przez VPN z wlan0, a adres 10.8.0.21 jest domyślną bramą:
# routes on vpn/hotspot routing table
ip route add 10.8.0.0/16 dev tun0 src 10.8.0.22 table vpn_hotspot
ip route add 192.168.1.0/24 dev wlan0 src 192.168.1.1 table vpn_hotspot
ip route add default via 10.8.0.21 table vpn_hotspotFinalnie informujemy maszynę do której tabeli wysyłać ma ruch sieciowy z poszczególnych sieci:
# routing rules
ip rule add from 192.168.0.0/24 table ether
ip rule add from 10.8.0.0/16 table vpn_hotspot
ip rule add from 192.168.1.0/24 table vpn_hotspotWklejamy to wszystko w /etc/openvpn/routing.sh i odkomentowujemu /etc/openvpn/routing.sh w /etc/openvpn/client.conf. Nadajemy atrybuty uruchamialny, resetujemy openvpn i gotowe - wszystko działa. Teraz urządzenia podłączone do hotspota dietrich łączą się z siecią poprzez VPN. To doskonały sposób na ominięcie zabezpieczeń odnoszących się do lokalizacji geograficznej naszej maszyny.
Źródło:
http://bradmont.net/pi_router/
Fajne? Ranking DIY
