Motywacją do napisania niniejszej pracy było udokumentowanie, zbudowanej przez autora sieci satelitarnej oraz przedstawienie łączności satelitarnej jako dziedziny teleinformatyki. Praca zawiera praktyczne przykłady oraz symulacje takiej sieci gdyż wynajęcie pasma satelitarnego tylko i wyłącznie na potrzeby pomiarów i testów jest wysoko nieopłacalne. Łączność satelitarna w dzisiejszych czasach jest wykorzystywana głównie jako łącze zapasowe lub przeznaczone do dedykowanych transmisji, dlatego projekt sieci przestawionej w pracy skupia się głównie na jej specyfice działania oraz konfiguracji urządzeń do zastosowania w takich sieciach.

Treść pracy jest podzielona na sekcje tematyczne. W pierwszej sekcji są omówione podstawy łączności satelitarnej. Następnie w kolejnych dwóch sekcjach są omówione technologie zastosowane do wykonania sieci, pomiarów oraz symulacji. Wszystkie kolejne sekcje natomiast dotyczą specyfiki działania, projektu oraz rozwiązań technicznych zastosowanych w pracy. W ostatnich sekcjach pracy zostały przedstawione możliwości rozbudowy lub przyszłościowych zmian przedstawionej sieci.

Wszystkie opisy w tej pracy dotyczą satelit komunikacyjnych, żaden z opisów oraz żadna instalacja lub konfiguracja w pracy nie odnosi się do satelit pozycjonowania lub obrazowania. Tyczy się to samo prezentowanych anten oraz terminali one również dotyczą teleinformatycznych sieci satelitarnych, a nie sieci do transmisji telewizji lub sygnałów audiowizualnych, przeznaczonych do odbioru za pomocą dekoderów telewizji satelitarnej.

Antena satelitarna, Raisting Niemcy. CC BY-SA 2.5
Źródło: https://pl.wikipedia.org/wiki/Plik:Erdfunkstelle_Raisting_2.jpg

Antena satelitarna to niezbędna część traktu satelitarnego, bez której nie może działać ani część nadawcza jak i również część odbiorcza. Jest to element służący do nadawania lub odbioru sygnału radiowego, najczęściej z satelitów telekomunikacyjnych. Stosowane często w gospodarstwach domowych do odbioru telewizji satelitarnej.

Na powyższym rysunku 1 przedstawiono antenę satelitarną (średnicy 28.5m) stosowaną w transmisji przez europejskie teleporty. Ateny takie w dzisiejszych czasach są już rzadko stosowane gdyż technologia półprzewodnikowa umożliwiła budowę wzmacniaczy wysokiej mocy przy optymalizacji kosztów takiego wzmacniacza. W nowych instalacjach stosuje się maksymalnie anteny o średnicy nie większej niż 10 metrów.

Wygląd anteny wynika z tego że przy częstotliwościach EHF (30-300 GHz), zjawiska falowe uwidaczniają się zdecydowanie bardziej niż przy niższych częstotliwościach. Atena satelitarna przypomina zdecydowanie bardziej swoim działaniem zwierciadło paraboliczne niż klasyczną antenę bazującą na zasadzie dipola pół falowego. Konsekwencją tego jest również to że możemy w łatwy sposób obliczyć zysk takiej anteny.

$$G = \frac{4 \pi A}{\lambda^2}e_A = (\frac{\pi d}{\lambda})^2 e_A \label{eq:antenna_gain}$$

• $A$: pole powierzchni apertury anteny. Rozmiar otworu przez który przechodzą fale elektromagnetyczne.
• $d$: Średnica anteny jeżeli antena jest okrągła.
• $\lambda$: Długość fali elektromagnetycznej.
• $e_A$: Parametr wydajności apertury, pomiędzy 0 a 1.

Z tego wzoru możemy wywnioskować że im większa średnica anteny tym większy jej zysk. Dlatego w starszych instalacjach z lat 90 stosowano bardzo duże anteny, ponieważ wzmacniacze dużych mocy na wysokie pasmo były bardzo nie wydajane energetycznie oraz kosztowo.

Makieta ERS 2 – sztucznego satelity Ziemi

Sztuczny satelita ziemski to każdy obiekt wykonany przez człowieka który porusza się po pewnej orbicie wokół ziemi. Pierwszym tego rodzaju obiektem był Sputnik 1, wystrzelony na orbitę przez ZSRR w 1957 roku. W tym rozdziale są opisane główne części które są odpowiedzialne za działanie takiego satelity. Poniższe sekcje skupiają się głównie na kwestiach elektroniki oraz teleinformatyki, kwestie mechaniczne są omówione mniej obszernie.

Każdy z satelit stworzonych przez ludzi, nie miał dostatecznie dużo czasu (Miliardów lat) żeby ustabilizować swoją orbitę, więc potrzebuje on kompensacji, która pozwoli mu utrzymać się na jego wyznaczonej pozycji. Pozycje satelitów geostacjonarnych są oznaczane ze względu na odchylenie na wschód oraz na zachód od południka zerowego. Na przykład satelita wysunięty nad równikiem na wschód o 7 stopni od południka zerowego będzie nazwany “E7”, w dzisiejszych czasach z racji dużej zajętości pozycji czasami wysyła się kilka satelit na jedną pozycję powoduje to wtedy że nazewnictwo wygląda np. “E7A”, “E7B”, “E7C”.

Sama kompensacja pozycji satelity jest realizowana poprzez silniki odrzutowe, wyrzucają one mieszankę gazu która pozwala kompensować ruchy około orbitalne satelity. Ilość paliwa jest zwykle ograniczona co powoduje że satelity mają ograniczoną żywotność np. satelita Eutelsat 7B wysłany na obitę w 2013 roku jest przeznaczony do działania około 15 lat, co oznacza że w roku 2028 prawdopodobnie skończy mu się paliwo do przeprowadzania kompensacji. Rozwiązaniem w takich sytuacjach jest zastosowanie anteny nadawczo-odbiorczych z śledzeniem satelity, pozwala to wtedy na wykorzystanie satelity jeszcze przez kilka lat po zakończeniu się jego daty przydatności.

Schemat przykładowego transpondera

Transponder satelitarny to kluczowy element systemów komunikacyjnych, odpowiedzialny za odbieranie, wzmacnianie i retransmisję sygnałów. Jego budowa obejmuje kilka kluczowych komponentów:

