No banner in farm
iscriviti alla newsletter

ISAserver.it - No. 1 Unofficial European web site on Microsoft ISA Server / Forefront TMG

Home di ISAserver.it
Google
 
Articoli
Autori di ISAserver.it
Forum Tecnico Iscriviti al feed RSS del forum di ISAserver.it
Blog di Luca Conte Iscriviti al feed RSS del blog di ISAserver.it
Software per ISA Server
Soluzioni Hardware per ISA Server
Eventi Tecnici e Formazione
Libreria di ISAserver.it
Contatti
Consigliati da ISAserver.it

No banner in farm
WORKBOOK

No banner in farm
Quale prodotto utilizzi

Quale prodotto utilizzi

VMexperts.org
Community tecnica italiana sulla Virtualizzazione
VOIPexperts.it
Community tecnica italiana sul VOIP
 
 

<< Torna all'elenco degli Articoli
 
Progettare una soluzione
con ISA Server in reti complesse
Il presente articolo è una libera traduzione dell'articolo originale, in inglese, pubblicato su ISAserver.org.
ISAserver.it è stata autorizzata a pubblicare sul proprio portale una selezione dei migliori articoli di ISAserver.org. Se vuoi segnalare un articolo o se vuoi dare il tuo contributo traducendo un articolo inviami una mail a lconte<at>isaserver<d0t>it.


Nota all'articolo: In questo articolo si fa riferimento alla versione 2000 sia di ISA Server che di Windows. Questo non riduce il valore dell'articolo in quanto le considerazioni di tipo architetturale sono applicabili anche alle ultime versioni.


Autore: Jim Harrison (ISAserver.org)

PROGETTARE UNA SOLUZIONE
CON ISA SERVER IN RETI COMPLESSE

Figura 1


Versioni di ISA Server

  • Enterprise Edition – Per operare correttamente richiede un dominio Active Directory Windows 2000. Installare la versione Enterprise in un qualunque altro ambiente fa si che ISA Server venga configurato come Standalone, rendendo così inutile il maggior costo sostenuto per l’acquisto di questa versione.
  Standard Edition – La versione Standard ignora completamente l'esistenza di altri ISA Server e Array. Questa versione è da preferire in ambienti dove non siano presenti Array di server ISA o Active Directory.

Servizi di rete di Windows 2000 Server
Per poter utilizzare ISA Server e gestire le richieste da parte degli utenti ISA, sia interni che esterni, a seconda delle specifiche realtà, è necessario che alcuni dei seguenti servizi di rete di Windows 2000 Server siano installati e configurati.
  • DNS – necessario – W2K utilizza il DNS prima di qualunque altro sistema di risoluzione dei nomi quindi, installato e configurato correttamente, rende il processo di risoluzione dei nomi molto più veloce. Generalmente, per ridondanza, di server DNS se ne implementano almeno due.
  • DHCP – raccomandato – Il servizio garantisce la corretta configurazione dello stack TCP/IP di tutte le macchine interne, rendendo la vita un po’ più semplice. Se configurato correttamente, il servizio DHCP può semplificare il processo di aggiornamento dinamico del server DNS W2K per tutti quelle macchine client non W2K. NON utilizzare il DHCP per configurare l’IP di ISA Server.
  • WINS – facoltativo – Servizio di risoluzione dei nomi NetBIOS, non è richiesto per il funzionamento di W2K. Anche in ambienti con sistemi operativi diversi, a condizione che il DNS interno e le opzioni IP siano configurati correttamente e funzionanti, è possibile evitare l’installazione del WINS.
  • Domain Controller (Active Directory o NT SAM) – a seconda delle circostanze – Le funzionalità degli Array ISA (Enterprise Edition) sono utilizzabili a fondo solo in domini Active Directory W2K. In qualunque altro ambiente opera come server standalone.

Questi servizi possono rappresentare una componente critica per il normale funzionamento della infrastruttura di rete di ISA Server. ISA Server, in configurazione standalone, opera anche con Active Directory, ma non può essere membro di Array.


