Popularne są dwa scenariusze. Pierwszy dotyczy sytuacji gdy naszym dostawcą Internetu jest lokalny provider. Bardzo często w ramach swojej infrastruktury sieciowej operuje on na adresacji prywatnej (czyli np. z zakresu 192.168.0.0/16) natomiast dla użytkowników którzy mają takie wymagania dostarcza on niewielką pulę (czasami tylko jeden) adresów z własnej puli adresów publicznych. Drugi przypadek to taki gdy operator telekomunikacyjny dostarcza użytkownikowi tzw. adresację połączeniową (czyli adres publiczny z sieci z maską 255.255.255.252) natomiast w sytuacji gdy użytkownik wymaga większej liczby adresów z puli adresów publicznych rejestruje wymaganą podsieć lub nawet całą klasę w RIPE i zapewnia jej trasowanie do routera użytkownika.

W obu przypadkach administrator sieci musi w jakiś sposób zagospodarować posiadaną adresację. Artykuł został podzielony na dwie części, w pierwszej opiszę sytuację dla ruchu OUTGOING w drugiej dla ruchu INCOMING. Oczywiście opisy dotyczą topologii gdy urządzeniem dostępowym dla sieci lokalnej jest STORMSHIELD UTM.

Część 1

Dostawca zrealizował usługę dostawy łącza w oparciu o podsieć 192.168.100.0/255.255.255.252. Adres 192.168.100.1 jest bramą po stronie dostawcy natomiast adres 192.168.100.2 jest adresem dla klienta (do wykorzystania na jego urządzeniu dostępowym). Dodatkowo klientowi została przydzielona pula adresów (posieć) 10.0.1.0/255.255.255.0. Administrator zdecydował, że podsieć lokalna (Network_in) będzie natowana na adres 10.0.1.100.

W pierwszej kolejności należy należy zapewnić dostęp do łącza komunikacyjnego poprzez zadanie przydzielonego adresu na interfejsie:

oraz skonfigurowanie bramy domyślnej:

Załużmy, że reguła translacji będzie w postaci (obiekt storm_100 reprezentuje adres 10.0.1.100):

Wykonujemy polecenie ping:

weryfikujemy co się dzieje na interfejsie UTM-a:

okazuje się, że problemem jest fakt, że brama nie może uzyskać od interfejsu UTM-a adresu MAC dla pakietów pochodzących z hosta storm_100.

Problem widziany od strony routera (bramy):

problem możemy rozwiązać na dwa sposoby:

Wariant1

Bezpośrednio na interfejsie urządzenia konfigurujemy adres 10.0.1.100:

Wariant 2

Bezpośrednio na interfejsie skonfigurować dodatkowo dowolny z przydzielonej puli adres IP:

oraz zapewnić propagację ARP:

Niezależnie od wariantu komunikacja będzie przebiegać prawidłowo:

Część 2

Dostawca zrealizował usługę dostawy łącza w oparciu o podsieć 192.168.100.0/255.255.255.252. Adres 192.168.100.1 jest bramą po stronie dostawcy natomiast adres 192.168.100.2 jest adresem dla klienta (do wykorzystania na jego urządzeniu dostępowym). Dodatkowo klientowi została przydzielona pula adresów (posieć) 10.0.1.0/255.255.255.0. Administrator zdecydował, że pakiety adresowane na adres 10.0.1.10 będą niezależnie od usługi (portu) forwardowane na adres w sieci lokalnej 172.16.10.2.

W pierwszej kolejności należy należy zapewnić dostęp do łącza komunikacyjnego poprzez zadanie przydzielonego adresu na interfejsie:

oraz skonfigurowanie bramy domyślnej:

Załużmy, że reguła translacji (zrealizowana na FW) wygląda tak:

Obiekt storm_10 to reprezentuje adres 10.0.1.10 a obiekt admin_pc adres 172.16.10.2.

Z hosta znajdującego się w Internecie (192.168.140.x) wydajemy polecenie ping.

Na interfejsie zewnętrznym urządzenia UTM odnotowujemy szereg zapytań ARP od routera (bramy) z rządaniem wskazania adresu MAC powiązanego z adresem 10.0.1.10 (storm_10):

urządzenie UTM nie jest wstanie dokonać takiego powiązania. Od strony routera jest to uwidocznione:

problem możemy rozwiązać na dwa sposoby:

Wariant1

Bezpośrednio na interfejsie urządzenia konfigurujemy adres 10.0.1.10:

Wariant 2

Bezpośrednio na interfejsie skonfigurować dodatkowo dowolny z przydzielonej puli adres IP:

oraz zapewnić propagację ARP:

Niezależnie od wariantu komunikacja będzie przebiegać prawidłowo: