Routing w sieciach VPN (VTI)

Opublikowany przez pawel w NETWORK, VPN

W pierwszej kolejności należy wyjaśnić jaka jest różnica pomiędzy tradycyjnymi  tunelami IPSEC a tunelami opartymi o VTI (Virtual Tunnel Interface). Tradycyjna konfiguracja tunelu IPSEC wymaga zdefiniowania zasobów które mają zostać połączone za pomocą kreowanego tunelu (local traffic to remote traffic). Taka definicja wpływa na trasowanie pakietów powodując, że proces trasowania na urządzeniu przebiega w oparciu o tablicę routingu oraz polisę IPSEC (SPD). Polisa wymusza aby wszystkie pakiety które spełniają kryteria polisy były enkapsulowane w IPSEC. Zastosowanie interfejsów VTI powoduje, że uzyskujemy możliwość wpływania na trasowanie pakietów w sposób dużo bardziej elastyczny niż ma to miejsce gdy korzystamy z polisy IPSEC (zmian routingu wymaga wprowadzenia zmiany w polisie IPSEC). Korzystając z VTI możemy do trasowania pakietów korzystać ze statycznych reguł routingu, PBR jak i użyć trasowania z wykorzystaniem dynamicznych protokołów routingu.

Możliwość operowania interfejsami VTI została wprowadzona w STORMSHIELD począwszy od wersji SNS 2.x firmware.

Sposób skorzystania z interfejsów VTI zostanie przedstawiona na przykładzie:

  • lokalizacja A posiada dwa łącza dostępowe (wan1, wan2)
  • lokalizacja B posiada jedno łącze dostępowe (wan3)
  • w lokalizacji B znajduje się serwer http/ssh (net_server)
  • należy zrealizować połączenia VPN pomiędzy lokalizacajami A i B tak aby zapytania http z lokalizacji A do serwera net_server były kierowane przez tunel zrealizowany pomiędzy wan1<->wan3 a połączenia ssh do net_server poprzez tunel zrealizowany pomiędzy wan2<->wan3
  • należy zapewnić ciągłość dostępu do serwisów http/ssh, oznacza to, że w przypadku awarii jednego łącza należy oba serwisu przepuścić łączem czynnym.

Tak przedstawionego zadania nie jesteśmy w stanie zrealizować z wykorzystaniem typowych tuneli IPSEC (pomijam sytuację użycia transalacji NAT). Ponieważ rozgraniczenie trasowania ma być determinowane usługą wykorzystamy PBR (Policy Base Routing).

Lokalizacja A

Rozpoczynamy od utworzenia interfejsów VTI:

vti1

Następnie tworzymy obiekty reprezentujące interfejsy VTI w lokalizacji B:

vti_hosts1

Konfigurujemy oba tunele IPSEC łączące interfejsy wirtualne:

ipsec_loka

konfiguracja zdalnych lokalizacji prezentuje się (wan3_endpoint:192.168.120.2, wan3_endpoint_bis:192.168.120.3):

lokzdal1

lokzdal2

Konfiguracja zapory:

fw1_ipsec

gdzie:

router_http

router_ssh

router_ssh1

router_ssh2

Lokalizacja B

Konfiguracja interfejsu WAN3:

wan3

Konfiguracja interfejsów VTI:

vti_lokb

Następnie tworzymy obiekty reprezentujące interfejsy VTI w lokalizacji A:

hosts_vti_a

Konfigurujemy oba tunele IPSEC łączące interfejsy wirtualne:

ipsec_lokb_loka

konfiguracja zdalnych lokalizacji prezentuje się (wan1_endpoint:192.168.100.2, wan2_endpoint_bis:192.168.110.2):

to_wan2

to_wan1

Konfiguracja zapory (gdzie: remote_traffic:172.16.10.0/24):

fw_lokb

Musimy również zapewnić właściwy powrót pakietów poprzez konfigurację tras powrotnych:

trasypowrotne_lokb

Nie można zrealizować powyższego przykładu w sytuacji gdy w lokalizacji B posiadamy do dyspozycji tylko jeden adres publiczny.

- Paweł Grzelewski

07 Lis 2016


Najnowszy firmware SNS: 3.7.1 (Release Note)
Najnowszy firmware SNSv2: 2.12.2 (Release Note)