Descrizione generale
• Topologia – Figura 1 rappresenta una disposizione in ambiente “corporate”; dove più subnet ed apparati di rete (switch, router) sono impiegati per connettere un gran numero di client e server. Questa topologia è stata già ampiamente discussa nell’articolo “Progettare una soluzione con ISA Server su una rete semplice” (ndt: vedi ), quindi non verrà ripetuta.
  • Dispositivi di rete – Richiedono tutti un indirizzo IP sia per la configurazione che per il controllo da remoto. Questo rappresenta un interessante problema di sicurezza, dato che gli utenti possono modificare, a meno che non siano presenti specifiche limitazioni, le impostazioni di questi dispositivi. Dato che operano, a tutti gli effetti, come dispositivi TCP/IP (con indirizzo IP ed altro), condizionano il metodo di connessione utilizzato dai client verso ISA Server.
 
  • Switch – Sono dispositivi che trasmettono “direttamente” i pacchetti utilizzando l’indirizzo MAC di destinazione (Livello 2). Esistono dispositivi che operano anche in maniera più intelligente ma questa è la principale modalità di funzionamento richiesta. Generalmente, da quando il pacchetto è ricevuto a quando è inviato, non ne modificano il contenuto.
  • Router – Questi dispositivi “instradano” i pacchetti in basse all’indirizzo IP di destinazione (Livello 3). Modificano il contenuto del pacchetto conformemente alle regole impostate, così come definito negli RFC che ne controllano il comportamento. Proprio perchè modificano l’indirizzamento del pacchetto, è qui che nasce il problema del “default gateway” per i client SNAT. Un aspetto importante per i router è che ogni interfaccia ha un proprio indirizzo IP. Questo indirizzo IP sarà il “default gateway” per tutti quei dispositivi IP che vi si connetteranno.
Nota: il termine “router” è inappropriato per dispositivi xDSL e Modem analogici. Il termine “router” non è niente di più che un’invenzione del marketing per far credere che possa fare più cose di quello che può realmente fare. Questi dispositivi non sono altro che “switch” o perfino “hub” che possono fornire servizi limitati di NAT, DNS e DHCP. Questi non sono router, nel senso stretto del termine, in quanto non supportano i protocolli di routing come RIP e OSPF.
  • Server – Queste macchine devono essere configurate come client SNAT; cioè devono essere configurate con una default route che raggiunga il server ISA attraverso l’infrastruttura di rete. Dato che questi server non appartengono alla stessa subnet di ISA Server, configurare il “default gateway” con l’IP di ISA Server non è corretto.
  • Workstation – Queste macchine operano in un contesto di sicurezza leggermente diverso rispetto ai Server, in quanto abbiamo degli utenti che le utilizzano. Questo può richiedere configurazioni IP differenti a seconda del ruolo svolto dalla singola workstation.
   


• Configurazione con più Subnet – La divisone della rete TCP/IP in subnet permette all’amministratore di avere un maggior controllo della rete. Sfortunatamente questo comporta che il “default gateway” impostato sui client non è direttamente collegato alla capacità del client di raggiungere ISA Server. Pensiamo alla interfacce di rete come a delle porte in una casa: “default route” e “default gateway” definiscono “l’ultimo percorso possibile” per un dispositivo TCP/IP. Se l’indirizzo di destinazione non è sulla via davanti o sulla via nel retro della casa, vie già note, allora, prima di scartarlo, lo invieremo attraverso la porta che definisce l’ultimo percorso disponibile, la “default door”, nella speranza che, lungo quella via, riesca a raggiungere la destinazione.