• Antena odbiorcza: Odbiera sygnały z Ziemi.
• Wzmacniacz nisko-szumowy (LNA): Wzmacnia słabe sygnały, aby zredukować szumy i zwiększyć ich moc.
• Przetwornik częstotliwościowy (i lokalny oscylator): Konwertuje częstość odbieranego sygnału na inną częstość, wymagającą do nadawania.
• Filtr przejściowy (BPF): Odrzuca niepożądane częstotliwości, pozwalając tylko na przejście oczekiwanego sygnału.
• Przed wzmacniacz radiowy: Dalsze zwiększanie mocy sygnału przed jego nadawaniem.
• Wzmacniacz radiowy wysokiej mocy (HPA): Ostatecznie wzmacnia sygnał do poziomu, który może być skutecznie retransmitowany z powrotem na Ziemię.
• Antena nadawcza: Emisja sygnału w kierunku stacji odbiorczej na Ziemi.

Pasmo L jest szeroko stosowane w systemach nawigacji satelitarnej, takich jak GPS. Dzięki dużej odporności na zakłócenia, jest idealne do stosowania w urządzeniach mobilnych i pojazdach, zapewniając precyzyjne określenie pozycji.

Pasmo S znajduje zastosowanie głównie w radarach oraz komunikacji w meteorologii. Umożliwia monitorowanie warunków atmosferycznych i istnienie systemów satelitarnych, które przesyłają dane o klimacie.

Pasmo C jest wykorzystywane w telewizji satelitarnej, a także w komercyjnych usługach telekomunikacyjnych. Dzięki swojemu zasięgowi, umożliwia transmisję sygnału do szerokiej gamy odbiorców.

Pasmo X ma zastosowanie głównie w komunikacji wojskowej. Używane jest w systemach radarowych oraz do przesyłu danych w trudnych warunkach atmosferycznych, co czyni je niezbędnym w operacjach wojskowych.

Pasmo Ku jest popularne w transponderach telewizyjnych oraz usługach Internetu satelitarnego. Oferuje wysoką jakość odbioru, co czyni je idealnym dla transmisji wideo i danych.

Pasmo Ka jest wykorzystywane do stosunkowo nowych, wysokoprzepustowych usług, takich jak telekomunikacja mobilna. Jego zdolność do przesyłania dużych ilości danych czyni je atrakcyjnym dla innowacyjnych aplikacji internetowych.

asmo V jest używane w eksperymentalnych technologiach i badaniach naukowych. Dzięki wysokim częstotliwościom, pozwala na nowe aplikacje w telekomunikacji oraz przesyłaniu danych.

Schemat ideowy orbit satelit komunikacyjnych

Satelity na orbicie niskiej (LEO - Low Earth Orbit) znajdują się na wysokości od 160 do 2000 km nad powierzchnią Ziemi. Dzięki bliskości do Ziemi, satelity LEO charakteryzują się niskim opóźnieniem sygnału oraz większą rozdzielczością obrazów. Są powszechnie wykorzystywane w telekomunikacji, obserwacji ziemi oraz w misjach badawczych.

Satelity na orbicie średniej (MEO - Medium Earth Orbit) znajdują się na wysokości od 2000 km do 35 786 km. Typowym przykładem są satelity systemów nawigacyjnych, takich jak GPS, Glonass, czy Galileo, które działają na wysokości około 20 200 km. Satelity MEO oferują kompromis pomiędzy zasięgiem a czasem reakcji.

Satelity na geostacjonarnej orbicie (GEO - Geostationary Orbit) znajdują się na wysokości 35 786 km, co pozwala im pozostawać w stałej pozycji względem Ziemi. Oznacza to, że orbitują z prędkością obrotu Ziemi. Satelity GEO są idealne do telekomunikacji, meteorologii i transmitowania sygnałów telewizyjnych, ponieważ oferują szeroki zasięg oraz stabilność sygnału.

Sygnał satelitarny pokrywa obszary planety za pomocą różnych metod transmisji, co pozwala na dostarczanie usług telekomunikacyjnych i danych na dużą skalę.

• Mapa odbiorcza: Przedstawia zasięg, w jakim sygnał z satelity może być odbierany na powierzchni Ziemi. W przypadku Eutelsat 7B, sygnał pokrywa znaczną część Europy, Bliskiego Wschodu oraz części Afryki

Mapa nadawcza (z ziemi) satelity Eutelsat 7B
Źródło: https://www.eutelsat.com/satellite-network/GEO-fleet/eutelsat-7-east

• Mapa nadawcza: Ukazuje zasięg obszarów, z których sygnał może być wysyłany do satelity. W przypadku Eutelsat 7B, użytkownicy muszą znajdować się w odpowiednich strefach, aby skutecznie korzystać z usług nadawczych.

Pokrycie sygnałem satelitarnym jest kluczowe dla zapewnienia szerokopasmowego dostępu do internetu, transmisji telewizyjnej oraz komunikacji w trudno dostępnych regionach, gdzie infrastruktura lądowa nie jest rozwinięta.

W poniższej sekcji zostały w skrócie opisane technologie satelitarne wykorzystane do budowy sieci obsługującej terminale satelitarne. Sieć słuzy do transmisji danych IP oraz jest wykorzystywana do łączności zapasowej lub jako główne łącze internetowe w lokalizacjach w których, nie ma dostępnych łącz przewodowych lub łącz radiowych np. 4G/LTE.

Z racji popularności i łatwości implementacji w pracy została zastosowana łączność geostacjonarna. Symulacje i inne tym podobne konfiguracje były wykonywane z myślą o paśmie Ku. Pasmo Ku jest najczęściej wykorzystywanym pasem do transmisji danych IP w sieciach satelitarnych, oraz jest szeroko wspierane przez różne platformy satelitarne m.in. iDirect.

Schemat sieci satelitarnej na bazie platformy iDirect

W realizacji projektu sieci wykorzystano platformę satelitarną iDirect. W poniższym porównaniu wykorzystano pojęcie przeskoku satelitarnego. Przeskok satelitarny to przesłanie sygnału z miejsca nadawania i następnie odebranie go w miejscu odbioru, w poniższym porównaniu wykorzystano pojęcie pojedynczego skoku oraz podwójnego skoku. Poniżej wyjaśnienie tych pojęć.

Pojedynczy skok satelitarny następuje w momencie w którym, nadawany sygnał jest przetwarzany tylko raz przez satelitę. Czyli na przykład w sytuacji w której dwa terminale komunikują się razem poprzez pasmo satelitarne. Sygnał jest najpierw nadawany przez jeden terminal potem odbierany przez drugi.

