Ci sono diversi casi in cui un dominio viene registrato presso un fornitore mentre l’hosting (o un altro servizio) è altrove; i casi più comuni che mi vengono in mente sono i blog su Blogger e i Tumblr che desiderano utilizzare un proprio nome a dominio mantenendo la comodità di una piattaforma pubblica, oppure quando il dominio di primo livello che avete scelto non è gestito dall’hoster: un caso molto comune sono i domini .it su un provider statunitense. In quest’ultimo caso, poiché non sono supportati i .it, è necessario registrare il dominio altrove e poi intervenire sul DNS in modo da “puntare” il dominio sui server corretti.

Tanto per fare chiarezza sui termini: il “registrar” è l’entità presso la quale avete registrato e pagato il nome a dominio, l’”hoster” è il fornitore di servizi che vi fornisce i server (o parti di essi) sui quali “girano” i servizi legati al dominio. Di solito coincidono, ma quando non è così è necessario intervenire sui DNS.

Gestire le funzioni di base di un DNS non è difficile, ma presuppone la conoscenza di alcuni concetti che vanno capiti prima di effettuare modifiche; normalmente è difficile fare danni irreparabili, ma se si fanno pasticci si rischia di rendere irraggiungibile il proprio sito per diverse ore. Il tutto è reso ancora più scomodo dal tempo di propagazione: prima che le modifiche vengano “recepite” da tutto internet è necessario attendere alcune ore, in certi casi anche 24/36.

Se desiderate una breve spiegazione a proposito del DNS, ne avevo scritto tempo fa; in questo post vorrei parlare delle poche cose da sapere nel caso si voglia gestire il proprio dominio.

Ciascun registrar, l’entità presso la quale avete “comprato” il nome a dominio, gestisce uno o più server DNS. Questi server usano un database nel quale ai nomi a dominio (detti anche “zone”) sono associati diversi record; quelli ai quali siamo interessati sono i record NS, A, CNAME e MX. (Ce ne sono molti altri, ma per i nostri scopi basta gestire questi). Una zona (dominio) comprende uno o più host che erogano i servizi. (In realtà quello che viene chiamato “database” è un semplice file di testo che contiene le diverse righe dei record).

La modifica dei record si fa generalmente tramite il pannello di controllo del registrar, con modalità che cambiano di volta in volta, ma in genere si tratta di interfacce abbastanza intuitive.

Uno dei record più importanti con il quale si ha a che fare è NS. Esso stabilisce chi sono i server DNS per la zona; viene indicato nella forma:

NS	nome.delserver.com.

Si possono specificare piu’ DNS per una singola zona, ma non è possibile sapere quale sarà usato dai resolver: dipende dall’implementazione del resolver stesso, quindi tutti vanno tenuti aggiornati.

In alcuni casi, la modifica di questo record è tutto quello che ci serve. Facciamo un esempio abbastanza comune: un dominio .it registrato in Italia e hostato presso un provider statunitense, per esempio Dreamhost. Una volta che il pannello di DH è pronto per “accogliere” il dominio, è sufficiente modificare i record NS sul registrar in modo che puntino ai DNS americani. In questo modo, la registrazione rimane in Italia, tutto il resto passa a Dreamhost, che diventa responsabile pubblicamente per tutti gli host di quel dominio. Modificando NS, la palla passa a DH che è già pronto per ospitare il nuovo dominio nei suoi DNS; tempo della propagazione e tutto funzionerà alla perfezione.

State attenti: il nome del server va scritto con il punto in fondo, per indicare che è proprio quello e non è un host di quel dominio. Se manca il punto il record verrà interpretato come nome.delserver.com.miodominio.it, e non funzionerà più nulla.

Nel caso non si dovesse e/o potesse modificare il nameserver è necessario intervenire su altri tipi di record. E’ il caso, per esempio, di Tumbr associato a un proprio dominio. Tumblr non fornisce server DNS, quindi dovrò modificare un record A.

Un record A traduce un nome host in un indirizzo IP:

nome IN A    12.34.56.78

dato che la zona è quella del dominio miodominio.it, la riga qui sopra dice che l’host nome.miodominio.it risponde all’indirizzo 12.34.56.78.

Se la riga fosse:

tumblr IN A    72.32.231.8

avremmo appena creato un dominio di terzo livello tumblr.miodominio.it che punta ai server di Tumblr, dove il nostro tlog, opportunamente configurato, è pronto per servire le pagine. Potete trovare maggiori informazioni in un altro mio post.

E’ possibile assegnare più indirizzi IP allo stesso host; essi verranno restituiti come risultato della query DNS e sta al resolver del client decidere quale usare. E’ un meccanismo che talvolta viene utilizzato per ottenere un rozzo bilanciamento di carico tra server distinti.

Spesso un singolo server ospita diversi servizi, accessibili con un nome diverso. Il caso più comune è il seguente:

www IN A    12.34.56.78
ftp IN A    12.34.56.78

In questo caso il singolo host risponderà sia su www.miodominio.it che su ftp.miodominio.it.

C’è un altro modo di ottenere questo risultato, e questo ci introduce all’uso di un altro tipo di record: CNAME. Questo tipo di record permette, usando le parole di Wikipedia, “di collegare un nome DNS ad un altro. La risoluzione continuerà con il nuovo nome indicato dal record CNAME. Questa funzione è molto utile quando, per esempio, sullo stesso server sono disponibili più servizi come FTP, HTTP ecc operanti su porte differenti. Ciascun servizio potrà avere il suo riferimento DNS (ad esempio ftp.example.com. e www.example.com.“.

L’esempio qui sopra potrà quindi essere configurato anche così:

www IN A      12.34.56.78
ftp IN CNAME  www.miodominio.it.

Attenzione, sempre, al punto finale quando si scrive un nome FQDN completo. In questo caso il server DNS restituirà al client che richiede ftp.miodominio.it non un indirizzo IP, ma un altro nome (www.miodominio.it); verrà quindi effettuata una seconda query, dalla quale otterremo finalmente l’indirizzo desiderato. Si dice che ftp.miodominio.it è un “alias” di www.miodominio.it.

Utilizzando i record descritti fin qui si possono gestire la quasi totalità delle configurazioni dove il registrar è separato dall’hosting. Per completezza vediamo l’ultimo record, MX.

Il record MX è molto importante per il recapito della posta perché contiene il nome del server deputato a ricevere messaggi quel particolare dominio. E’ fatto così:

MX	10	posta.miodominio.it.
MX	20	mail.provider.com.

In questo esempio il dominio ha due mail server. Il primo, più importante, è quello con il campo priorità più basso (10) ed è il primo che verrà contattato. Se esso non risponde si passa all’altro (se c’è) che fa da backup e si incaricherà di inoltrare i messaggi al server principale non appena esso tornerà online; impostando due priorità uguali si può ottenere una specie di bilanciamento di carico. Maggiori informazioni sul recapito della posta, il protocollo SMTP e una breve prova pratica li trovate in un mio vecchio post.

La modifica del record MX è necessaria, per esempio, nel caso si utilizzi Gmail per per proprio dominio; è un servizio fantastico ed è gratuito fino a 50 utenti. In pratica Google vi regala una Gmail personalizzata per il vostro dominio, insieme a calendario, contatti condivisi, Google Docs e Google Site.

Vi ricordo che le modifiche hanno bisogno di 24/36 ore per essere propagate a tutto il mondo: una volta cambiati i parametri sul pannello, il server DNS aggiorna (di solito automaticamente) il serial number del record SOA, che serve per sapere se i dati sono stati modificati e quindi aggiornati su tutto il sistema DNS mondiale.

(Alcuni aspetti sono stati volutamente semplificati: una trattazione rigorosa richiede tempo e sarebbe comunque inutile, vista la quantità di materiale reperibile in rete al riguardo.)

Scenario 1: siamo connessi ad internet tramite un firewall con politiche restrittive che non permette il traffico verso i server di cui abbiamo bisogno e/o verso alcuni siti web.

Scenario 2: siamo connessi ad internet tramite una rete non fidata (internet cafè, lanparty, hackmeeting) e sospettiamo che il nostro traffico possa essere sniffato da qualche malintenzionato.

In questi casi, avendo a disposizione un account su un server SSH pubblico raggiungibile su una qualunque porta (anche diversa dalla stardard TCP/22) possiamo utilizzare il dynamic port forwarding, un sistema particolarmente comodo di veicolare traffico criptato bypassando eventuali restrizioni.

Il port forwarding dinamico (dynamic port forwarding) è un meccanismo trasparente che supporta il protocollo SOCKS4 o SOCKS5. Invece di configurare un port forwarding da porte specifiche dell’host locale verso porte specifiche del server remoto, esso permette di specificare un server SOCKS che può essere utilizzato dalle applicazioni. Il Client SSH apre una porta sull’host locale e simula un server SOCKS per ciascuna delle applicazioni opportunamente configurate. Quando queste applicazioni devono connettersi a servizi come HTTP, FTP, POP3, SMTP ecc., esse “parlano” al client SSH che simula un server SOCKS e crea un port forwarding verso il server SSH remoto, al quale inoltra il traffico crittografato dal protocollo SSH.

In pratica tutto il traffico in uscita dalle applicazioni configurate per usare il server SOCKS locale viene incapsulato nella connessione SSH verso il server remoto, da dove esce e viene poi veicolato verso i server di competenza. Per effetto di questo meccanismo otteniamo il duplice risultato di bypassare le eventuali regole restrittive del firewall (in quanto la connessione in uscita è solo verso il server SSH), e di criptare tutto il traffico dal client fino al server SSH, nascondendolo agli sguardi indiscreti.

Il requisito principale è un accesso shell via SSH a un server che possiamo raggiungere: potrebbe essere anche un computer a casa che abbiamo configurato per essere raggiungibile dall’esterno con varie tecniche, ad esempio DynDNS. Praticamente tutte le distribuzioni linux contengono OpenSSH, disponibile anche per Windows e su OS/X si abiliterà il login remoto. Il giochino funziona anche se avete un account su un server di un provider che fornisce una shell SSH, ad esempio DreamHost, e riuscite a raggiungerlo dalla vostra posizione. I client sono Putty per Windows e nativi negli altri casi.

Putty può essere usato tramite linea di comando o interfaccia grafica. La sintassi per la linea di comando è la seguente:

putty -ssh -D 9999 -P 80  serverssh.dominio.com

dove:

• -ssh indica usare il protocollo SSH.
• -D 9999 indica al client di ascoltare sulla porta 9999/TCP. Potete utilizzare qualunque porta libera sul vostro client: controllate con netstat -an -p TCP | findstr LISTENING (Windows) o netstat -an -p TCP | grep LISTEN (OS/X e linux).
• -P 80 identifica la porta sulla quale è in ascolto il server SSH remoto. Se è la default TCP/22 non serve indicarla.
• serverssh.dominio.com è il nome del server SSH. Si può usare anche l’indirizzo IP.

Se si usa l’interfaccia grafica bisogna stabilire una normale connessione, poi aggiungere un tunnel nel menu Connection –> SSH –>Tunnels compilando il campo “Source port” (la porta locale di ascolto),  lasciare vuoto “Destination”, scegliere “Dynamic” e cliccare su “Add”

La sintassi per linux e OS/X è:

ssh -D porta_locale utente@serverssh

Una volta autenticati e stabilita la connessione si può minimizzare la finestra della console senza chiuderla e passare alla configurazione delle applicazioni. In Windows si possono utilizzare tutte quelle che supportino l’utilizzo di un server SOCKS. Praticamente tutti i browser lo fanno e molti altri programmi hanno il supporto, per esempio Pidgin.

In Firefox la configurazione si fa tramite il menu Strumenti –> Opzioni –> Avanzate –> Rete  –> Impostazioni –> Configurazione manuale del proxy –> Host SOCKS e si specifica “localhost” (o 127.0.0.1) e la porta locale sulla quale ascolta il client SSH (9999 nell’esempio qui sopra).

Una comoda alternativa è rappresentata da una categora di tool chiamati socksifier, che permettono a qualunque applicativo di connettersi all’esterno tamite SOCKS. Uno dei più utilizzati per Windows è gratuito e si chiama WideCap. Su linux si può usare tsocks, avendo cura di modificare prima il file /etc/tsocks.conf specificando 127.0.0.1 nella variabile “server” e la porta desiderata in “server_port”.  Per OS/X il supporto è nativo: Preferenze di sistema –> Network –> scegliete l’interfaccia con la quale siete collegati ad internet –> Avanzate –> Proxy –> Abilitare “Proxy SOCKS” e compilare i capi “Server” (localhost) e porta (quella scelta precedentemente). In questo modo tutte le connessioni uscenti da quella scheda di rete transiteranno attraverso il proxy SOCKS, e non ci sarà bisogno di toccare la configurazione delle applicazioni poiché il meccanismo è completamente trasparente.

Questo è un breve screencast che mostra come utilizzare Putty e Firefox per ottenere un port forwarding dinamico.

(Utilizzate questi metodi con giudizio: bypassare le policy di sicurezza aziendali vi potrebbe mettere nei guai.)

Pare che la moda del momento sia chiedere che i propri dipendenti non usino Facebook e non chattino su MSN. Pur non essendo d’accordo, credo si tratti di una richiesta lecita se fatta da chi paga sia le persone che la banda(*).

I sistemi di content filtering possono essere costosi e/o impegnativi nella manutenzione per aziende di piccole dimensioni che magari dispongono a malapena un firewall. Ci sono un paio di tecniche che permettono di filtrare abbastanza agevolmente senza dover fare alcun investimento. Il principio è controllare le query DNS, intercettando i domini da bloccare e/o utilizzando l’apposito servizio gratuito fornito da OpenDNS. Della situazione speculare, il blocco totale con pochi domini in whitelist avevo già parlato qui.

Come spesso accade, in azienda c’è un piccolo server Windows 200x o Small Business Server che adempie alle solite funzioni (AD controller, file e print server, DNS, DHCP ecc ecc.); concentriamoci sul DNS. In questo esempio mi interessa bloccare il traffico verso Facebook, quindi ne carico una pagina e do una scorsa al sorgente HTML, dal quale mi accorgo che gli unici domini interessati sono Facebook.com e fbcdn.net. Provvedo quindi a creare due nuove zone di ricerca diretta primarie, integrate in AD e replicate su tutti i server DNS proprio per quei due domini (facebook.com e fbcdn.net).

Il risultato di questa operazione sarà che il mio server sarà convinto di essere autoritativo per i domini in questione e non si preoccuperà di recuperare dai suoi forwarder, o dai root server, l’indirizzo IP degli host di quei domini(**). Non avendo alcun record di tipo A definito, restituirà al client un messaggio di host sconosciuto (“www.facebook.com non esiste“); otteniamo così il risultato di rendere Facebook non raggiungibile. (Naturalmente devo attendere che la cache DNS sui client sia scaduta o forzarne il refresh con ipconfig /flushdns)

Per evitare che un utente più smaliziato usi un server DNS pubblico, bisogna bloccare sul firewall tutto il traffico in uscita sulla porta 53 sia TCP che UDP, tranne quello proveniente dai server DNS interni.

Per bloccare Messenger e per un controllo su altre categorie di siti, si può usare il servizio gratuito offerto da OpenDNS, dove basta registrarsi, configurare il proprio server DNS con gli appositi forwarder, registrare e confermare il proprio network seguendo le semplici indicazioni (c’è anche un client per chi non ha un IP pubblico statico) e attivare il content filtering. Questo è un esempio di configurazione che blocca Messenger ed altre categorie di siti.

Queste impostazioni che vedete sono disponibili anche nella versione gratuita, che assolve egregiamente ai suoi scopi. Si possono anche specificare singoli domini da blacklistare. Il servizio offre anche un po’ di statistiche. Le pagine bloccate vengono catturate e viene restituita una pagina con messaggi personalizzabili e logo dell’azienda.

E’ evidente che questi metodi non resistono ad un utente con competenze evolute (non riuscirete a bloccare il traffico a un ufficio di sistemisti), ma per la maggior parte dell’utenza è uno scoglio insormontabile.

Pregi:

• Sono gratuiti.
• Sono molto semplici da implementare.
• Sono facili da spiegare ai clienti.
• Richiedono pochissima manutenzione.
• Sono adatti a aziende piccole o medio-piccole.
• Sono facilmente reversibili alla configurazione “tutto aperto”.

Difetti:

• Pasticciare con le query DNS non è affatto elegante.
• Ci si affida a un servizio esterno con tutto ciò che ne consegue in termini di sicurezza, privacy e continuità del servizio.
• Utilizzare un servizio come OpenDNS che raccoglie un database di query e lucra sul traffico rediretto è comunque un compromesso.
• Non scalano bene nel caso le esigenze di controllo diventino più granulari.
• Non sono adatti ad aziende più grandi con infrastrutture più complesse.

(*)Ulteriori considerazioni sul filtrare i contenuti internet sono al di fuori dello scopo di questo post.

(**)Semplificazione. Per una spiegazione più approfondita, leggimi qui.

Tapullo: “Non esiste parola che si possa paragonare a Tapullo. Trattasi di riparazione di fortuna che spesso dura nel tempo e aggiunge nuove funzionalità (…). I Genovesi, da sempre parsimoniosi, sono abili nei Tapulli. I Tapulli vengono mostrati con fierezza agli amici, alcuni diventano perfino leggendari e spesso i grandi marchi vi si ispirano per migliorare i propri prodotti. A volte viene usato il termine per denigrare una riparazione di fortuna (raro), o per indicare una soluzione temporanea (più comune).” Fonte.

Ricetta quick’n dirty per creare una VPN tra un client remoto ed un server, entrambi con sistema operativo Windows. Destinata a cuochi mediamente abili. Versione routed(*).

Ingredienti:

• Un host che faccia da server, con IP privato statico (es: 192.168.1.2/24), collegato ad internet, acceso 24/7 e a cui il router inoltri almeno una porta TCP(**) (Es: TCP/11900). Windows 2000 o successivi, non necessariamente Server.
• Un client con connessione ad internet con IP privato di classe diversa dal server (es: 192.168.254.0/24).
• OpenVPN.

Esecuzione:

• Generare una chiave simmetrica key.txt tramite l’apposita utility e copiarla nelle cartelle “config” di OpenVPN di entrambi gli host.
• Scegliere una terza subnet diversa da entrambe le subnet degli host coinvolti. Es: 172.30.0.0/16.
• Aggiungere sul default gateway (tipicamente il router) della rete del server una rotta statica che inoltri tutto il traffico destinato alla rete 172.30.0.0/16 verso l’IP privato del server (192.168.1.2).
• Registrarsi su DynDNS e creare un hostname per il server (es: mioserver.dnsalias.net).
• Installare sul server il client DynDNS (versione per 200x Server in fondo alla pagina) e configurarlo per usare l’hostname appena creato. Accertarsi che il relativo servizio parta automaticamente.
• Installare OpenVPN su entrambi gli host, e inserire nelle cartelle “config” di OpenVPN i ripettivi file di configurazione, con estensione .ovpn.

File: client.ovpn
remote mioserver.dnsalias.net
dev tap
proto tcp-client
rport 11900
ifconfig 172.30.1.2 255.255.0.0
route 192.168.2.0 255.255.255.0 172.30.1.1
secret key.txt
verb 3

File: server.ovpn
dev tap
proto tcp-server
lport 11900
ifconfig 172.30.1.1 255.255.0.0
secret key.txt
verb 3

• Sul server avviare il servizio “OpenVPN Server” e impostarne l’avvio automatico.
• Sul client, collegato ad internet con una connessione internet diversa dal server,  eseguire “OpenVPN GUI” in modalità amministratore, cliccare col tasto destro sull’icona nella systray e scegliere “connect”.
• Effettuare dei test di connettività. In caso di problemi, i log di OpenVPN sono molto esplicativi già a verb 3.

Guarnire con quanta più banda possibile e servire con due righe di istruzioni per l’utente.

(*)Le due reti non sono in bridging, configurazione comunque possibile ma leggermente più complicata.

(**)Si può usare anche UPD, che sarebbe il default di OpenVPN, ma su alcuni router SOHO non si possono inoltrare le relative porte.

Universal Plug and Play, secondo Wikipedia, è un insieme di protocolli di rete che permette ai dispositivi che lo implementano di semplificare drasticamente la loro integrazione all’interno di una rete. Il nome è mutuato da Plug-and-play, una tecnologia che permette di collegare un dispositivo ad un computer e averlo immediatamente pronto all’uso. La similitudine si riferisce alla possibilità di alcuni dispositivi di collegarsi, autoconfigurarsi e annunciare i propri servizi alla rete senza necessità di configurazione preventiva. Per tutti i particolari più tecnici, vi rimando alla voce di Wikipedia che ho linkato qui sopra.

Una delle categorie di oggetti che supportano UPnP sono i router per uso casalingo o per piccoli uffici (SOHO), che tramite un’estensione del protocollo, detta Internet Gateway Device Protocol, permettono ai client in grado di sfruttare la tecnologia di compiere una serie di azioni; le più comuni sono il reperimento dell’indirizzo pubblico della connessione, la lista della tabella di inoltro delle porte TCP e UDP e la relativa modifica.

Proprio questo ultimo aspetto contribuisce a semplificare parecchio la vita degli utenti: per pubblicare un servizio o abilitare il traffico in ingresso verso un client è necessario configurare il NATP sul router, il che richiede conoscenze tecniche non banali. Se il software che stiamo utilizzando ed il router supportano UPnP è sufficiente assicurarsi che le rispettive voci siano abilitate e non ci sarà bisogno di fare nessuna configurazione.  L’esempio più comune sono i software P2P: per massimizzare la velocità di trasferimento è necessario che il traffico in ingresso su una o più porte TCP sia inoltrato verso il client su cui sta girando il software; programmi come µTorrent o Transmission sono in grado di configurare autonomamente il router in modo da ricevere il traffico entrante, rendendo il trasferimento molto più veloce.

Sfortunatamente, in tutto questo c’è un problema: UPnP non supporta l’autenticazione e presume che tutti gli host della rete siano sicuri e a tutti garantisce i privilegi sufficienti per effettuare modifiche alla configurazione, il che potrebbe rappresentare un buco nella sicurezza; è stato ipotizzato che un programma Flash opportunamente scritto potrebbe aprire alcune porte nel router all’insaputa dell’utente, esponendo quindi il client all’attacco dall’esterno con una semplice visita ad un sito contenente codice malevolo, anche se a memoria non ricordo di aver mai sentito parlare di qualcosa del genere. Per questo motivo, e per il fatto che si tratta comunque di un protocollo di cui l’utente è meglio sia al corrente, su parecchi dispositivi è disabilitato per default e va abilitato esplicitamente: controllate sul vostro router.

Scenario: un firewall con due interfacce WAN collegate a due router ADSL e configurate in failover. Cade la linea principale e la rete perde connettività: cosa è successo?

Ad una prima indagine mi accorgo che tutti gli host accedono regolarmente ad internet via linea di backup ma non funziona la risoluzione dei nomi, quindi è praticamente tutto fermo. La rete è servita da un Windows 2003 server che, tra gli altri, ha i ruoli di DNS server, mail server e webmail server.

La causa della risoluzione  non funzionante è il server che, scopro, non ha connessione ad internet. Come è possibile che tutta la rete acceda ad internet tranne il server? Verificato che il firewall non abbia policy restrittive e spulciati i log relativi, mi concentro sulla sua tabella di NAT.

Dato che il server è pubblicato per i servizi SMPT e HTTP, esiste una regola esplicita che natta l’IP privato sull’IP pubblico della WAN primaria, e fin qui tutto bene. Dopo una telefonata chiarificatrice con un collega, mi rendo conto che manca completamente la regola che NATti il server anche sull IP pubblico della linea di backup. Modifico la regola principale esplicitando l’interfaccia di outbound, che prima era ANY, e creo un’altra regola per il NAT sull’IP di backup, sulla relativa interfaccia. Come per magilla, la connettività riappare e il server DNS ricomincia a fare il suo mestiere.

Le VPN verso le sedi remote vengono riattivate facendo modificare alle filiali l’IP del peer da cui la connessione viene accettata, e specificando nel “local ID peer” l’IP pubblico della connessione di backup perché il router relativo, in comodato d’uso, fa a sua volta un NAT. Al momento del ripristino della linea principale, si effettuerà un rollback delle modifiche.

Per scongiurare problemi in futuro, rimangono da fare i seguenti passi:

• configurare un record backup MX nel DNS del dominio di posta, in modo che i messaggi possano essere anche ricevuti, oltre che inviati, quando è attivo il failover;
• aggiungere una regola di NAT sulle interfacce opportune per pubblicare l’IP privato del server anche sull’indirizzo pubblico della linea di backup.

Perché tutto ciò non è stato testato prima della messa in produzione? Per i soliti motivi: uno dei due provider tardava a fornire la connettività di backup e l’altro ha sbagliato il contratto modificando in corso d’opera la classe degli IP pubblici assegnati; Il cliente aveva bisogno di lavorare da subito e non c’è mai stato modo di fare un collaudo vero e proprio.

Iperf è uno strumento per misurare l’ampiezza di banda di cui avevo già accennato qui. Il sito originale nel frattempo è sparito ma si trovano parecchi tutorial, dei quali vi segnalo questo. Per fortuna il progetto non è stato del tutto abbandonato e sebbene il codice originale sia sempre lo stesso, Google Code ospita JPerf.

Si tratta di un frontend grafico pensato per semplificare l’utilizzo di Iperf e aggiungere dei grafici abbastanza gradevoli. Permette di salvare risultati e configurazione mentre per i grafici ci si deve arrangiare con uno screenshot, almeno al momento. Si basa su Java ed è quindi multipiattaforma.

Molto utile per la redazione delle relazioni tecniche, croce e deliza dei sistemisti; ha il vantagio di produrre risultati abbastanza comprensibili anche per i non addetti ai lavori, perlomeno con le impostazioni predefinite.

Quasi ogni volta che mi imbatto in un IBM AS/400 ho sempre lo stesso problema: il server è irraggiungibile dall’esterno della sua subnet. Anche se firewall, router, NAT, frizzi lazzi e mazzi sono perfettamente configurati, non si riesce ad accedere dall’esterno, fosse anche la subnet a fianco, la WLAN o la DMZ.

Ormai vado a colpo sicuro e chiamo il sistemista AS: so già che manca il default gateway nella configurazione di rete dell’AS che, in queste condizioni, non è in grado di indirizzare i pacchetti dove potranno essere adeguatamente ruotati instradati.

Del perché mi imbatta spesso in questo problema, mi sono fatto un paio di convinzioni: intanto nella maggior parte dei casi questi baracconi son talmente vecchi che vanno ancora a legna, e all’epoca della loro installazione non si usava neppure il TCP/IP, preferendo lo SNA 5250; figuriamoci se c’era la necessità di uscire dalla subnet. Costretti dalla diffusione di Ethernet a scapito di Twinax a passare a TCP/IP, i sistemisti AS, un po’ pigri un po’ capre, hanno spesso omesso di configurare completamente i parametri di rete, limitandosi a compilare indirizzo IP e subnet mask.

Preferisco evitare di mettere le mani in quei cosi, meglio chiamare chi li conosce bene.

Lo studio medico di un amico ha una rete di computer non recentissimi, che utilizzano esclusivamente un applicativo client-server il cui motore gira su server Windows 2003. Niente Office, niente mail, niente altro.
La rete non aveva connessione ad internet, e grazie a questo tutto ha funzionato perfettamente fino ad ora: le macchine, benché vecchie, sono veloci, non hanno antivirus né spazzatura inutile installata; non sono mai intervenuto per alcun problema che non fosse la morte naturale di un PC, e il mio lavoro finora si era limitato all’installazione del server e di qualche stampante di rete.(*)

Si è presentata la necessità di collegare via internet lo studio con la ASL per la prenotazione online degli esami diagnostici, ed io ho cominciato a sudare freddo. Per fortuna Claudio è molto ragionevole ed ha capito subito le mie perplessità, abbiamo quindi convenuto che la cosa migliore da fare fosse filtrare l’accesso ad internet permettendo solo il traffico verso il sito dedicato, escludendo tutto il resto.

Trattandosi di una fase di test, per il momento ho preferito non far spendere allo studio qualche centinaio di euro per l’acquisto di un firewall; per diversi motivi l’istallazione di un vecchio PC che facesse da gateway non era praticabile/desiderata, quindi ho riflettuto su quale potesse essere la soluzione più semplice.

Scartata l’ipotesi di un proxy, ho deciso di installare DNS sul server, disabilitando le query ricorsive. Questa impostazione fa sì che la risoluzione dei nomi di domino venga fatta dal server esclusivamente con le sue risorse, senza inoltrare la richiesta ai suoi forwarders.

A questo punto, andando in gestione DNS, nelle “Zone di ricerca diretta” è sufficiente aggiungere una nuova zona per il dominio di secondo livello che si desidera risolvere, ed aggiungere al suo interno gli host A che ci servono, specificandone l’IP pubblico, risolto in precedenza tramite nslookup su un PC con un normale accesso ad internet. La procedura funziona anche con i domini di terzo e quarto livello.

Una volta installato il router, e configurato il servizio DHCP in modo che serva il corretto indirizzo del server DNS, il gioco è fatto: i client sono in grado di navigare solo sul sito la cui zona  stata configurata sul server, mentre il resto dei domini non vengono risolti poiché sono state disabilitate le query ricorsive.

E’ chiaro che si tratta di un metodo rudimentale, ma fa quello che deve fare senza troppe complicazioni.

Contro:

• Non è il massimo dell’eleganza.
• E’ facilmente aggirabile da un utente esperto.
• Va bene se la navigazione deve essere permessa solo verso pochi domini, dopodiché scala molto male.
• Se i domini da risolvere cambiano IP, la modifica non si propaga e ci costringe a modificare a mano gli indirizzi.
• Non blocca la navigazione tramite indirizzo IP.

Pro:

• E’ gratuito.
• Si configura in 10 minuti.
• Si basa su un servizio robusto (DNS di Microsoft lo è), e non richiede software di terze parti.
• E’ di semplice implementazione.
• Riduce il numero di asset da gestire.

(*) Questo dimostra quello che predico da sempre: PEBKAC.

Ritorno sulle impostazioni e parametri delle connessioni ADSL Telecom di tipo business per puntualizzare alcune cose.

I parametri della linea sono: VPI e VCI rispettivamente 8 e 35, encapsulation LLC, QoS UBR, protocollo RFC1483 routed. Per questo tipo di linea vengono forniti in genere almeno quattro IP fissi, ed il foglio che lascia l’omino Telecom contiene due classi di indirizzi chiamati IP LAN e IP punto-punto (o IP WAN).

Se avete un router di proprietà, ecco come impostarlo.

Intanto fatevi un’idea di come sono fatte le classi di indirizzi; nessuno fa i conti a mano, utilizzate l’ottimo Online IP calculator.

Facciamo un esempio pratico(*): sul foglio, spesso scritto a mano con pessima calligrafia e fotocopiato da una Xerox degli anni ’50, ci sono:

IP LAN: 78.62.124.200 / 255.255.255.248. Il tool ci dice che abbiamo a disposizione una classe da 8 indirizzi (78.62.124.200 – 78.62.124.207), di cui possiamo utilizzarne 6, poiché il primo (.200) identifica la rete e l’ultimo (.207) il broadcast.

Punto-punto: 84.81.188.200 / 255.255.255.252    Stessa cosa: ma solo 4 indirizzi (84.81.188.200 – 84.81.188.203 ) con 2 utilizzabili.

A questo punto impostiamo IPoA (IP over ATM) e mettiamo nell’indirizzo IP della connessione (lato WAN) 84.81.188.202, subnet 255.255.255.252 e gateway 84.81.188.201. Questo perché il gateway di Telecom è sempre il primo indirizzo disponibile.

Nell’indirizzo LAN del router va inserito uno degli IP pubblici forniti. Scegliamo il primo, 78.62.124.201 con subnet 255.255.255.248. Questa configurazione è routing “puro”, e il NAT andrà disabilitato poiché nei modelli più semplici di router non è possibile assegnare due IP all’interfaccia LAN, oltretutto NATtandone uno solo; per questo siete praticamente obbligati ad installare un firewall con WAN 78.62.124.202, subnet 255.255.255.248 e gateway 78.62.124.201 (l’interfaccia LAN del router). IP LAN e NAT andranno configurati in conseguenza della classe di indirizzi privati che utilizzate nella vostra rete locale.

Naturalmente nessuno di Telecom vi dirà nulla di tutto questo, lo dovrete scoprire da soli.

(*) gli indirizzi sono assolutamente inventati.