Zyxel Firewall [VPN Routing] - Instradamento del traffico da un tunnel VPN a un altro sito VPN [VPN Routing]

Questo articolo spiega come instradare il traffico da un tunnel site-to-site in un altro tunnel per raggiungere i dispositivi dietro una connessione site-to-site. Spiega come instradare il traffico dal sito A al sito B attraverso il firewall/gateway HQ (instradamento da sito a sito attraverso il tunnel da sito a sito), la risoluzione di problemi, le regole di instradamento se si desidera che le VPN client raggiungano un server situato in un altro sito (da client a sito attraverso il tunnel da sito a sito), la configurazione di SecuExtender IPSec.

Alternativa 1: instradamento del traffico dal tunnel VPN remoto a un'altra VPN site-to-site

1) Impostazione dei tunnel VPN

Prerequisito: Deve essere già stata stabilita una connessione site-to-site tra le sedi.

Una volta stabilito il tunnel, lo collegheremo utilizzando L2TP su IPSec.

Per istruzioni su come impostare una VPN, consultare:

VPN - Configurazione di una VPN IPSec da sito a sito

È possibile trovare informazioni su L2TP su IPSec:

VPN - Configurazione di una VPN L2TP su IPSec con PSK [modalità stand-alone].

Per semplificare il processo, è possibile utilizzare la procedura guidata per la creazione di un tunnel VPN e L2TP over IPSec.

2) Configurazione dei criteri di instradamento

Per consentire il traffico tra la sede principale (HQ) e il sito B, è necessario impostare le politiche e le rotte per il tunnel VPN.

Sul firewall HQ:

1. Creare un percorso di policy che instradi le richieste in arrivo dal tunnel L2TP al tunnel del sito B. Questo è l'instradamento delle richieste in entrata dal tunnel L2TP attraverso il Firewall HQ verso il tunnel del sito B.

   • Fonte: Sottorete del client L2TP
   • Destinazione: Sottorete del sito B
   • Next-hop: tunnel VPN "tunnel del sito B".

Si noti che l'indirizzo di destinazione è l'indirizzo del nostro cliente.

2. Creare un criterio che consenta le risposte dal sito B e le instradi nel tunnel verso il sito B. Questo è fondamentale per il traffico di ritorno dal sito B alla sede centrale.

• • Fonte: Qualsiasi
  • Destinazione: Tunnel L2TP
  • Next-hop: tunnel VPN "Tunnel L2TP"

Sul sito B:

1. Inoltre, creare una rotta di criterio che consenta le richieste in entrata dal quartier generale e le inoltri nel tunnel verso il sito B. Creare quindi una rotta di criterio che consenta le risposte dal quartier generale e le instradi nel tunnel verso il sito B:

Assicurarsi che il Routing asimmetrico sia abilitato per una connettività senza interruzioni. Questa opzione è disponibile qui:

Configurazione > Criteri di sicurezza > Controllo criteri

Abilitando questa funzione si attiva il percorso "triangolare", consentendo al firewall di utilizzare una topologia di percorso asimmetrica nella rete e impedendo il ripristino della connessione in caso di risposta.

Seguendo questi passaggi, è possibile instradare efficacemente il traffico tra i tunnel VPN e mantenere una connessione fluida e sicura tra il quartier generale e il sito B.

Alternativa 2: instradamento dal tunnel VPN a un altro sito VPN

1) instradare il traffico dal sito A al sito B attraverso il sito HQ

Se si desidera che il sito A raggiunga il sito B e viceversa, è necessario creare rotte di policy su ciascun firewall per consentire al firewall HQ di sapere dove inviare le richieste in arrivo e dove inviare le risposte.

1.1 Rotte di criterio - Firewall HQ

Sul firewall HQ, occorre innanzitutto configurare una regola che consenta le richieste provenienti dal sito A e dirette al sito B. Queste devono essere instradate nel tunnel verso il sito B, e ciò è importante sia per le richieste ICMP (provenienti dal sito A), sia per le risposte ICMP (provenienti dal sito B e che ora tornano al sito B).