Il modo come sono definiti i client SNAT è leggermente differente in questo scenario:
  - La macchina client deve aver definito, come “default gateway”, il router ad essa più vicino.
  - Una “default route” deve essere definita nel router più vicino ad ISA Server (standalone o array). La “default route” deve puntare all’indirizzo IP interno di ISA. Se ISA Server ha più indirizzi IP interni, l’indirizzo IP configurato nella “default route” deve essere l’IP di “default”, o IP Primario, dell’interfaccia di rete interna.
  - Se sono presenti altri router nella rete, questi devono essere configurati con una “default route” che indirizzi il traffico al router che, nel percorso di rete, più si avvicina al router a cui è connesso ISA Server. Questo può essere abbastanza impegnativo da implementare in scenari complessi.
  - ISA Server deve poter raggiungere, mediante la definizione di una route “classless”, tutte le subnet. Questo significa che ISA Server deve sapere come raggiungere tutte le subnet che fanno parte della infrastruttura a cui è connesso. In caso contrario, nessuna delle route di “default” del mondo potrà mettere in collegamento ISA Server con i propri client. Una route “classless” non è altro che una route che comprende tutte le subnet presenti nella propria infrastruttura. Questo è ottenuto in Figura 1 assegnando alla subnet “192.168.0.0” una route che utilizza una subnet mask più grande di quella che solitamente viene definita, “255.255.0.0”. L’effetto, in questo caso, è quello di far si che ISA utilizzi come default route, per tutti gli indirizzi IP di destinazione che hanno “192.168” nel primo ottetto, il router a lui più vicino. Questa procedura è molto più semplice che non quella di inserire una route per ciascuna subnet presente nella infrastruttura.
   

La Figura-2 illustra questo concetto. Ogni switch fa si che tutte le macchine a cui è connesso utilizzino come default gateway (DG) il router a lui più vicino. Ogni router, di conseguenza, salendo la catena utilizza, come default route (DR), il router a lui più prossimo, ad eccezione dell’ultimo che utilizza, come default route, ISA Server.
Bisogna notare che lo switch a cui è connesso ISA Server utilizza “RTR3” come default gateway. Mentre questo sembra creare un potenziale loop, bisogna ricordare che ISA Server è differente da ogni altro server presente nella subnet; in quanto ha un proprio default gateway impostato sull’interfaccia esterna.
In questo modo, per raggiungere tutte le “destinazioni sconosciute”, ISA Server utilizzerà l’interfaccia esterna.

Figura 2

• Definire la route “classless” – È necessaria una certa dimestichezza con il calcolo binario applicato al TCP/IP in quanto la definizione della subnet mask è la chiave del routing “classless”. La subnet mask è fondamentale per il confronto binario. Si sviluppa in termini di potenze del 2 (1,2,4,8) e non seguendo una logica lineare (1,2,3,4). Il valore 252 è un valore valido per la netmask, il 253 invece no, in quanto crea un “buco” nei bit che compongono la maschera. Il termine “classless” definisce una rete che è logicamente più estesa di quanto lo sia effettivamente la rete fisica. Se definiamo una rete come 192.168.0.0/24, abbiamo creato una rete che ha 254 host per 256 subnet. Se definiamo una route come 192.168.0.0/16, forziamo lo stack TCP/IP a vedere la rete come un unico grande subnet logica di 65534 host, tutti visibili tramite la medesima interfaccia.

• Impostare la route “classless” – Per poter impostare una route “classless” che risponda allo scenario di Figura-1, dobbiamo utilizzare il seguente comando:
route –p add 192.168.0.0 mask 255.255.0.0 192.168.0.1
il parametro “–p” fà si che la route inserita sia ”persistente”, o “permanente”. Le route aggiunte manualmente non sono “persistenti” in quanto si perdono al reboot, a meno di non utilizzare il parametro “-p”. Inutile dirlo che questo può essere fonte di confusione. Quindi utilizzare il parametro “-p” è fondamentale; impostiamolo come sopra o non sarà accettato.


• Configurazione del/dei DNS – nel/nei server DNS interno/i facciamo una “copia” della zona esterna (non una zona secondaria), che mappa l’indirizzo IP interno dei server pubblicati. Questo permetterà ai client interni di risolvere i nomi esterni con indirizzi IP interni, evitando così gli errori “failed to create packet filter” molto comuni in questi casi. È da notare che è necessario avere due server DNS fisicamente distinti. Un metodo è quello di collocare la “vera” zona esterna su un server DNS collocato sulla stessa macchina di ISA Sever.

• Proteggere la rete con il Firewall client – Spesso vorremmo il controllo totale del traffico di rete. Potremmo non volere che i client si connettano direttamente ad ISA Server senza prima aver fornito le proprie credenziali.• Configurazione del router – Primo, i router non devono essere configurati con la “default route” verso un ISA Server. Questi devono essere configurati con le sole route che permettono la comunicazione fra subnet, ma nessuna che indirizzi il traffico ad ISA Server. Potremmo configurare delle “blackhole route”, o scartare tutti i pacchetti che non siano indirizzati ad una delle subnet locali. Questo fa sì che non siano possibili connessioni ad Internet da parte di client che non utilizzano il firewall client.

• Configurazione di ISA Server

  - Creare Protocol rule per “ciascuna tipologia di client”; utilizzare restrizioni su base utente/gruppo che rispondano alle specifiche necessità dell’utente. Uno dei membri di un gruppo potrebbe avere la necessità di accedere ad Internet con modalità diverse rispetto ad un altro membro del medesimo gruppo.
  - Verificare di aver inserito correttamente nella LDT il nome del dominio interno; questo è critico per il corretto processo di risoluzione dei nomi da parte del firewall client.

• Configurazione dei client di ISA Server – Impostare la configurazione automatica conformemente al proprio scenario, operazione descritta in dettaglio nell’help in linea di ISA. Porre particolare attenzione alle impostazioni del “WPAD” sul server DNS ed il DHCP, in quanto sono critici per il corretto funzionamento del firewall client. Verificare la correttezza delle impostazioni prima di installare il software su un qualunque client.

• Configurazione del client – Affinché le postazioni di lavoro utilizzino ISA come unico punto di accesso ad Internet dobbiamo installare il firewall client. In questo modo, il client può mantenere inalterato l’IP del proprio default gateway. Questo aspetto è critico in scenari con più subnet.

• Applicazioni Server – DNS, SMTP, POP3, WEB e simili tipicamente non rispondono bene in presenza di software Winsock proxy visto che, in senso stretto, non sono applicazioni Winsock. Dunque dovremo collocare le applicazioni server nella stessa subnet di ISA Server così che possano essere configurati come un client SNAT. Dato che abbiamo configurato i router affinché scartino tutti i pacchetti con destinazione non interna, dobbiamo impostare il default gateway dei server con l’indirizzo IP interno di ISA Server. Questo non interferisce con la comunicazione interna visto che ISA è in grado di instradare il traffico alle LAN interne grazie alla route “classless” che è stata definita.

Informazioni sull’autore
Jim Harrison, MCP(NT4/W2K), A+, Network+,ET1(SW)(RET), sposato con quatto figli. Attivo online fin dai tempi del Kaypro-4, su cui ha realizzato la sua prima BBS.


ISAServer.it ed i suoi Autori non sono responsabili per danni di qualsiasi tipo - inclusi danni per perdita o mancato guadagno, interruzione dell'attivita', perdita di informazioni commerciali o altre perdite pecuniarie - derivanti o correlati all'utilizzo o all'incapacita' di utilizzo delle informazioni e degli esempi riportati - per quanto testati e funzionanti -. Le informazioni e gli script sono "cosi' come sono", senza garanzia di nessun tipo. L'intero rischio derivante dall'uso delle informazioni e degli script di esempio e' interamente a proprio carico. L'utilizzo è consentito solo accettando le presenti condizioni.

 
 
 
 
 
 
 
 
No banner in farm


ISAserver.it - No. 1 Unofficial European web site on Microsoft ISA Server / Forefront TMG

Pubblicità su ISAserver.it - Note d'uso - Privacy
Copyright© 2004-2008 Luca Conte Tutti i diritti riservati.