Podwójny skok satelitarny następuje w momencie w którym sygnał jest przetwarzany przez satelitę podwójnie. Kiedy np. terminal chce dostać się do internetu i musi przejść przez punkt główny czyli huba. Terminal wykonuje polecenie ping 8.8.8.8, pakiet najpierw jest przesyłany do huba, hub następnie rozkodowuje pakiet satelitarny i przesyła go na adres docelowy 8.8.8.8, czeka na odpowiedź ECHO REPLY w momencie otrzymania odpowiedzi, zakodowuje ją w pakiet satelitarny, wysyła na satelitę i następnie terminal go otrzymuje. W taki sposób zachodzi tzw. podwójny skok.

Platforma iDirect pozwala na realizację sieci satelitarnych w poniższych trybach konfiguracji:

• Topologia gwiazdy lub siatki
  • Pozwala na połączenie każdego terminala z każdym (po podwójnym przeskoku)
  • Dodatkowo pozwala na definiowanie połączeń między terminalami (po pojedynczym przeskoku)
• Topologia gwiazdy
  • Pozwala na połączenie każdego terminala z każdym (po podwójnym przeskoku)
  • Nie pozwala na połączenia siatkowe między terminalami (bez podwójnego skoku)
• Topologia połączeń bezpośrednich
  • Pozwala tylko i wyłącznie na połączenia bezpośrednie między dwoma lub więcej terminalami satelitarnymi na dedykowanym, przeznaczonym tylko i wyłącznie do tego paśmie tzw. jeden kanał na nośną (eng. SCPC single channel per carrier)

W tej pracy sieć oraz platforma satelitarna były skonfigurowane pod działanie sieci w trybie “Topologia gwiazdy”. Konsekwencją tego jest to że cały ruch sieciowy jaki zachodzi, między terminalami albo do internetu musi przejść przez punkt centralny (tzw. hub).

Podczas testów przed uruchomieniem sieci satelitarnej, trzeba przeprowadzić testy funkcjonalne. Z racji tego że pasmo satelitarne jest usługą o wysokiej cenie, powoduje to szukanie i opracowywanie rozwiązań które pozwalają przetestować działanie sieci bez pasma satelitarnego. Na rysunku 8 możemy zaobserwować, porównanie tego jakie są najważniejsze komponenty prawdziwej sieci satelitarnej, oraz jak możemy to uprościć w celu przetestowania sieci bez pasma satelitarnego.

Schemat symulacji pętli TXRX oraz porównanie z realną instalacją

Sieć satelitarna podczas zastosowania prawdziwego pasma satelitarnego wymaga od nas zastosowania pełnych traktów odbiorczych i nadawczych dla strony terminala jak i również huba. Trakt nadawczy powinien być również redundantny, więc potrzebujemy zastosować podwójnie sprzęt nadawczy i odbiorczy po stronie huba.

Natomiast przy testach funkcjonalnych wystarczy zastosować dzielniki do których możemy podłączyć stronę nadawczą i odbiorczą terminali, i po uprzednim stłumieniu sygnału do odpowiedniego poziomu, możemy tak przygotowane sygnały podłączyć do terminali. Pozwoli to na podłączenie i uwierzytelnienie się w sieci satelitarnej bez uprzedniego wynajmowania pasma satelitarnego.

Testy wykonane w taki sposób nie pozwalają na zbadanie opóźnienia i ograniczeń pasma wynikających z pasma satelitarnego. Dlatego w następnym rozdziale przedstawiono metodę badania i symulacji takich warunków za pomocą otwarto źródłowego oprogramowania.

Pasmo satelitarne jest usługą która jest stosunkowo droga. Powoduje to że w niektórych analizach może być potrzebne symulowanie warunków takiej sieci. W poprzednich sekcjach przedstawiono jak za-symulować sieć satelitarną na platformie satelitarnej, natomiast takie symulacje nie mają odpowiedniego ograniczenia pasma, ani również opóźnienia. Tutaj natomiast skupiamy się na symulacji opóźnień oraz ograniczeń pasma.

Narzędzie Traffic Control (TC) w systemie Linux jest kluczowe w zarządzaniu ruchem sieciowym, pozwalając na emulację różnych warunków sieciowych, takich jak opóźnienia czy ograniczenia pasma. Dzięki TC można precyzyjnie kontrolować, jak dane przepływają przez sieć, co jest niezbędne do skutecznej symulacji zachowań łącza satelitarnego.

Aby przeprowadzić symulację, konieczne było skonfigurowanie odpowiedniego środowiska testowego. Na poniższej ilustracji przedstawiono schemat maszyn wirtualnych, które zostały użyte do symulacji.

Schemat maszyn wirtualnych zastosowanych do symulacji

Tabela konfiguracji sieci

W konfiguracji sieci opisanej w Tabeli 1 użyto maszyn z wieloma interfejsami, co pozwoliło na testowanie różnych scenariuszy.

Na maszynie głównej (ubuntu-tc) włączono forwarding dla IPv4, co pozwoliło na przesyłanie ruchu między interfejsami. Poniżej przedstawiono polecenia umożliwiające aktywację tej funkcji:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

Następnie należało zrestartować interfejsy sieciowe, a także skopiować i uruchomić narzędzie TC GUI:

sudo apt install git
    git clone https://github.com/tum-lkn/tcgui
    cd tcgui
    sudo python3 main.py --ip 127.0.0.1

W przeglądarce możemy otworzyć narzędzie do konfiguracji TC poprzez interfejs webowy pod url http://127.0.0.1:5000.

Interfejs webowy do sterowania narzędziem TC

Inne maszyny musiały zostać przygotowane poprzez zainstalowanie iperf3, co można zrealizować za pomocą następującego polecenia:

sudo apt-get update
    sudo apt-get install iperf3

Musimy je jeszcze zaadresować statycznie za pomocą GUI albo za pomocą netplan

Wyniki testów opóźnień, pasma UDP i TCP, oraz inne testy

Analizując wyniki testów przeprowadzonych w ramach symulacji, można zauważyć, że narzędzie Traffic Control (TC) wykazuje dużą precyzję w realizacji ustawionych parametrów. Oto kluczowe wnioski dotyczące jego dokładności i efektywności:

• Dokładność ustawień pasma: TC z powodzeniem ograniczało pasmo do zadanych wartości, co potwierdzają wyniki testów. Obserwowane wartości pasma były zbliżone do tych, które zostały skonfigurowane, co świadczy o efektywności narzędzia w zarządzaniu przesyłem danych.
• Emulacja opóźnień: Narzędzie TC precyzyjnie odwzorowuje dodane opóźnienia, które miały miejsce w rzeczywistych warunkach. Ustawione opóźnienia odpowiadały uzyskanym wartościom, co potwierdza jego zdolność do symulacji rzeczywistych warunków sieciowych.
• Straty pakietów: TC pozwoliło na kontrolowanie strat pakietów w różnych scenariuszach. Wyniki pokazują, że narzędzie skutecznie różnicowało sytuacje, w których występowały zyski oraz straty, co jest kluczowe dla analizy jakości łącza.
• Wydajność pod dużym obciążeniem: Pomimo dodanych ograniczeń pasma i opóźnień, TC nie potrafiło utrzymać względnie stabilnej wydajności, jeżeli chodzi o symulacje wymagające większej ilości parametrów. Co powoduje że lepiej symulować opóźnienie ale bez ograniczeń w transmisji.
• Praktyczne zastosowanie: Zważywszy na osiągnięte wyniki, narzędzie TC ujawnia swój potencjał w symulacji sieci o wysokim opóźnieniu i małej przepustowości, zwłaszcza w kontekście platform satelitarnych, gdzie optymalizacja ruchu sieciowego jest niezwykle istotna.

Podsumowując, Traffic Control (TC) okazało się skutecznym narzędziem do emulacji i zarządzania parametrami sieciowymi, z wysoką dokładnością w dostosowywaniu się do zadanych wartości. Jego wykorzystanie w analizach i symulacjach sieciowych może znacząco podnieść jakość oceny systemów komunikacyjnych.

W tej sekcji przedstawione zostaną kluczowe technologie sieciowe, które zostały wykorzystane w niniejszej pracy. Omówione zostaną zarówno urządzenia, jak i protokoły, które pozwalają na efektywne zarządzanie sieciami.

Urządzenia MikroTik to popularne rozwiązanie w zakresie sprzętu sieciowego, oferujące elastyczność i rozmaite możliwości konfiguracji. Charakteryzują się intuicyjnym interfejsem, co sprawia, że są idealne zarówno dla małych, jak i dużych sieci. MikroTik stosuje system RouterOS, który umożliwia zarządzanie ruchami, QoS, VPN oraz innymi funkcjami związanymi z bezpieczeństwem.

Protokół VRRP (Virtual Router Redundancy Protocol) służy do zwiększenia dostępności bramy sieciowej. W ramach VRRP kilka routerów współpracuje, aby zapewnić, że jeden z nich działa jako „wirtualny router”. Dzięki temu, w przypadku awarii jednego z routerów, pozostałe mogą przejąć odpowiedzialność, co minimalizuje przestoje sieci.

Protokół RIP (Routing Information Protocol) to jeden z najstarszych protokołów routingu dynamicznego, wykorzystujący algorytm wektora odległości. RIP umożliwia routerom wymianę informacji o trasach w sieci, co pozwala na dynamiczne dostosowanie tras w odpowiedzi na zmiany w topologii. Chociaż prosty w implementacji, jego zastosowanie jest ograniczone w dużych sieciach ze względu na maksymalną liczbę 15 przeskoków.

Co ważne, protokół RIP jest szczególnie wymagany do działania platform satelitarnych, ponieważ wciąż jest szeroko wykorzystywany w tych systemach.

Redundancja i przełączanie awaryjne są kluczowymi elementami w projektowaniu niezawodnych sieci IP. Poprzez zastosowanie VRRP, sieci mogą zapewnić ciągłość działania nawet w przypadku awarii komponentów. Właściwe planowanie i implementacja tych technologii są niezbędne dla utrzymania stabilności i dostępności usług sieciowych.

W tej sekcji przedstawiono zrealizowany projekt sieci satelitarnej przeznaczonej do obsługi ruchu sieciowego przetwarzanego przez platformę satelitarną iDirect. Sieć ta została zrealizowana oraz w momencie pisania tej pracy obsługuje kilka z terminali satelitarnych.

Platforma iDirect ma stosunkowo specyficzne wymagania co do sieci komputerowej jaka ma być zastosowana do obsługi ruchu sieciowego wytwarzanego przez terminale satelitarne. Aby przedstawić te wymagania musimy najpierw zapoznać się z najważniejszymi komponentami takiej sieci.

Serwer PP (ang. Protocol processor). Platforma satelitarna używa własnościowych protokołów które nie są kompatybilne z sieciami ogólnego przeznaczenia, aby ten ruch sieciowy mógł zostać poprawnie obsłużony przez sieci IP musi być najpierw rozkodowany do postaci pakietów IP, zadanie to należy do serwera PP który jest podłączony do takiej sieci poprzez dwa porty i na jednym z nich otrzymuje dane do rozkodowania i następnie przesyła je na drugi port, do sieci w której mogą te dane być przetworzone przez normalne routery IP. Ilość tych serwerów jest zależna od wielkości sieci.

Serwer NMS (ang. Network managment system). To jest serwer którego nie wpływa na działanie sieci ale jest kluczowym komponentem, zawiera on bazę danych w której przechowywane są informację na temat konfiguracji sieci oraz kart w systemie iDirect. Serwer ten zwykle instaluję się w dwóch egzemplarzach oraz ustawia się na nich replikację bazy danych, w celu zachowania redundancji.

Router krańcowy (ang. Edge). Jest to urządzenie które obsługuje ruch w całej sieci. Platforma iDirect wykorzystuję routing dynamiczny RIP do komunikacji z modemami satelitarnymi oraz wykorzystuje dwie sieci które oddzielają dane przed przetwarzaniem przez serwery PP oraz po przetwarzaniu przez serwery PP. Sieć która zawiera dane przed przetwarzaniem nazywa się “tunnel” a sieć po przetworzeniu danych nazywa się “upstream”.

Uproszczony schemat sieci komputerowej do obsługi platformy iDirect

Na uproszczonym rysunku 11 możemy zaobserwować jak wygląda rdzeń sieci komputerowej do obsługi platformy. Struktura infrastruktury serwerowej oraz sama platforma iDirect ma jedną sporą wadę nie pozwala w żaden łatwy sposób zrobić redundancji dla switcha przez który przechodzi cały ruch sieciowy, bez przełączania fizycznie połączeń między dwoma switchami. Wynika to z tego że w momencie podłączenia się do sieci satelitarnej modemy zostają przypisane do jednego z serwerów PP i nie można dynamicznie tego serwera zmienić po podłączeniu się do sieci.

Schemat pozwala natomiast na obserwację tego w jaki sposób komponenty są połączone w sieć. Serwer NMS jest podłączony do sieci upstream przechowuje on tylko konfigurację więc nie zmienia przepływu danych w sieci. Serwer PP jest podłączony dwoma portami do switcha, co oznacza że jest podłączony do sieci tunnel i jednocześnie do sieci upstream, podział tych sieci na switchu SW1 jest realizowany za pomocą sieci VLAN. Routery działają jako routery dostępowe do sieci internet. Od strony WAN są podłączone dwoma łączami do internetu oraz mają przydzielone dwa adresy publiczne oraz jeden wirtualny dla technologii VRRP.

