Zyxel Firewall [VPN Routing] - Routing ruchu z tunelu VPN do innej lokalizacji VPN [VPN Routing]

Ważna informacja:
Drogi kliencie, pamiętaj, że korzystamy z tłumaczenia maszynowego, aby dostarczać artykuły w Twoim lokalnym języku. Nie wszystkie teksty mogą być przetłumaczone dokładnie. W przypadku pytań lub rozbieżności dotyczących dokładności informacji w przetłumaczonej wersji, prosimy o zapoznanie się z oryginalnym artykułem tutaj:Wersja oryginalna

W tym artykule wyjaśniono, jak kierować ruch z tunelu site-to-site do innego tunelu, aby dotrzeć do urządzeń znajdujących się za połączeniem site-to-site. Wyjaśnia, jak kierować ruch z witryny A do witryny B przez zaporę / bramę HQ (trasa site-to-site przez tunel site-to-site), rozwiązywanie problemów / problemów, reguły routingu, jeśli chcesz, aby sieci VPN klienta docierały do serwera znajdującego się w innej witrynie (client-to-site przez site-to-site), konfiguracja SecuExtender IPSec.

Alternatywa 1: Routing ruchu ze zdalnego tunelu VPN do innej sieci VPN typu site-to-site

1) Konfiguracja tuneli VPN

Wymagania wstępne: Połączenie między lokalizacjami musi być już ustanowione.

Po ustanowieniu tunelu połączymy go za pomocą protokołu L2TP przez IPSec.

Instrukcje dotyczące konfigurowania sieci VPN można znaleźć w:

VPN - Konfiguracja IPSec Site-To-Site VPN

Można tam znaleźć informacje o L2TP przez IPSec:

VPN - Configure L2TP over IPSec VPN using PSK [Stand-alone mode]

Aby uprościć proces, można użyć kreatora do utworzenia tunelu VPN i L2TP over IPSec.

2) Konfigurowanie zasad routingu

Aby umożliwić ruch między główną siedzibą (HQ) a lokalizacją B, należy skonfigurować zasady i trasy dla tunelu VPN.

Na zaporze sieciowej centrali:

  1. Utwórz trasę polityki, która kieruje żądania przychodzące z tunelu L2TP do tunelu Site B. To jest kierowanie żądań przychodzących z tunelu L2TP przez zaporę HQ do tunelu Site B

    • Źródło: Podsieć klienta L2TP
    • Miejsce docelowe: Podsieć Site B
    • Next-hop: Tunel VPN "Tunel lokacji B"

Zwróćuwagę, że adres docelowy to adres naszego klienta.

2. Utwórz politykę, która zezwala na odpowiedzi z witryny B i kieruje je do tunelu do witryny B. Ma to kluczowe znaczenie dla ruchu powracającego z witryny B do centrali.

    • Źródło: Dowolne
    • Miejsce docelowe: Tunel L2TP
    • Next-hop: Tunel VPN "Tunel L2TP"

W witrynie B:

  1. Utwórz również trasę zasad, która zezwala na przychodzące żądania z centrali i przekazuje je do tunelu do witryny B. Utwórz również trasę zasad, która zezwala na odpowiedzi z centrali i kieruje je do tunelu do witryny B:

Upewnij się, że Asymmetric Routing jest włączony dla płynnej łączności. Opcję tę można znaleźć tutaj:

Konfiguracja > Polityka bezpieczeństwa > Kontrola zasad

mceclip0.png

Włączenie tej funkcji aktywuje trasę "trójkątną", umożliwiając zaporze korzystanie z asymetrycznej topologii trasy w sieci i zapobiegając resetowaniu połączenia po powrocie odpowiedzi.

Wykonując te kroki, można skutecznie kierować ruch między tunelami VPN i utrzymywać płynne i bezpieczne połączenie między centralą a lokalizacją B.

Alternatywa 2: Routing z tunelu VPN do innej lokalizacji VPN

1) Trasowanie ruchu z lokalizacji A do lokalizacji B przez lokalizację HQ

mceclip9.png

Jeśli chcesz, aby witryna A docierała do witryny B i odwrotnie, musisz utworzyć trasy zasad na każdej zaporze sieciowej, aby poinformować zaporę sieciową centrali, gdzie wysyłać przychodzące żądania i gdzie również wysyłać odpowiedzi.

1.1 Trasy zasad - zapora HQ

