Łączność miedzy dwiema lokalizacjami przez sieć komórkową
Wiemy jak upierdliwa jest łączność między dwiema lokalizacjami, które dostęp do Internetu realizują za pomocą sieci komórkowej. Ona w ogóle nie istnieje i trzeba kombinować. Jeśli potrzebujemy jednej konkretnej usługi, to tunel SSH może wystarczyć. Jednak jest lepsza metoda, zapewniająca bardziej swobodną komunikację. Jest nią sieć VPN. O sieciach VPN zrobiłem osobny materiał, link znajduje się w źródłach. Mimo, że od dawna wiedziałem, że mogłem zrealizować taką komunikację za pomocą sieci VPN, to źle zabierałem się do jej konfiguracji. Logicznie rzecz biorąc pierwszą rzeczą jaka przychodzi nam na myśl jest, biorąc pod uwagę dwie lokalizacje jest - łączenie ze sobą oddziałów firmy. No właśnie nie. Kilku krotnie podchodziłem do tematu - właśnie używając sposobów na łączenie ze sobą oddziałów firmy. Ostatnio zmieniłem strategię.
Otóz a co jeśli poszczególne hosty traktować jako klientów. Tylko problemem może być to, że klasyczne połączenie między klientem a serwerem tworzy wirtualną sieć od długości /30. Co daje nam całe dwa hosty: serwer vpn i klienta. Tak domyślnie działa oprogramowanie OpenVPN z którego korzystam. Nie mniej jednak znalazłem w dokumentacji (link w źródłach), że możemy zmienić tę funkcjonalność za pomocą opcji topology subnet i teraz zamiast obsługiwać pojedyncze połączenia tunel będzie obsługiwać całą sieć. Trzeba więc to przetestować. Stworzyłem na komputerze przy użyciu maszyn wirtualnych najbardziej zbliżoną infrastrukturę do tej rzeczywistej. I rozpocząłem konfigurację.
Na początku skonfigurowałem dwie bramki na Alpine Linux, aby strony połączenia znajdowały się za NAT-em, jak to jest w rzeczywistości. To bardzo prymitywna konfiguracja bez DHCP i DNS same interfejsy i NAT przez iptables. Następnie skonfigurowałem CA dla certyfikatów na tym samym serwerze co VPN, dla bezpieczeństwa lepiej tego nie robić, ale to tylko środowisko testowe. Konfiguracji doknałem zgodnie z 3 linkiem w źródłach. Już raz o tym pisałem, więc odsyłam. Po skonfigurowaniu CA wygenerowałem certyfikaty dla całej infrastruktury. Następnie zabrałem sie za konfigurację serwera. Tak o to wyglądał plik konfiguracyjny serwera VPN w środowisku testowym:
dev tun local 192.168.97.203 proto udp port 17003 user openvpn group openvpn ca cacert.pem cert servercrt.pem key serverkey.pem dh dh2048.pem topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-config-dir ccd keepalive 10 120 comp-lzo
Testowo uruchomiłem OpenVPN i serwer zrucił błąd za małego klucza DH trzeba było wygenerować nowy, dłuższy, poźniej zapomniałem o użytkowniku. Ale koniec, końców udało się go podnieść i mamy w naszym systemie interfejs tun0 o adresie 10.8.0.1.
Następnie przyszedł czas na konfigurację klientów, ich konfiguracja nie wymaga zbyt wiele wysiłku. Ja przepisałem ją z mojego wcześniejszego materiału (4 link w źródłach). Certyfikaty zgrane, OpenVPN skonfigurowany, tunele zestawione i oto nadchodzi wielka chwila prawdy. Test pingiem między jedną stroną a drugą. Uruchamiam polecenie i... Ciemnosc i nie ma połączenia ;(.
Pingi do serwera VPN idą bez problemu, a między hostami nie. Nie wiem dlaczego ale stwierdziłem, że jest coś nie tak z serwerem. Jego zadaniem jest przekazać... No właśnie przekazać pakiety z jednego interfejsu na ten sam, ale muszą one zostać przetworzone. Bez przekazywania, serwer tylko sprawdzić czy ten pakiet jest do niego. Jeśli nie, to go odrzuci. Włączyłem zatem przekazywanie pakietów IPv4.
$ sudo sysctl net.ipv4.ip_forward=1
I ponownie testuje i jakaż euforia mnie opanowała, kiedy jedna strona z drugą stroną zaczęły sie komunikować za pośrednictwem tunelu VPN.
Rozwiązanie wdrożyłem na produkcji, z jednej stronym mam różowego operatora a z drugiej zielonego. I tutaj pro-tip. Nie korzystajcie dostarczonego pliku jednostki systemd, OpenVPN. Skopiujcie jego zawartość do powiedzmy: openvpn-local.service i ten plik włączcie. Unikniecie problemów ze startem tunelu podczas bootowania - np. za którymś uruchomieniem zamiast jednego interfejsu tun0 będą dwa z tym samym adresem (tun0 i tun1). Samo rozwiązanie działa zadawaląco pozwala nawet odtworzyć większy plik wideo za pomocą programu VLC z udziału zamontowanego po przez NFS.
Ten artykuł został wydany bardziej w formie felietonu, a niżeli takich typowych materiałów przedstawiających tutoriale, aczkolwiek musiał powstać, aby nie przepadło to doświadczenie, jakiego nabrałem podczas konfigurowania zarówno środowiska testowego jak i produkcyjnego.
Źródło:
~xf0r3m