Schemat konfiguracji switcha SW1

Schemat na rysunku 12 pokazuję konfigurację na switchu. Możemy tutaj zobserwować jasny podział na dwie sieci. Sieć tunnel która zawiera nie przetworzone dane satelitarne oraz sieć upstream która służy do obsługi zarządzania siecią oraz przetwarzania danych IP przetworzonych przez serwer PP.

Schemat przepływu danych z platformy satelitarnej do routerów

Schemat na rysunku 13 pokazuję jak dane satelitarne przepływają przez switcha. Proszę nie zapomnieć o tym że dane w sieciach komputerowych przepływają w obydwie strony, więc zaraz po przejściu pakietu zgodnie ze schematem musi się odbyć to samo tylko że w odwrotnej kolejności. Ukazuje nam to główną zasadę działania sieci iDirect, router krańcowy musi znać adresy wszystkich terminali satelitarnych w sieci tunnel ale nie może się do nich dostać przez tą sieć, musi korzystać z serwera PP aby się do nich dostać. Powoduje to że router musi znać wszystkie adresy modemów w sieci tunnel, zgłasza je do niego serwer PP za pomocą routingu dynamicznego. Pamiętajmy jeszcze o tym że każdy terminal satelitarny działa jak router więc ma swoją własną sieć którą zgłasza do klienta na porcie ethernetowym.

Schemat podziału sieci na terminalu satelitarnym

Na żadnym do tej pory wymienionym etapie nie następuje translacja adresów, więc wszystkie sieci muszą się ze sobą komunikować. Odczytując schemat z rysunku 14 możemy wywnioskować że router musi dowiadywać się o tym jak ma się dostać do części local network modemu. Dzieję się to poprzez już wcześniej wymieniony RIP który rozgłasza serwer PP, modemy satelitarne zgłaszają się do platformy, platforma informuje serwer PP że dana sieć kliencka jest dostępna przez dany adres tunnel modemu. Serwer PP następnie przesyła tą informację do routera krańcowego i dodaje wpis do tablicy routingu który pokazuje że do danej sieci local network możemy się dostać poprzez serwer PP (upstream), który z kolei przechowuje dane o tym za jakim adresem modemu (tunnel) znajduje się dana sieć kliencka.

Żeby bardziej rozjaśnić zasadę działania takiego przepływu danych, rozpatrzmy przykład transmisji pakietu w sieci gdzie terminal satelitarny wyśle pakiet ICMP. Poniżej spis adresów wykorzystanych do takiego przypadku.

1. 8.8.8.8 - przykładowy adres dostępny w internecie
2. 192.168.10.0/24 - podsieć dla VLANu upstream
3. 192.168.20.0/24 - podsieć dla VLANu tunnel
4. 192.168.10.1 - adres R1 w VLANie upstream
5. 192.168.20.1 - adres R1 w VLANie tunnel
6. 192.168.10.2 - adres R2 w VLANie upstream
7. 192.168.20.2 - adres R2 w VLANie tunnel
8. 192.168.10.3 - adres VRRP w VLANie upstream
9. 192.168.20.3 - adres VRRP w VLANie tunnel
10. 192.168.10.111 - interfejs serwera PP w VLANie upstream
11. 192.168.20.111 - interfejs serwera PP w VLANie tunnel
12. 172.16.32.0/24 - podsieć kliencka
13. 172.16.32.1 - adres local network modemu
14. 192.168.20.10 - adres tunnel ip modemu
15. 172.16.32.254 - adres klienta (np. komputera podłączonego do terminala satelitarnego)

Przeanalizujmy sytuację w której klient podłączony do terminala satelitarnego wysyła pakiet ICMP do adresu 8.8.8.8.

1. Komputer wysyła pakiet icmp na adres 8.8.8.8

   Adres żródłowy	Adres docelowy
   172.16.32.254	8.8.8.8

2. Modem odbiera ten pakiet, nie zna sieci docelowej więc przekazuje ten pakiet na swoją bramę czyli na serwer PP, 192.168.20.111.

   Adres żródłowy	Adres docelowy
   172.16.32.254	8.8.8.8

3. Serwer PP odbiera pakiet (w sieci tunnel) rozkodowuje go z pakietu satelitarnego na pakiet IP. Następnie sprawdza w tablicy routingu sieć docelową, nie zna jej więc przekazuje go na swoją bramę czyli adres VRRP (w sieci upstream) 192.168.10.3.

   Adres żródłowy	Adres docelowy
   172.16.32.254	8.8.8.8

4. Routery R1 i R2 odbierają pakiet (w sieci upstream) sprawdzają sieć docelową która jest w internecie, przekazują pakiet do swojej bramy w sieci publicznej maskując swój adres. W tym miejscu na potrzeby tej analizy pominiemy fragment przechodzenia pakietu przez sieć internet i przejdziemy od razu do etapu powrotu pakietu. Serwer 8.8.8.8 zwraca pakiet na adres publiczny routerów routery odbierają go i następnie podmieniają z powrotem adresy z tabeli połączeń przechodzących przez NAT.

   Adres żródłowy	Adres docelowy
   8.8.8.8	172.16.32.254

   Router w tabeli routingu RIP ma wpis (rozgłoszony przez serwer PP) który mówi że do sieci 172.16.32.0/24 ma dostać się przez serwer PP 192.168.10.111. Więc router przekazuje to z powrotem na serwer PP.

5. Serwer PP odbiera pakiet i zgodnie z tabelą routingu RIP ma trasę która pokazuje że do sieci 172.16.32.0/24 ma dostać się przez adres tunnel ip modemu 192.168.20.10.

   Adres żródłowy	Adres docelowy
   8.8.8.8	172.16.32.254

6. Modem otrzymuje pakiet i zgodnie z wspisem w tabli przekazuje go na sieć która jest do niego bezpośrednio podłączona.

   Adres żródłowy	Adres docelowy
   8.8.8.8	172.16.32.254

Powyżej wyjaśniony proces można zaobserwować na rysunku 15. Na wymionionym rysunku przedstawiono wszystkie urządzenia wymienione w procesie oraz umieszczono obok nich przypisy z odpowiednimi adresami w celu łatwiejszej wizualizacji tego procesu.

Schemat sieci satelitarnej wraz z adresacją.