Na zaporze HQ należy najpierw skonfigurować regułę, która zezwala na żądania przychodzące z witryny A, które trafiają do witryny B. Muszą one być kierowane w tunelu do witryny B, co jest ważne zarówno dla żądań ICMP (pochodzących z witryny A), ale także dla odpowiedzi ICMP (pochodzących z witryny B i teraz wracają ponownie do witryny B).

Przychodzące: dowolne - Źródło: "Site A subnet" -> Destination: "podsieć witryny B" - tunel Next-hop - "tunel VPN witryny B"

mceclip1.png

Po drugie, musisz skonfigurować regułę, która zezwala na odpowiedzi przychodzące z witryny B, które idą do witryny A (po wysłaniu żądania z witryny A) i muszą być kierowane do tunelu witryny A. Jest to ważne zarówno dla żądań ICMP (pochodzących z witryny B), ale także dla odpowiedzi ICMP (pochodzących z witryny B i teraz wracających do witryny A).

Przychodzące: dowolne - Źródło: "Site B subnet" -> Destination: "podsieć witryny A" - tunel Next-hop - "tunel VPN witryny A"

mceclip5.png

1.2 Trasy zasad - zapora sieciowa witryny A

Następnie należy skonfigurować regułę, która zezwala na żądania przychodzące z witryny B, które trafiają do witryny A (po wysłaniu żądania z witryny B). Muszą one zostać przekierowane"z powrotem" do tunelu Site A, co jest ważne zarówno dla żądań ICMP (pochodzących z Site B), ale także dla odpowiedzi ICMP (pochodzących z Site B i teraz wracają z powrotem do Site B).

Przychodzące: dowolne - Źródło: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"

mceclip6.png

1.3 Trasy zasad - zapora sieciowa witryny B

Następnie należy skonfigurować regułę, która zezwala na żądania przychodzące z witryny A, które trafiają do witryny B (po wysłaniu żądania z witryny A). Muszą one zostać przekierowane"z powrotem" do tunelu witryny B, co jest ważne zarówno dla żądań ICMP (pochodzących z witryny A), ale także dla odpowiedzi ICMP (pochodzących z witryny A i teraz wracających ponownie do witryny A).

Przychodzące: dowolne - Źródło: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"

mceclip4.png

2) Weryfikacja / rozwiązywanie problemów

Po skonfigurowaniu wszystkich tras zasad ważne jest, aby sprawdzić, czy routing faktycznie działa. Być może w regułach zapory sieciowej występują sprzeczne trasy (nakładanie się podsieci, istniejąca polityka / trasy statyczne itp.

Należy pamiętać, że może to być bardzo mylące, ponieważ istnieje wiele tras, którymi należy się zająć. Najprostszym sposobem na to jest ręczne zmapowanie wszystkich przepływów pakietów na papierze (komputer -> brama A - brama musi przekierować do centrali, centrala musi przekierować do lokalizacji B - lokalizacja B musi przekierować odpowiedź z powrotem do centrali ... itd.), zadaj sobie pytanie - "kto jest odpowiedzialny za routing i czy routing jest na miejscu?".

mceclip10.png

Poniżej znajdziesz dwa scenariusze, w których może być konieczna zmiana konfiguracji, aby routing działał.

2.1 Test przez pingowanie firewalla

Pierwszym z nich jest testowanie poprzez pingowanie z komputera w witrynie A do serwera lub komputera w witrynie B:

Czerwona strzałka - żądanie ICMP [ping]

Zielonastrzałka - odpowiedź ICMP [ping]

2.2mTrasy zasad - zapora sieciowa witryny A

Jeśli pingujesz bramę witryny B z bramy witryny A (wbudowane narzędzie ICMP), routing zasad w witrynie A nie będzie miał zastosowania do odpowiedzi zwrotnych z witryny B, jeśli witryna B próbuje pingować bramę witryny A.

Dlatego potrzebujemy trasy polityki, która wygląda następująco:

Przychodzące: ZyWall- Źródło: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"

mceclip8.png

2.3 Trasy zasad - zapora sieciowa witryny B

Pierwszym testem, który możesz wykonać, jest pingowanie firewalla, jednak ponieważ routing, który teraz utworzyłeś, jest TYLKO dla przychodzących (z wyłączeniem Zywall), oznacza to, że routing nie będzie miał zastosowania, jeśli ping pochodzi z Site A, dociera do Firewalla Site B, a następnie Firewall jest odpowiedzialny za odpowiedź na to żądanie. Odpowiedź ICMP będzie wyglądać następująco:

Żądanie ICMP

PC (ICMP Request) -> Site A Gateway -> VPN tunnel to HQ -> HQ Gateway wysyła ruch do Site B Gateway

Odpowiedź ICMP

Site B Gateway (ICMP Reply) -> Site B Gateway -> tunel VPN do HQ -> HQ Gateway wysyła ruch do Site A Gateway -> Site A Gateway wysyła pakiety z powrotem do PC

Dlatego ta trasa polityki jest potrzebna:

Przychodzące: ZyWall- Źródło: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"

mceclip3.png

2.4 Test przez pingowanie serwera / komputera

Ponieważ komputer PC znajduje się w sieci 192.168.20.0/24, a serwer znajduje się w sieci 192.168.30.0/24, serwer nie rozpoznaje sieci 192.168.20.0/24 i dlatego najprawdopodobniej zablokuje pakiety ICMP pochodzące z nieznanych podsieci. Dlatego podczas wykonywania testów należy zawsze

  • Wyłącz wszelkie wbudowane zapory sieciowe (np. Windows Defender / Firewall)
  • Wyłącz inne oprogramowanie antywirusowe i zabezpieczające punkty końcowe zainstalowane na serwerze / komputerze.

mceclip11.png

Kierowanie ruchu od klienta do witryny przez tunel między witrynami

Uwaga: To nie działa z Dynamic VPN! Wybierz tylko Site2Site VPN!

1.png

1) Konfiguracja SecuExtender IPSec VPN

