La risorsa Italiana per pfSense

6 ottobre 2012

Multi WAN con pfSense - Parte 3

Nei precedenti articoli abbiamo visto come configurare pfSense in versione multi wan, oggi vedremo come completare la nostra configurazione attivando il monitoring delle interfacce ed effettuando il tuning finale del firewall.
Abbiamo visto che il multi wan ha due principali funzionalità:
  1. Aumentare la larghezza di banda disponibile aggregando più connessioni;
  2. Migliorare la disponibilità della connessione ridondandola.
Nello scorso articolo abbiamo visto come realizzare il punto uno, ora vedremo come mettere in atto il punto due attivando il monitoring. Per poter gestire in modo corretto la fault tolerance, pfSense ha bisogno di un meccanismo per verificare se le connessioni wan sono attive e funzionanti. Il modo più semplice per indagare se una connessione è attiva, è effettuare un ping verso un host in internet che normalmente è raggiungibile e verificare l'esito del ping.
Per mettere in atto questo meccanismo occorre effettuare le seguenti operazioni:
  1. Trovare un host che ha un livello di uptime del 99,99%;
  2. Accertarsi di poter "pingare" l'host senza arrecare danni o disturbo al proprietario;
  3. Far in modo che il ping passi attraverso la connessione da monitorare.

La scelta del Monitor

Normalmente quando devo scegliere un host da pingare, la mia scelta è quasi sempre uno dei dns del provider oppure uno dei router del provider. Entrambi questi tipi di target devono garantire un elevato uptime e normalmente rispondono al ping.

Il targhet che proveremo ad utilizzare è il primo router dopo il nostro e per testarlo procediamo come segue:
  • Effettuiamo un tracert verso il dns del nostro provider: tracert dns.provider.it
  • Selezioniamo l'IP del primo router dopo il nostro e proviamo a verificare se risponde al ping: ping 8.7.6.5
  • Se il router non risponde possiamo passare al dnsdel provider, meglio scegliere il secondario, oppure un'altro router lungo il cammino dalla nostra rete al dns;
  • Se il router risponde possiamo procedere e determinare allo stesso modo il router della seconda connettività.
Identificati gli indirizzi IP dei nostri targhet dobbiamo procedere inserendoli nella nostra configurazione:
  • Accediamo a System > Routing;
  • Procediamo alla modifica del primo Gateway cliccando su Edit;
  • Nel campo Monitor IP inseriamo l'IP che abbiamo individuato;
  • Clicchiamo su Save;
  • Ripetiamo l'operazione per gli altri Gateways

Forzare il gateway attraverso cui raggiungere il monitor

Così come li abbiamo impostati, i nostri monitor non servono a molto perchè in caso di down di una delle connessioni, pfSense farebbe transitare il ping attraverso l'altro gateway ed il monitor verrebbe comunque raggiunto.
Per ovviare a questo problema dobbiamo necessariamente fare in modo che il nostro monitor sia raggiungibile solo ed esclusivamente dal gateway che volgiamo monitorare, per farlo è sufficiente aggiungere una regola di firewall sull'interfaccia LAN per ogni gateway da monitorare.

Clicchiamo su Firewall > Rules;
Aggiungiamo una nuova regola con le seguenti impostazioni

Action: Pass
Interface: Lan
Protocol: Any
Destination: IP Monitor
Gateway: GW_WAN

Ripetiamo l'operazione per tutti i gateway

A questo punto il nostro bilanciamento + fault tolerance è funzionante, per fare un test possiamo eseguire il comando ping www.pfsenseitaly.com -t e durante l'esecuzione provare a staccare alternativamente il cavo delle nostre connessioni wan. Il ping continuerà a funzionare modificando il percorso utilizzato per raggiungere la destinazione.

Tuning del sistema

Ora vedremo alcuni accorgimenti da adottare in questo tipo di configurazioni per non incappare in malfunzionamenti ed errori.