In arrivo: qualsiasi - Sorgente: "Sottorete del sito A" -> Destinazione: "Sottorete del sito B" - Next-hop Tunnel - "Tunnel VPN del sito B".

In secondo luogo, è necessario configurare una regola che consenta le risposte provenienti dal sito B e dirette al sito A (quando si è inviata una richiesta dal sito A) e che vengano instradate nel tunnel del sito A. Questo è importante sia per le richieste ICMP (provenienti dal sito B), sia per le richieste ICMP (provenienti dal sito A). Questo è importante sia per le richieste ICMP (provenienti dal sito B), sia per le risposte ICMP (provenienti dal sito B e che ora tornano al sito A).

In entrata: qualsiasi - Sorgente: "Sottorete del sito B" -> Destinazione: "Sottorete del sito A" - Next-hop Tunnel - "Tunnel VPN del sito A".

1.2 Rotte politiche - Firewall del sito A

Quindi, è necessario configurare una regola che consenta le richieste provenienti dal sito B e dirette al sito A (quando si è inviata una richiesta dal sito B). Queste devono essere instradate"indietro" nel tunnel del sito A, e questo è importante sia per le richieste ICMP (provenienti dal sito B), sia per le risposte ICMP (provenienti dal sito B e che ora tornano di nuovo al sito B).

In arrivo: qualsiasi - Sorgente: "Sottorete del sito B" -> Destinazione: "Sottorete del sito A" - Next-hop "Tunnel VPN del sito A".

1.3 Rotte politiche - Firewall del sito B

Quindi, è necessario configurare una regola che consenta le richieste provenienti dal sito A e dirette al sito B (quando si è inviata una richiesta dal sito A). Queste devono essere instradate"indietro" nel tunnel del sito B, e questo è importante sia per le richieste ICMP (provenienti dal sito A), sia per le risposte ICMP (provenienti dal sito A e che ora tornano di nuovo al sito A).

In entrata: qualsiasi - Sorgente: "Sottorete del sito A" -> Destinazione: "Sottorete del sito B" - Next-hop "Tunnel VPN del sito B".

2) Verifica / Risoluzione dei problemi