W poprzednich sekcjach omówiliśmy specyfikę działania platformy oraz przepływ danych. W tej sekcji omówimy jak skonfigurować switch platformy iDirect tak żeby umożliwić jego działanie w sieci, służącej do obsługi tej platformy.

Poniżej analiza konfiguracji switcha na przykładzie platformy Cisco Catalyst. Wymieniono poszczególne etapy konfiguracji takiego urządzenia wykonane w trybie konfiguracji globalnej (przy uprzednim wykonaniu poleceń enable a nastepnie configure terminal)

1. Dodanie VLANów dla sieci upstream oraz tunnel.

vlan 10
name UPSTREAM
exit

vlan 20
name TUNNEL
exit

1. Ustawienie portów dla routerów R1 i R2.

interface GigabitEthernet1/0/1
description R1
switchport mode trunk
switchport trunk allowed vlan 10,20
switchport trunk encapsulation dot1q
exit

interface GigabitEthernet1/0/2
description R2
switchport mode trunk
switchport trunk allowed vlan 10,20
switchport trunk encapsulation dot1q
exit            

1. Przykład konfiguracji portów dla serwera NMS oraz PP

interface GigabitEthernet1/0/3
description NMS
switchport mode access
switchport access vlan 10
exit

interface GigabitEthernet1/0/4
description PP tunnel
switchport mode access
switchport access vlan 10
exit

interface GigabitEthernet1/0/5
description PP upstream
switchport mode access
switchport access vlan 20
exit

W poprzedniej sekcji omówiona została konfiguracja urządzenia warstwy drugiej, w tej sekcji omówimy konfigurację routera do obsługi platformy iDirect. Do wdrożenia tej sieci została wybrana platforma sprzętowa MikroTik bazująca na systemie RouterOS.

Poniżej analiza krok po kroku konfiguracji przeprowadzonej na routerach R1 oraz R2. Fragmenty konfiguracji nie różniące się pomiędzy routerami zostały wymienione tylko na przykładzie routera R1, natomiast fragmenty konfiguracji różniące się miedzy routerami zostały wymienione podwójnie z wyjaśnieniem różnic. Polecania zostały wykonane z standardowego terminala dostępnego w systemie RouterOS.

1. Zmiana nazw interfejsów.

   /interface ethernet
   set [ find default-name=ether1 ] name=ether1-WAN
   set [ find default-name=ether2 ] name=ether2-iDX

   Interfejs o nazwie ether1-WAN jest podłączony do sieci internet. Interfejs o nazwie ether2-iDX jest podłączony do switcha SW1

2. Dodanie wirtualnych interfejsów na porcie ether2-iDX do obsługi sieci VLAN.

/interface vlan
add interface=ether2-iDX name=VLAN10-Upstream vlan-id=10
add interface=ether2-iDX name=VLAN20-Tunnel vlan-id=20

1. Konfiguracja VRRP na interfejsach. Konfiguracja na routerze R1, który jest routerem głównym.

   /interface vrrp
   add group-authority=self interface=VLAN10-Upstream name=VRRP1-VLAN10-Upstream \
   priority=200 vrid=10
   add group-authority=VRRP1-VLAN10-Upstream interface=VLAN20-Tunnel name=\
   VRRP2-VLAN20-Tunnel priority=200 vrid=20
   add group-authority=VRRP1-VLAN10-Upstream interface=ether1-WAN name=VRRP3-WAN \
   priority=200 vrid=40

   Konfiguracja na routerze R2, który jest routerem zapasowym.

   /interface vrrp
   add group-authority=VRRP1-VLAN10-Upstream interface=VLAN10-Upstream name=VRRP1-VLAN10-Upstream \
   priority=100 vrid=10
   add group-authority=VRRP1-VLAN10-Upstream interface=VLAN20-Tunnel name=\
   VRRP2-VLAN20-Tunnel priority=100 vrid=20
   add group-authority=VRRP1-VLAN10-Upstream interface=ether1-WAN name=VRRP3-WAN \
   priority=100 vrid=40

   Wyżej wymieniona konfigurcja składa się z trzech interfejsów VRRP.

   • VRRP1-VLAN10-Upstream
   • VRRP2-VLAN20-Tunnel
   • VRRP3-WAN

   Każdy z tych interfejsów jest skonfigurowany tak że parametr group-authority to interfejs VRRP1-VLAN10-Upstream. Oznacza to że w przypadku kiedy urządzenia przestaną się ze sobą komunikować poprzez sieć upstream to VRRP automatycznie przełączy się na router zapasowy. Interfejs VRRP2-VLAN20-Tunnel nie był konieczny do skonfigurowania gdyż nie ma wymagania bramy dla sieci tunnel, nastomiast jest to przydatne podczas konfigurowania kart w hubie iDirect. Ostatni interfejs to VRRP3-WAN jest on wykorzystywany głównie do wychodzenia do internetu poprzez jeden wirtualny adres interfejsu VRRP i w przypadku przełączenia awaryjnego adres publiczny się nie zmienia.

2. Włączenie routingu dynamicznego RIP na routerze, na odpowiednich interfejsach.

/routing rip instance
add disabled=no name=rip-instance-1 routing-table=main
/routing rip interface-template
add disabled=no instance=rip-instance-1 interfaces=\
VRRP1-VLAN40-Upstream,VRRP2-VLAN50-Tunnel

1. Stworzenie list interfejsów oraz dodanie interfejsów do tych list.

   /interface list
   add name=WAN
   add name=LAN
   
   /interface list member
   add interface=ether1-WAN list=WAN
   add interface=VLAN10-Upstream list=LAN
   add interface=VLAN20-Tunnel list=LAN
   add interface=VRRP1-VLAN10-Upstream list=LAN
   add interface=VRRP2-VLAN20-Tunnel list=LAN
   add interface=VRRP3-WAN list=WAN
   add interface=ether2-iDX list=LAN

   Interfejsy zostały dodane do grup w poniższy sposób:
   WAN: ether1-WAN, VRRP3-WAN
   LAN: VRRP1-VLAN10-Upstream, VRRP2-VLAN20-Tunnel, ether2-iDX, VLAN10-Upstream, VLAN20-Upstream
   Interfejsy zostały przydzielone w ten sposób gdyż chcemy żeby wszystkie były rozpatrywane jako interfejsy od strony lokalnej lub od strony publicznej, w zasadach w firewallu, nie zależnie od tego czy są to interfejsy wirtualne czy fizyczne.