Come abbiamo visto, il meccanismo di ripartizione del traffico è round robin, questo fa si che pfSense possa decidere in modo indipendente da dove far transitare i nostri pacchetti. Sfortunatamente alcuni protocolli non gradiscono il continuo cambio di sorgente generando malfunzionamenti. Tipicamente tra i protocolli che non gradiscono il cambio di sorgente abbiamo: HTTPS, SMTPS, IMAPS, POP3S ecc...
Come avrete certamente notato sono tutti protocolli sicuri. Per ovviare a questo problema possiamo agire scegliendo a priori attraverso quale gateway vogliamo far passare un determinato protocollo ma facendo in modo che in caso di fault del gateway il protocollo venga veicolato attraverso l'altro gateway disponibile.
Accediamo al menù Firewall > Rules
Aggiungiamo una nuova regola con le seguenti impostazioni

Action: Pass
Interface: Lan
Protocol: Any
Destination: Any
Protocol: HTTPS
Gateway: WAN_FAULT

WAN_FAULT è il gruppo che avevamo creato nella parte 2 e che pone Wan come gateway primario e OPT1 come backup.

Alcuni provider consentono l'accesso ai propri server DNS, SMTP, IMAP, POP3 ecc... solo dalla propria rete, questo ci obbliga a creare delle regole di firewall che forzino il traffico diretto verso questi indirizzi attraverso il gateway della loro rete. Supponiamo che sulla Wan1 abbiamo collegato il Provider A che consente l'accesso ai server SMTP solo tramite la propria connettività, procediamo come segue:

Accediamo al menù Firewall > Rules
Aggiungiamo una nuova regola con le seguenti impostazioni

Action: Pass
Interface: Lan
Protocol: Any
Destination: Any
Protocol: SMTP
Gateway: GW_WAN

A questo punto la nostra configurazione è terminata, il nostro firewall ora può sfruttare a pieno più connessioni gestendo in autonomia il bilanciamento del carico ed eventuali guasti delle connessioni.

7 commenti:

Fabio C. ha detto...

Prima di tutto grazie per queste mini guide, mi sono state utili per comprendere meglio pfSense, non posso però ancora metterlo in produzione perché ho dei problemi: attivando squid e squidguard in transparent proxy e contemporaneamente il load balancing e failover, non riesco poi ad "uscire".
Se configuro una sola wan, tutto ok.

Inoltre, come posso fare in modo che un certo Host esca solo ed esclusivamente su una wan e solo quella con tutti i protocolli?

Fabio Viganò ha detto...

Ciao,
per il primo punto avrei bisogno di maggiori dettagli. Squid è in ascolto sul VIP della LAN?

per il secondo punto basta fare così:
In firewall > rules > lan crei una regola così fatta:
Action: Pass
Interface: Lan
Source: (IP HOST)
Protocol: Any
Destination: Any
Protocol: Any
Gateway: (WAN da utilizzare)

Ciao Fabio

Fabio C. ha detto...

Si, squid è solo sulla lan, pare che la sua attivazione aggiunga "qualcosa" che rende incompatibile le sessioni multi WAN.

In pratica penso che se un host "esce" con un gateway, quello lo dovrebbe mantenere per un certo tempo, a meno che non ci sia un failover.

Da quello che ho capito, Zeroshell per esempio fa così; quindi non c'è strettamente necessità di forzare HTTPS per esempio, su uno specifico Gateway.

Del resto, se ho il server di posta che può dialogare solo con lo specifico provider, piuttosto forzerò solo quell'host ad uscire con un solo gateway, come del resto ho fatto ora con ZeroShell, mentre tutti i client della lan, possono uscire in load balancing, ma senza per questo aver problemi con i protocolli sicuri.

Ora mi chiederai, allora perché non continui ad usare ZeroShell... il fatto è che ho bisogno di un content filter affidabile e performante e questo è quello in cui è forte pfSense e scarso ZeroShell...

Fabio Viganò ha detto...

Scusa, nel punto uno ho scritto una cavolata dovuta alla fretta, giustamente chiedevi del funzionamento del multi wan e non del carp.

