Temat: OpenVPN i sieci rutowane poradnik/przemyślenia (długie)
Postanowiłem podzielić się moimi doświadczeniami z rutowanymi sieciami i OpenVPN.
Konfiguracja nastepująca:
1. "Centrala" - sieć za DSL-em, stały publiczny adres IP.
Adresy prywatne podsieci za NAT-em - 192.168.200.0/24
Router VPN - dd-wrt, IP servera VPN: 10.0.0.1, podsieć VPN 10.0.0.0/24
2. Satelita nr 1 - sieć 192.168.201.0/24
Dostęp do internetu - modem HiLink, modowany, adres IP modemu
192.168.202.1, bez publicznie dostępnego adresu IP WAN.
CN klienta VPN: Sat1
3. Satelita nr 2 - sieć 192.168.203.0/24
Dostęp do internetu - modem HiLink, modowany, adres IP modemu
192.168.204.1, bez publicznie dostępnego adresu IP WAN.
CN klienta VPN: Sat2
4. Komputery klientów VPN - CN odpowiednio Komp1 i Komp2, łaczą się z VPN
poprzez kienta zainstalowanego bezpośrednio na tych komputerach.
Obydwa satelity pracują za routerem TP-Link 3420 z Gargoyle, extroot na pendrivie, hub aktywny z dobrym zasilaczem, też modowany - przecięta ścieżka łącząca +5V zasilania z +5V kabla USB idącego do modemu.
Aby uzyskać połączenie z urządzeniami w sieci satelickiej, kombinowałem początkowo z przekierowaniami portów VPN->LAN, (o tu: http://eko.one.pl/forum/viewtopic.php?p … 01#p154901), ale doszedłem do wniosku, że zdecydowanie lepszym rozwiązaniem będzie zrobienie jednej dużej rutowanej sieci w której z każdego urządzenia w sieci będę miał dostęp do dowolnego innego urządzenia bez względu na jego lokalizację.
Dokumentacja OpenVPN podaje, że aby uzyskać łącznośc pomiędzy klientami należy ustawić w konfiguracji serwera opcję
client-to-client. Filozofia OpenVPN jest taka, że ma ona swoją wewnętrzną tabelę routingu, odpowiedzialną za trasowanie ruchu do pomiędzy podsiecią VPN a innymi podsieciami.
Po bojach i poszukiwaniach w necie doszedłem do wniosku, że lepszym rozwiązaniem jest - paradoksalnie - wyłączenie opcji
client-to-client i rozwiązanie trasowania poprzez konfigurację trasowania w tablicach routingu routerów VPN. Daje to większą kontrolę i elastycznośc konfiguracji.
Po kolei:
1. Na wszystkich routerach włączamy forwardowanie pakietów VPN<->LAN
2. Na serwerze OpenVPN dodajemy w pliku konfiguracyjnym serwera VPN wpisy:
topology subnet
route 192.168.201.0 255.255.255.0 10.0.0.1 # LAN Satelita 1
route 192.168.202.0 255.255.255.0 10.0.0.1 # WAN Satelita 1
route 192.168.203.0 255.255.255.0 10.0.0.1 # LAN Satelita 2
route 192.168.204.0 255.255.255.0 10.0.0.1 # WAN Satelita 2
push "route 192.168.200.0 255.255.255.0" # LAN Centrala
push "route 192.168.201.0 255.255.255.0" # LAN Satelita 1
push "route 192.168.202.0 255.255.255.0" # WAN Satelita 1
push "route 192.168.203.0 255.255.255.0" # LAN Satelita 2
push "route 192.168.204.0 255.255.255.0" # WAN Satelita 2linie "route..." informują router (serwer) VPN, że trasa do podsieci 192.168.201.0 i kolejnych wiedzie poprzez tunel VPN.
Linie "push route ..." informują klientów VPN, że trasa do podsieci 192.168.200.0, 192.168.201.0 i kolejnych wiedzie poprzez tunel VPN.
3. W konfiguracji serwera OpenVPN dodajemy wpis:
client-config-dir /sciezka/do/konfiguracji/openvpn/ccdKatalog ccd będzie zawierał pliki konfiguracyjne specyficzne dla każdego klienta OpenvPN.
4. W katalogu ccd umieszczamy pliki Sat1, Sat2, Komp1 i Komp2 (nazwy plików są takie, jak CN klienta VPN):
Sat1:
ifconfig-push 10.0.0.2 255.255.255.0
iroute 192.168.201.0 255.255.255.0
iroute 192.168.202.0 255.255.255.0Sat2:
ifconfig-push 10.0.0.3 255.255.255.0
iroute 192.168.203.0 255.255.255.0
iroute 192.168.204.0 255.255.255.0Komp1:
ifconfig-push 10.0.0.4 255.255.255.0Komp2:
ifconfig-push 10.0.0.5 255.255.255.0Linie "ifconfig push.." przydzielają każdemu klientowi adres IP z podsieci VPN.
Linie "iroute.." dotyczą wewnętrznego routingu VPN (internal route) i informują serwer VPN, że klient Sat1 o adresie VPN 10.0.0.2 ma za sobą 2 podsieci:
192.168.201.0/24 i 192.168.202.0/24
i odpowiednio dla klienta Sat2 - podsieci 192.168.203.0/24 i 192.168.204.0/24
Tabela routingu serwera openVPN po uruchomieniu demona VPN:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 vlan2
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.200.0 0.0.0.0 255.255.255.0 UG 0 0 0 br0
192.168.201.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun2
192.168.202.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun2
192.168.203.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun2
192.168.204.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun2Czyli serwer wie, że trasa do podsieci 192.168.201.0 i kolejnych wiedzie poprzez tunel VPN (interfejs tun2)
Przy takiej konfiguracji tabela routingu na kliencie Komp1 przed zestawieniem tunelu VPN do serwera wygląda następująco:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.101.254 0.0.0.0 UG 0 0 0 wlan18
192.168.101.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan18192.168.101.0/24 to sieć, w której w tym momencie jest Komp1. Brama w tej sieci ma adres 192.168.101.254 i przez nią jest kierowany cały ruch na zewnątrz.
Po zestawieniu tunelu VPN tabela routingu wygląda następująco:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.101.254 0.0.0.0 UG 0 0 0 wlan18
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
w.x.y.z 192.168.101.254 255.255.255.255 UGH 0 0 0 wlan18
192.168.200.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun0
192.168.201.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun0
192.168.202.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun0
192.168.203.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun0
192.168.204.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun0
192.168.101.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan18Widać wyraźnie, że:
- trasa do w.x.y.z to trasa do publicznego IP serwera VPN
- trasa do podsieci VPN 10.0.0.0 wiedzie poprzez interfejs tun0 czyli tunel
VPN jest aktywny
- trasa do podsieci 192.168.200.0 i kolejnych wiedzie poprzez adres IP serwera
VPN z puli wirtualnych adresów podsieci VPN
- ruch lokalny (do podsieci 192.168.101.0) pozostał bez zmian
- cały pozostały ruch pozostał bez zmian, czyli przez bramę 192.168.101.254
Tada !!!! 
Wszystkie urządzenia w sieci widzą siebie nawzajem, każdy może pingować każdego.
Teraz czas na ograniczenia dostępu 
Prostota tego rozwiązania polega na tym, że całą konfigurację od tego momentu przeprowadzamy na serwerze OpenVPN, poprzez modyfikację reguł firewalla.
# Zezwalamy na cały ruch już wcześniej zainicjowany
# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
#Chcemy, aby Komp2 nie miał dostępu do podsieci Sat2:
# iptables -A FORWARD -s 10.0.0.5 -d 192.168.203.0/24 -j DROP
# iptables -A FORWARD -s 10.0.0.5 -d 192.168.204.0/24 -j DROP
#Chcemy, aby Komp1 miał pełen dostęp do wszystkiego:
# iptables -A FORWARD -s 10.0.0.4 -d 192.168.0.0/16 -j ACCEPT
# iptables -A FORWARD -s 192.168.0.0/16 -d 10.0.0.4 -m conntrack --ctstate NEW -j ACCEPT
#Wszyscy z podsieci Sat1 mają dostęp do Sat2 ale tylko wtedy gdy sami zainicjują połączenie:
# iptables -A FORWARD -s 192.168.201.0/24 -d 192.168.203.0/24 -m conntrack --ctstate NEW -j ACCEPT
# iptables -A FORWARD -s 192.168.201.0/24 -d 192.168.204.0/24 -m conntrack --ctstate NEW -j ACCEPT
#Blokujemy cały pozostały ruch:
# iptables -A FORWARD -j DROP Mam nadzieję, że ułatwi to niektórym konfigurację VPN.
Pozdrawiam
Gimbus109