2. Zaadresowanie interfejsów Konfiguracja R1:

   /ip address
   add address=192.168.10.1/24 interface=VLAN10-Upstream network=192.168.10.0
   add address=192.168.20.1/24 interface=VLAN20-Tunnel network=192.168.20.1
   add address=192.168.10.3/24 interface=VRRP1-VLAN10-Upstream network=192.168.10.0
   add address=192.168.20.3/24 interface=VRRP2-VLAN20-Tunnel network=192.168.20.0
   add address=203.0.113.1/27 interface=ether1-WAN network=203.0.113.0
   add address=203.0.113.3/27 interface=VRRP4-WAN network=203.0.113.0

   Konfiguracja R2 to samo co powyżej oraz zmiany wymienione niżej:

   /ip address
   add address=192.168.10.2/24 interface=VLAN10-Upstream network=192.168.10.0
   add address=192.168.20.2/24 interface=VLAN20-Tunnel network=192.168.20.1
   add address=192.168.10.3/24 interface=VRRP1-VLAN10-Upstream network=192.168.10.0
   add address=192.168.20.3/24 interface=VRRP2-VLAN20-Tunnel network=192.168.20.0
   add address=203.0.113.2/27 interface=ether1-WAN network=203.0.113.0
   add address=203.0.113.3/27 interface=VRRP4-WAN network=203.0.113.0

   Tabela adresacji routerów

   Router	Interfejs	Adres
   R1	VLAN10-Upstream	192.168.10.1
   R1	VLAN20-Tunnel	192.168.20.1
   R1	VRRP1-VLAN10-Upstream	192.168.10.3
   R1	VRRP2-VLAN20-Tunnel	192.168.20.3
   R1	ether1-WAN	203.0.113.1
   R1	VRRP4-WAN	203.0.113.3
   R2	VLAN10-Upstream	192.168.10.2
   R2	VLAN20-Tunnel	192.168.20.2
   R2	VRRP1-VLAN10-Upstream	192.168.10.3
   R2	VRRP2-VLAN20-Tunnel	192.168.20.3
   R2	ether1-WAN	203.0.113.2
   R2	VRRP4-WAN	203.0.113.3

3. Włączenie funkcji przekazywania zapytań DNS Włączenie tej funkcji pozwala na ustawienie serwera DNS na adres routera, dla klientów. Router działa wtedy jak rekursywny DNS z własną pamięcią cache dla częstych zapytań oraz można zdefiniować własne statyczne wpisy DNS.

   /ip dns
   set allow-remote-requests=yes servers=8.8.8.8

4. Ustawienie zasad filtrowania na firewallu

   /ip firewall filter
   add action=accept chain=input comment="accept established,related" \
   connection-state=established,related
   add action=drop chain=input comment="drop invalid" connection-state=invalid
   add action=accept chain=input comment="accept icmp" protocol=icmp
   add action=drop chain=input comment="drop all not coming from lan" \
   in-interface-list=!LAN
   add action=accept chain=forward comment="accept in ipsec policy" \
   ipsec-policy=in,ipsec
   add action=accept chain=forward comment="accept out ipsec policy" \
   ipsec-policy=out,ipsec
   add action=fasttrack-connection chain=forward comment=fasttrack \
   connection-state=established,related hw-offload=yes
   add action=drop chain=forward comment="drop forward invalid" \
   connection-state=invalid
   add action=drop chain=forward comment="drop all from WAN not DSTNATed" \
   connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
   add action=accept chain=forward comment=\
   "accept established,related, untracked" connection-state=\
   established,related,untracked

   Poniżej wyjaśnienie poszczególnych zasad, w kolejności ich występowania listingu.

   • accept established,related - zasada pozwalająca na przepuszczenie pakietów które należą do połączeń które zostały już zestawione lub są kontynuowane.
   • drop invalid - zasada która odrzuca połączenie które mają stan połączenia jako invalid.
   • accept icmp - zasada pozwalająca na ruch ICMP kierowany do routera.
   • drop all not coming from lan - zasada blokująca cały ruch który ma źródło poza interfejsami na liście LAN a jest skierowany do routera.
   • accept in/out ipsec policy - dwie zasady które zgodnie z dokumentacją MikroTika powinny być zaimplementowane aby klienci którzy są podłączeni do sieci LAN routera mogli zestawiać tunele ipsec.
   • fasttrack - zasada która zgodnie z dokumentacją MikroTika ma odciążyć procesor routera dla pakietów które są już przypisane do istniejących połączeń.
   • drop forward invalid - zasada która ma nie pozwolić routerowi przekazać dalej pakietów których stan połączenia to invalid.
   • drop all from WAN not DSTNATed - zasada która ma odrzucić wszystkie nowe połączenia które nie zostały dodane do przekierowań portów (translacji adresów docelowych DNAT).

5. Konfiguracja translacji adresów źródłowych. Router został skonfigurowany tak że wszystkie pakiety wychodzące przez interfejsy na liście WAN, mają zamaskowany adres źródłowy publicznym adresem VRRP.

   /ip firewall nat
   add action=src-nat chain=srcnat log-prefix=NAT out-interface-list=WAN \
   to-addresses=203.0.113.3

6. Ustawienie trasy domyślnej. Adres 203.0.113.254 to adres bramy dla publicznej podsieci.

   /ip route
   add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
   203.0.113.254 routing-table=main scope=30 suppress-hw-offload=yes \
   target-scope=10

7. Konfiguracja usług, strefy czasowej, nazwy routera oraz NTP.

   /ip service
   set telnet disabled=yes
   set ftp disabled=yes
   set www disabled=yes
   set ssh address=192.168.0.0/16
   set api disabled=yes
   set api-ssl disabled=yes
   /system clock
   set time-zone-name=Europe/Warsaw
   /system identity
   set name=IDIRECT-MIKROTIK-X
   /system ntp client
   set enabled=yes
   /system ntp server
   set broadcast=yes enabled=yes multicast=yes
   /system ntp client servers
   add address=tempus1.gum.gov.pl
   add address=tempus2.gum.gov.pl

   Poniżej wymienione procesy wykonane w konfiguracji:

   • Wyłączenie nie używanych usług na routerze takich jak: telnet, ftp, www, api. Ograniczenie połączeń ssh do routera tylko z sieci lokalnych.
   • Ustawienie strefy czasowej na strefę Europe/Warsaw.
   • Ustawienie nazwy routera na IDIRECT-MIKROTIK-X gdzie X to 1 dla R1 oraz 2 dla R2
   • Włączenie usługi ntp client oraz ntp server.
   • Skonfigurowanie klienta ntp i ustawienie serwerów na główny urząd miar.

Urządzenie wykorzystane do wdrożenia wcześniej wymienionych konfiguracji to:

1. Platforma iDirect Evolution series 15100, razem z wymaganymi kartami nadawczymi i odbiorczymi.
2. Modem/Terminal satelitarny iDirect Evolution X3
3. Serwery Dell poweredge R440
4. Switch Cisco Catalyst C9300-24P-M

Wybór platformy satelitarnej padł na platformę iDirect gdyż jest to jedna z najlepiej wspieranych i najlepiej udokumentowanych platform służących do wdrożeń sieci satelitarnych.

Router został wybrany jako MikroTik gdyż posiada on wszystkie funkcje wymagane do obsługi platformy oraz pozwoli na ewentualną rozbudowę sieci o tunele VPN lub redystrybucję tras w przyszłości. Łatwość konfiguracji oraz znajomość platformy przez autora też były nieuwzględnione podczas wyboru tej platformy.

Switch nie pełni tutaj żadnej innej funkcji poza dzieleniem domeny rozgłoszeniowej na dwie podsieci tunnel oraz upstream. Platforma Catalyst została wybrana z racji znajomości tej platformy.

Platforma Satelitarna iDirect Evolution series 15100
Źródło: https://www.idirect.net/

Najważniejsze cechy platformy:

• Seria 15100 może pomieścić do 20 uniwersalnych lub obronnych kart liniowych (ULC, DLC)
• Obsługuje do pięciu satelitów
• Obsługuje DVB-S2/DVB-S2X ACM z modulacją od QPSK do 256APSK
• Karty liniowe obsługują do 119 Msps DVB-S2X forward carriers i Adaptive TDMA na powrocie
• 48-portowy interfejs Gigabit Ethernet LAN obsługuje wysokie szybkości symboli nośnych
• Wysoki poziom nadmiarowości dzięki łańcuchowemu połączeniu hubów i nadmiarowości geograficznej
• Umożliwia konfigurację operatora sieci hosta (HNO) i operatora sieci wirtualnej (VNO)
• Współpracuje z wysokowydajnymi procesorami protokołów i serwerami NMS w celu inteligentnego routingu IP i równoważenia obciążenia

Modem/Terminal satelitarny iDirect Evolution X3
Źródło: https://www.idirect.net/

Maksymalne parametry osiągane dla modemu iDirect Evolution X3:

• Downstream DVB-S2 Upstream TDMA Upstream SCPC Return
• Modulation QPSK, 8PSK, 16APSK BPSK, QPSK, 8PSK BPSK, QPSK, 8PSK
• Max. Symbol Rate 45 Msps 7.5 Msps 15 Msps
• Max. Info Rate 150 Mbps1 12.8 Mbps 24 Mbps
• Max. Line Card IP Data Rate 149 Mbps1 11.1 Mbps2 18.2 Mbps3
• Max. Remote IP Data Rate 29 Mbps1 7.8 Mbps2 11.8 Mbps31

Serwer Dell poweredge R440
Źródło: https://www.dell.com/

Switch Cisco Catalyst C9300-24P-M
Źródło: https://www.cisco.com/

Router Mikrotik RB1100AHx4
Źródło: https://mikrotik.com/

Projekt sieci przedstawionej w pracy to minimalne wymagania funkcjonale co do sieci która musi być wdrożona aby obsłużyć podstawowe funkcje platformy iDirect. Sieć ta jest już aktualnie wdrożona podczas pisania tej pracy i obsługuję kilka stacji satelitarnych.

Środowiska testowe oraz konfiguracje przedstawione w tej pracy miały na celu rozjaśnienie działania sieci satelitarnych oraz przedstawienie tego w jaki sposób takie sieci się implementuje. Cel ten został zrealizowany na przykładzie projektu sieci satelitarnej zawierającej wymaganą ilość komponentów do obsługi takiej sieci.

Platforma iDirect to zaawansowane rozwiązanie, które zapewnia wyjątkową elastyczność w zakresie konfiguracji sieci. Dzięki tej platformie możliwe jest zestawienie infrastruktury telekomunikacyjnej w taki sposób, aby dostawca satelitarny był połączony z główną lokalizacją klienta za pomocą dedykowanego łącza światłowodowego, podczas gdy wszystkie biura podległe są integrowane poprzez łącza satelitarne. Ta unikalna architektura pozwala na wdrożenie innowacyjnych rozwiązań i lepsze zarządzanie zasobami, co stanowi doskonałą bazę do przyszłych badań i rozwoju.

Na podstawie wyników osiągniętych w niniejszej pracy, istnieje możliwość rozbudowy lub prowadzenia dalszych badań, które mogą obejmować następujące obszary.

Przewiduje się wprowadzenie dodatkowych zabezpieczeń oparciu o technologie tuneli VPN. Tunelowanie VPN pozwala na bezpieczne połączenia między zdalnymi lokalizacjami a centralą, co jest kluczowe w kontekście ochrony danych wrażliwych i komunikacji. Współczesne potrzeby biznesowe oraz intensyfikacja cyberataków sprawiają, że wzmocnienie zabezpieczeń sieciowych przy użyciu technologii VPN staje się priorytetem, szczególnie w sytuacjach, gdy pracownicy pracują zdalnie.

Kolejnym kierunkiem rozwoju jest zastosowanie adresacji publicznej na urządzeniach klienckich oraz redystrybucja tras protokołu RIP do BGP. Implementacja takich rozwiązań może przynieść korzyści dla klientów, którzy przy takiej strukturze sieci mogą mieć przydzielony publiczny adres IP.

Ostatnim, ale nie mniej istotnym kierunkiem badań, jest opracowanie dodatkowych symulacji obciążenia sieci. Stworzenie modeli symulacyjnych pozwoli na lepsze zrozumienie reakcji systemu pod różnymi obciążeniami, zwłaszcza w kontekście wzrastającej liczby użytkowników i urządzeń podłączonych do sieci. Dzięki tym badaniom można będzie identyfikować potencjalne wąskie gardła i optymalizować infrastrukturę, co wpłynie na jakość świadczonych usług oraz zadowolenie końcowych użytkowników.

Przyszłość badań w zakresie technologii satelitarnej i lądowej infrastruktury sieciowej składa się z wielu, różnorodnych elementów, które razem tworzą kompleksową sieć usług telekomunikacyjnych. Zastosowanie innowacyjnych rozwiązań w zakresie bezpieczeństwa, routing oraz symulacji obciążenia może przyczynić się do znacznej poprawy wydajności i bezpieczeństwa sieci. Dalsze badania powinny skupić się na integracji tych technologii w sposób, który zaspokoi rosnące potrzeby użytkowników oraz przyczyni się do zrównoważonego rozwoju infrastruktury telekomunikacyjnej.