Era un po’ che non tiravo fuori la mia fissa con IPv6…
Dopo oltre due mesi di trasferta per finire l’infrastruttura di una nave, eccomi tornato alla carica con IPv6.
Continua a leggereEra un po’ che non tiravo fuori la mia fissa con IPv6…
Dopo oltre due mesi di trasferta per finire l’infrastruttura di una nave, eccomi tornato alla carica con IPv6.
Continua a leggereDopo l’esperienza di Fabrizio, mi sono deciso ad usare un OpenWRT per il tunnel IPv6 di Hurricane Electic.
Avevo a disposizione un Netgear DG834GT gentilmente donato da Riccardo per questo scopo e ho deciso di metterlo finalmente in pista.
Avevo installato OpenWRT Backfire tanto tempo fa, ma non avevo ancora avuto l’occasione di provarlo seriamente sul campo. Dopo alcuni disservizi della linea ADSL di casa ho riconfigurato la rete casalinga eliminando la VM con pfSense e semplificando un po’ la configurazione. Tuttavia questo mi aveva fatto perdere la possibilità di usare pfSense come gestore del tunnel IPv6. (altro…)
Quando si comincia ad utilizzare IPv6 in produzione su una configurazione LAN eterogenea iniziano i comportamenti a cui non siamo abituati.
Con IPv4 un host impostato per la configurazione automatica si assegna un indirizzo link-local (169.254.0.0/16, RFC3927) contatta il server DHCP per avere un indirizzo e, quando lo ottiene, scarta l’indirizzo link-local e avrà sempre solamente quell’indirizzo fino alla scadenza dell’affitto dello stesso.
(altro…)Ho deciso di cambiare qualcosa nelle configurazione casalinga introducendo un po’ di virtualizzazione, un firewall standalone e un tunnel IPv6 (spero) finalmente stabile.
Seguendo le istruzioni di Fabrizio ho configurato il Linux casalingo di frontiera con KVM e una VM su cui gira la versione 2.1 di pfSense. Alla fine la configurazione è (per scelta di non complicarmi troppo la vita per ora) la più classica e semplice: WAN<->firewall<->LAN con i servizi pubblicati in LAN nattati (per IPv4) 1:1, senza DMZ, per ora.
Questo mi ha permesso di togliere i mezzo dal Linux host la gestione del tunnel e altri servizi legati alla rete (come il DHCP e radvd).
Quello che serve per lo scopo di questo articolo è un tunnel IPv6 gratuito con Hurricane Electric (un solo /64 è sufficiente), una connessione con IP fisso e un firewall pfSense. Negli esempi che seguono gli IP sono ovviamente inventati (per IPv4) o del blocco /32 utilizzabile per la documentazione (per IPv6).
Questo articolo spiega come forzare la connessione IPv4 o IPv6 verso un dominio specifico utilizzando Postfix.
Se si imposta inet_protocols = all
con un MTA che ha sia un record A sia un record AAAA Postfix sceglie di volta in volta a caso se utilizzare IPv4 o IPv6 per minimizzare i problemi di recapito.
Durante il primo periodo di adozione dell’IPv6 ci possono essere degli MTA con il record AAAA nel DNS ma con dei problemi a ricevere mail via IPv6. Oppure semplicemente si vogliono fare dei test con un dominio specifico senza modificare la configurazione generale di Postfix.
La prima versione di questo articolo spiegava in maniera onestamente un po’ cervellotica come abilitare su un server CentOS 6 la gestione degli host virtuali di Apache 2.2 basati sugli indirizzi (IP-based virtual host) per IPv6 e basati sul nome (name-based virtual host) per IPv4.
Questa revisione si propone lo stesso scopo, ma con un metodo molto più rapido e meno invasivo.
Nella documentazione di Apache viene detto esplicitamente che la gestione degli host virtuali basati sul nome è una tecnologia creata per far fronte alla scarsità degli indirizzi IPv4; dal momento che questo non è un problema di IPv6, possiamo usare tranquillamente gli host virtuali basati sugli IP. Questa tecnologia permette, tra le altre cose, di avere più certificati HTTPS caricati sul medesimo server.
(altro…)Questo articolo spiega come passare in IPv6 un mail server Linux con Postfix, Amavisd-new e Dovecot.
Il sistema di partenza è un Linux con il dual stack IPv4/IPv6 attivo e funzionante con un indirizzo pubblico IPv4 e uno IPv6. Anche il sistema di posta elettronica è perfettamente funzionante in IPv4 con le ultime versioni dei programmi indicati sopra installati da sorgente, non da pacchetto della distribuzione Linux. Ciò perché con IPv6 è sempre meglio avere le ultime versioni, anche se la maggior parte delle istruzioni che seguono dovrebbero funzionare anche con le versioni distribuite nei pacchetti standard.
Continua a leggereNota aggiunta il 30/9/2013: a questa soluzione è da preferire quella descritta in un articolo successivo con pfSense e KVM.
(alcune parti sono state modificate dopo la pubblicazione)
Questo articolo spiega come impostare un tunnel IPv6 con Linux CentOS 5 configurato come gateway, NAT e firewall di una LAN.
Lo scenario è il seguente: un router ADSL con IPv4 pubblico collegato ad un Linux che fa da NAT/firewall per la LAN. In questo esempio eth0 è l’interfaccia WAN con un IPv4 pubblico /29 e eth1 è l’interfaccia LAN con un IPv4 /24.
Alla fine della procedura la classe /64 di IPv6 pubblici con reverse DNS potrà essere utilizzata per assegnare indirizzi pubblici ai dispositivi IPv6 in LAN, incluso il gateway Linux.
(Disclaimer: seguite questo tutorial a vostro rischio e pericolo. Potreste incorrere in danni hardware come il brick del dispositivo, intrusioni di hacker nel vostro sistema o sviluppare dipendenza da IPV6. In nessun caso l’autore potrà esserne ritenuto responsabile)
Nel nostro paese è molto difficile ottenere una connessione con IPV6 nativo per la casa o l’ufficio.
La soluzione di seguito proposta consentirà di portare IPV6 sulla vostra LAN in maniera trasparente.
Il dispositivo che renderà possibile questo risultato è un router un po’ particolare, ma facilissimo da procurare. Probabilmente se siete informatici per professione o diletto lo avete già nella cassetta del materiale di scarto :-).
Nel mio caso ne ho reperiti un paio, ma la mia scelta è caduta sul più potente router/access point Dlink DIR-600.
Questo articolo inaugura una (spero) nutrita serie di articoli sull’IPv6 per cui è stata creata una tassonomia specifica.
L’idea è che tutti gli autori del blog condividano le proprie esperienze con IPv6 e le mettano a disposizione degli altri, che le possono consultare utilizzando le categorie nella colonna a sinistra.
Se qualcuno vuole contribuire come guest blogger oppure come autore ricorrente, per questo tema (o anche per altri) mi scriva pure a lrosa()siamogeek.com.
Scenario: abbiamo un server CentOS headless in hosting con un IPv4 fisso e configurato, che utilizziamo per fare amministrazione via ssh e dobbiamo aggiungere un indirizzo IPv6 che ci ha assegnato il fornitore.
La prima differenza rispetto ad un IPv4 è che non ci vengono assegnati, generalmente, uno o due indirizzi, ma un blocco. Nel mio caso mi hanno dato 2a01:4f8:d15:1c00::/64; dal momento che IPv6 ha 128 bit di indirizzo, un /64 significa che ho 64 bit di indirizzo fisso (2a01:4f8:d15:1c00) e altrettanti disponibili per il mio server. Un sogno, se ragioniamo con il razionamento di IPv4.