Andando con ordine:
1) squid e multiwan non hanno incompatibilità, io li uso in diverse installazioni senza problemi. Detto questo la causa del malfunzionamento potrebbe essere dovuta ad errori di configurazione. Per capire meglio avrei bisogno di sapere com'è configurato.
Io ti consiglierei di partire da zero quindi attivi Squid e metti queste config e vedi se così navighi poi passi al filtro dei contenuti.
Services > Proxy Server > General
Proxy Interface = LAN
Allow user on interface = ON
Transparent proxy = ON
Services > Proxy Server > Access Control
Allowed subnet = La tua subnet (es 192.168.0.0/24)
Salva tutto vai in
Status > Services
Riavvia Squid
In questo modo hai attivato il proxy ma in sostanza non fa nulla se non farti passare. Se così funziona procedi per gradi attivando le altre impostazioni.

2) nel bilanciare un carico è normale che il traffico venga ripartito sulle diverse connessioni altrimenti che bilanciamento sarebbe? In ogni caso se una sessione viene stabilita attraverso una connessione (wan) su questa viene mantenuta fino a chiusura garantendo che tutto vada senza errori. Attenzione alla differenza tra sessione e connessione che non sono assolutamente la stessa cosa ed è la prima causa di confusione ed errori.

Da quello che scrivi mi viene il dubbio che zeroshell stia facendo failover e non bilanciamento, se così fosse puoi farlo anche con pfsense così decidi tu a tavolino cosa passa da ogni connessione e se una connessione cade il traffico viene spostato sull'altra.
Ciao

Fabio C. ha detto...

Guarda, non sono un sistemista esperto, probabilmente è per quello che non ne vengo a capo... :) ma dopo aver letto innumerevoli post su forum, mi pare di capire che ci sono diversi problemi a far funzionare Squid+SquidGuard+HAVP contemporaneamente ad una doppia WAN in uscita.
Così, dato che pfSense l'ho virtualizzato sotto ESXi su una macchina di classe server, seppur vecchia ha comunque 8GB di ram; quello che avrei intenzione di fare è configurare 2 router pfsense, una sarà il gateway di default per le postazioni ed i server dell'ufficio filtrati e protetti, VPN e virtual server per alcune connessioni in ingresso, (ip camera ed altro).
L'altra più "libera" sarà usata da altre postazioni che possono navigare "liberi" e con il captive portal consentirà la navigazione agli "ospiti".
Il dubbio che mi viene è: chi delle due farà da DNS ?? e come faccio a specificare per ogni client che gateway deve usare ??

Fabio Viganò ha detto...

Non ti arrendere :D
Io ho una configurazione con 2 pfSense in carp con 4 wan, havp, squid, squid guard, captive portal con vouchers e 10 vlan e FUNZIONA!!!
Attiva e verifica una cosa per volta e vedrai che tutto funzionerà, se invece scegli per l'altra soluzione i tuoi pfsense possono essere entrambi dns e la suddivisione dei GW la devi fare a mano oppure suddividendo i client in due subnet separate e con dhcp separati.
ciao

Fabio C. ha detto...

Grazie 1000 davvero, sia per l'incoraggiamento, sia per le ottime guide ed il supporto sul forum italiano di pfSense.
Al momento ho messo su i due pfSense, poi un passo alla volta, come da prezioso consiglio, inizierò a sistemare i servizi, per il momento ho lasciato tutto sulla stessa rete, mettendo il DHCP relay al secondo.
Non credo di aver bisogno di un server DNS completo, il dnsmasq di default va bene, i nomi dei client li definisco nella lista host overrides, mentre gli host che acquisiscono l'ip in DHCP incappano nel captive portal, al bisogno, posso mettere il mac per scavalcarlo.
Per fortuna a suo tempo ho configurato tutti i client di lavoro con l'IP fisso e se anche qualcuno avesse la brillante idea di mettere il client in DHCP, ancora, incapperebbero nel captive portal.
Se poi un utente smaliziato, scoprisse l'indirizzo del gateway che "fa navigare", beh, credo sia sufficiente che metto una regola del firewall che da quel gateway quegli host non possono passare.
Ho detto qualche fesseria?