Dopo aver configurato tutte le rotte dei criteri, è importante verificare che il routing funzioni effettivamente. Forse ci sono rotte in conflitto nelle regole del firewall (sovrapposizioni di sottoreti, rotte statiche o di policy esistenti, ecc.

Si noti che questo può essere molto confuso, poiché ci sono molte rotte di cui ci si deve occupare. Il modo più semplice per farlo è tracciare manualmente tutti i flussi di pacchetti su un foglio di carta (PC -> Gateway A - il gateway deve instradare verso la sede centrale, la sede centrale deve instradare verso il sito B - il sito B deve instradare la risposta di nuovo verso la sede centrale ... ecc.

Di seguito sono riportati due scenari in cui potrebbe essere necessario modificare le configurazioni per far funzionare l'instradamento.

2.1 Test con il ping del firewall

Il primo consiste nel testare il ping da un PC del sito A a un server o a un PC del sito B:

Freccia rossa - Richiesta ICMP [ping]

Freccia verde - Risposta ICMP [ping]

2.2mRotte di policy - Firewall del sito A

Se si esegue il ping del gateway del sito B dal gateway del sito A (strumento ICMP incorporato), l'instradamento dei criteri del sito A non si applica alle risposte del sito B, se il sito B sta cercando di eseguire il ping del gateway del sito A.

Pertanto, abbiamo bisogno di un percorso di policy che assomigli a questo:

In arrivo: ZyWall- Sorgente: "Subnet del sito B" -> Destinazione: "Sottorete del sito A" - Next-hop "Tunnel VPN del sito A".

2.3 Rotte politiche - Firewall del sito B

Il primo test che si può fare è quello di inviare un ping al firewall, tuttavia, poiché l'instradamento creato ora è SOLO per i messaggi in entrata (escluso Zywall), significa che l'instradamento non si applicherà se il ping proviene dal sito A, raggiunge il firewall del sito B e quindi il firewall è responsabile della risposta a tale richiesta. La risposta ICMP sarà quindi simile a questa:

Richiesta ICMP

PC (richiesta ICMP) -> Gateway del sito A -> Tunnel VPN verso l'HQ -> Il gateway HQ invia il traffico al gateway del sito B

Risposta ICMP

Gateway del sito B (risposta ICMP) -> Gateway del sito B -> tunnel VPN verso HQ -> Gateway HQ invia traffico al gateway del sito A -> Gateway del sito A rimanda i pacchetti al PC

Pertanto, è necessario questo percorso di policy:

In entrata: ZyWall- Sorgente: "Sottorete del sito A" -> Destinazione: "Sottorete del sito B" - Next-hop "Tunnel VPN del sito B".

2.4 Test con il ping di un server / PC

Poiché il PC si trova sulla rete 192.168.20.0/24 e il server si trova sulla rete 192.168.30.0/24, il server non riconosce la rete 192.168.20.0/24 e quindi molto probabilmente bloccherà i pacchetti ICMP provenienti da sottoreti sconosciute. Pertanto, quando si eseguono i test, occorre sempre:

• Disattivare qualsiasi firewall integrato (ad esempio, Windows Defender / Firewall).
• Disattivare altri software antivirus e di sicurezza end-point installati sul server / PC.

Instradare il traffico da client a sito attraverso un tunnel da sito a sito

Attenzione: Non funziona con Dynamic VPN! Selezionare solo Site2Site VPN!

1) Configurare SecuExtender IPSec VPN

Per instradare i client IPSec VPN in un altro tunnel, è necessario utilizzare indirizzi IP fissi.

Se è necessario instradare molti client diversi, si consiglia di utilizzare IP vicini tra loro, in modo da creare un intervallo. In questo modo si riduce il numero di percorsi necessari.

La sottorete in cui si trovano gli indirizzi IP non deve essere presente sul firewall.

Inserire l'indirizzo IP fisso sul client VPN IPSec

2) Configurare l'instradamento del firewall

Nel firewall, navigare in

Configuration > Object > Address

e fare clic su

Add

per creare l'intervallo per gli indirizzi IP del client IPSec VPN.

Ora possiamo aggiungere le rotte necessarie sotto

Configuration > Network > Routing

con un clic sulla cartella

Add

2.1 Sito A Firewall

È necessario creare due rotte:

• Una per il traffico in uscita, quindi dal tunnel dinamico VPN-client alla subnet remota attraverso il tunnel site-to-site.

• Uno per il traffico in entrata, quindi dalla sottorete remota attraverso il tunnel site-to-site verso il tunnel VPN-client.

Le nuove rotte dovrebbero avere un aspetto simile a questo:

Un altro modo per far passare il traffico in arrivo dalla subnet remota attraverso il tunnel VPN remoto è quello di attivare il "percorso asimmetrico":

In questo modo si abilita il percorso "a triangolo" che fa sì che il firewall permetta l'uso della topologia di percorso asimmetrica nella rete e non ripristini la connessione al ritorno della risposta.

2.2 Firewall del sito B

Sul sito remoto, potrebbe essere necessario creare percorsi simili, in modo che il dispositivo del sito principale sappia come gestire il traffico dei clienti VPN provenienti dal sito della filiale.

Nel sito HQ, creiamo il range IP per i client VPN remoti in modo da poterlo utilizzare per instradare il traffico.

Ora creiamo le rotte corrispondenti anche sul sito HQ.

Una rotta in uscita, quindi dalla subnet HQ attraverso il tunnel site-to-site verso i client VPN remoti.

E una rotta in entrata, quindi dalla gamma di client VPN remoti attraverso il tunnel site-to-site verso la LAN locale del quartier generale. Se il traffico viene instradato in una sottorete locale, selezioniamo "Auto" come next-hop, l'USG lo gestisce automaticamente.

Le rotte dovrebbero avere un aspetto simile a questo:

+++ È possibile acquistare licenze per i client VPN Zyxel (SSL VPN, IPsec) con consegna immediata con un solo clic: Zyxel Webstore +++