From: xf0r3m Date: Tue, 23 Jul 2024 12:51:12 +0000 (+0200) Subject: Napisano artykuł zgodnie ze zgłoszeniem - BT #181. Do przeredagowania. X-Git-Url: https://gitweb.morketsmerke.org/?a=commitdiff_plain;h=65b81f2146bad8d626d152705620d6241f7830ba;p=mmdev.git Napisano artykuł zgodnie ze zgłoszeniem - BT #181. Do przeredagowania. --- diff --git a/articles/tnt/lacznosc_miedzy_dwoma_lokalizacjami_przez_siec_komorkowa.html b/articles/tnt/lacznosc_miedzy_dwoma_lokalizacjami_przez_siec_komorkowa.html new file mode 100755 index 0000000..6b4161a --- /dev/null +++ b/articles/tnt/lacznosc_miedzy_dwoma_lokalizacjami_przez_siec_komorkowa.html @@ -0,0 +1,146 @@ + + + + + + + + +
+  _______            ___   ______     _      __
+ /_  __(_)___  _____( _ ) /_  __/____(_)____/ /_______
+  / / / / __ \/ ___/ __ \/|/ / / ___/ / ___/ //_/ ___/
+ / / / / /_/ (__  ) /_/  </ / / /  / / /__/ ,< (__  )
+/_/ /_/ .___/____/\____/\/_/ /_/  /_/\___/_/|_/____/
+     /_/
+
+ +

+ ☠ morketsmerke ☠ +

+
+

Łą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 bardziej + metoda, zapewniająca bardziej swobodną komunikację. Jest nią + sieć VPN. O sieci 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 robi 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 zamontowane 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 +

+
+

+ 2022; COPYLEFT; ALL RIGHTS REVERSED; +

+ +