Aby przekierować klientów IPSec VPN do innego tunelu, muszą oni używać stałych adresów IP.

Jeśli wymagane jest kierowanie wielu różnych klientów, zaleca się użycie adresów IP, które są blisko siebie, aby można było utworzyć zakres. Zmniejsza to liczbę niezbędnych tras.

Podsieć, w której znajdują się adresy IP, nie musi być obecna na zaporze.

Wprowadź stały adres IP w kliencie IPSec VPN

2.png

2) Konfiguracja routingu zapory sieciowej

Na zaporze sieciowej przejdź do

dyn_repppp_0

i kliknij

dyn_repppp_1

aby utworzyć zakres adresów IP klienta IPSec VPN.

3.png

Teraz możemy dodać niezbędne trasy pod

dyn_repppp_2

za pomocą kliknięcia na

dyn_repppp_3

4.png

2.1 Zapora sieciowa w lokalizacji A

Musimy utworzyć dwie trasy:

  • Jedną dla ruchu wychodzącego, czyli z dynamicznego tunelu VPN-klient do zdalnej podsieci przez tunel site-to-site.

5.png

  • Jeden dla ruchu przychodzącego, czyli z podsieci zdalnej przez tunel site-to-site do tunelu VPN-klient.

6.png

Nowe trasy powinny wyglądać podobnie do tej:

7.png

Innym sposobem na przejście ruchu przychodzącego ze zdalnej podsieci przez zdalny tunel VPN jest włączenie "trasy asymetrycznej":

mceclip0.png

Spowoduje to włączenie trasy "trójkątnej", która sprawi, że zapora zezwoli na użycie asymetrycznej topologii trasy w sieci i nie zresetuje połączenia po powrocie odpowiedzi.

2.2 Zapora sieciowa w lokalizacji B

W zdalnej lokalizacji może być konieczne utworzenie podobnych tras, aby urządzenie w głównej lokalizacji wiedziało, jak obsługiwać ruch od klientów VPN pochodzących z oddziału.

W siedzibie głównej tworzymy zakres IP dla zdalnych klientów VPN, abyśmy mogli go użyć do kierowania ruchu.

8.png

Teraz tworzymy odpowiednie trasy również w siedzibie głównej.

Jedna trasa wychodząca, więc z podsieci HQ przez tunel site-to-site do zdalnych klientów VPN.

9.png

I jedna trasa przychodząca, więc ze zdalnego zakresu klientów VPN przez tunel site-to-site do lokalnej sieci LAN centrali. Jeśli ruch jest kierowany do lokalnej podsieci, wybieramy "Auto" jako następny hop, USG zarządza tym automatycznie.

10.png

Trasy powinny wyglądać mniej więcej tak:

11.png

+++ Możesz kupić licencje dla swoich klientów Zyxel VPN (SSL VPN, IPsec) z natychmiastową dostawą za pomocą 1 kliknięcia: Zyxel Webstore +++

Artykuły w tej sekcji

Czy ten artykuł był pomocny?
Liczba użytkowników, którzy uważają ten artykuł za przydatny: 3 z 9
Udostępnij

Komentarze

Komentarze: 0

Zaloguj się, aby dodać komentarz.