L'articolo che sto scrivendo ha un taglio più tecnico, per cui non me ne vogliano i meno esperti (a cui comunque cerco spesso di dedicare anche articoli "digeribili"), ma sarebbe opportuno che il lettore conosca cos'è un IPv4 e la relativa logica di routing legata alla maschera di rete, inoltre è necessario avere già conoscenze sui meccanismi di NAT per meglio comprendere il proseguo.
Lo scopo è quello di far muovere i primi passi e consentire al lettore di creare un laboratorio di test per effettuare una serie di esperimenti.
L'architettura presa in esame non prevede che il proprio ISP fornisca nativamente IPv6, quindi utilizzeremo un TunnelBroker, ovvero un servizio in grado di creare un tunnel con il nostro gateway ed erogarci una classe /64 di IPv6 (di 18 milioni di miliardi di IP pubblici, ma questo lo vedremo avanti).
Premessa
Visto il taglio tecnico, mi dilungherò poco sulle premesse: oramai anche i muri sanno che gli IPv4 sono praticamente terminati su RIPE e ARIN, quindi la situazione (seppur se ne parli da molto tempo) riveste carattere d'urgenza. Piuttosto è importante sfatare alcuni miti per cui è opportuno che il lettore legga queste FAQ in italiano ad opera di ipv6italia (gruppo non più attivo, ma le cui fonti risultano comunque estremamente utili e preziose).
E' altrettanto opportuno che il lettore sappia leggere un IPv6, quindi rimando a https://it.wikipedia.org/wiki/IPv6 e nello specifico la sezione di "Notazione per gli indirizzi IPv6".
Primo Step: creare un collegamento ad un Tunnel Broker
Come abbiamo visto poc'anzi, un servizio di Tunnel Broker si occupa di fornire connettività IPv6 tunnellizzandola su una esistente IPv4, esso ci darà a disposizione una classe IPv6 /64 liberamente utilizzabile, ovvero 18446744073709551616 IP Pubblici Statici (per dirla con nomi familiari). Opzionalmente è possibile richiedere una /48 con un semplice click, ma ritengo che non siano particolarmente necessari i 1208925819614629174706176 indirizzi IP di questa maschera di rete. (almeno non ora, non parleremo di subnetting)
Nel nostro esperimento (estremamente pratico), ci collegheremo su https://www.tunnelbroker.net/, effettueremo una registrazione, quindi cliccheremo su Create Regular Tunnel. A questo punto potremo scegliere il nodo di collegamento IPv4 tra una serie corposa di Server sparsi in tutto il mondo.
A questo punto avremo tutto per creare un Tunnel tra noi e loro per utilizzare la nostra classe IPv6.
Potremo avere visibilità degli IP pubblici utilizzando il semplice tool CIDR Calculator per IPv6 reperibile qui https://www.ultratools.com/tools/ipv6CIDRToRange (in effetti non è proprio banale calcolare la notazione CIDR in v6!).
Secondo Step: Configuriamo il nostro router-tunnel
Qualcuno dovrà fare un tunnel, nel nostro caso il router che si occuperà di fare questo è un pfSense la cui documentazione relativa a questo aspetto è estremamente dettagliata e reperibile qui: https://docs.netgate.com/pfsense/en/latest/interfaces/using-ipv6-with-a-tunnel-broker.html
Se tutto va bene ed abbiamo seguito la guida "religiosamente", avremo il tunnel online.
 |
| Interfaccia Tunnel online |
Architetturalmente abbiamo deciso di mettere, a seguire, un firewall Stormshield dietro il pfSense, pertanto quest'ultimo non viene utilizzato come firewall, ma come semplice router.
Facciamo qualche prova utilizzando http://www.ipv6now.com.au/pingme.php
Perfetto, siamo belli, biondi e con gli occhi azzurri.
Terzo Step: La nostra LAN full IPv6
A questo punto abbiamo messo il firewall Stormshield a valle del pfSense (abilitandolo all'IPv6) in bridge, così da consentire l'adozione degli IPv6 pubblici su tutta la LAN. Il NAT su IPv6 non è necessario e da un punto di vista di sicurezza, in verità, non apporta alcun beneficio rispetto ad un filtro ben strutturato... anzi.
Configurato correttamente il Firewall in bridge, potremo notare sull'interfaccia out il traffico IPv6 mediante un tcpdump:
A questo punto abbiamo messo un server vmware direttamente connesso all'altra interfaccia del bridge sul firewall, così da poter installare due macchine virtuali, una Linux ed una Windows.
NB: Abbiamo abilitato sul firewall il DHCP6 Server, tuttavia esso non era indispensabile avendo lasciato abilitati i protocolli di Router Advertisemen (RA), di cui tuttavia ci occuperemo in un prossimo articolo.
A conti fatti, l'architettura che abbiamo realizzato è la seguente:
Qualche test
A questo punto abbiamo la nostra rete Full IPv6, ovvero ora non sussiste alcun IPv4 tradizionale (per la cronaca, il protocollo IPv4 è stato proprio disabilitato all'interno delle VM).
Le VM navigano (sui siti, pochi, IPv6 abilitati). Ovviamente Debian si è riuscito nativamente a scaricare i suoi aggiornamenti fin dalla fase di installazione. Come DNS abbiamo messo (quando facevamo da DHCP6 Server) i DNS6 di CloudFlare 2606:4700:4700::1111 e 2606:4700:4700::1001.
In sostanza, le due macchine tra di loro si pingano, raggiungono l'esterno e sono contattabili dall'esterno. Hanno, di fatto, degli IP pubblici. In questa fase non sono stati messi dei filtri, ne parleremo più avanti, è un laboratorio. Da notare che questa architettura non utilizza ovviamente NAT. Era banale da precisare (trovandoci in Bridge), ma è importante entrare nell'ottica che il NAT appartiene al mondo IPv4, e non a quello IPv6 (il NAT-PT è un'altra storia, prima o poi lo approfondiremo).
A questo punto, non posso che augurare al lettore sopravvissuto "buon divertimento" con i nuovi host IPv6 only. Buoni esperimenti!
E poi?
Le domande che a questo punto il lettore dovrebbe essersi già posto sono:
- In una rete fullbridge (un po' come accade nei campus), come faccio a creare delle policy di firewalling?
- In una rete fullbridge, come gestisco le VLAN e la relativa compartimentazione?
- Il DHCPv6 Relay che vedo ha più IP, che ruolo ha la Router Advertisement (RA) in tutto questo?
- Perchè la mia scheda di rete ha un indirizzo speciale fe80::/10 valido (da RFC) per lo specifico link fisico? (ovvero: cosa significa link fisico?? Che centrano i layer più bassi? Parleremo di Scope Address, un nuovo concetto)
- Facciamo alcune considerazioni di sicurezza, l'assenza del NAT semplifica di molto la gestione (NO! Il NAT non si applica per motivi di sicurezza ma solo per incrementare il numero di IPv4 utilizzabili!), inoltre il numero sproporzionato di indirizzi IPv6 rende difficoltoso il lavoro degli scanner generici. Tralasciando le fantasie sul supporto IPsec nativo di IPv6 rispetto a IPv4, che altri scenari si aprono sotto il fronte security?
Ne parleremo nel prossimo articolo, nel frattempo sarebbe interessante confrontarci sul tema. Lasciate pure nei commenti i vostri contatti (se personali non li pubblicherò, i commenti sono moderati). Ogni confronto è bene accetto, anche non necessariamente epistolare.
 |
| RA su StormShield |
 |
| RA su pfSense |
Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.
