[Tasslehoff]

Originariamente inviato da destroyer85

Ah una cosina proprio semplice semplice come un routing...
E poi quello è un servizio di protezione dagli attacchi, non un protocollo base.

Non si tratta di creare o di inventarsi un protocollo nuovo, sempre si tratta di protocollo TCP/IP, è un modo diverso di esporre i servizi, molto più flessibile, molto più semplice e che permette di superare i limiti della classica pubblicazione basata su NAT (con tutte le sue rotture, nat, regole fw, dns) che in alcuni casi (es provider che non ti assegnano un ip pubblico perchè "nattano" a loro volta) non sono proprio utilizzabili.

Che poi aggiunga anche un layer di protezione dovuto a WAF e controlli di sicurezza della CDN Cloudflare è un altro paio di maniche, ma quello è un "di più" che non c'entra nulla con quello che stavo citando.

Se vuoi puoi aggiungerci (for free) anche Cloudflare Access per avere accesso autenticato (e con MFA) o federato (se hai già un tuo Identity Provider) anche ad applicazioni ad accesso anonimo, ma anche questo è fuori dal tema che stavamo trattando.

Originariamente inviato da nyo90

Già.. Se cerco su google mi dice direttamente di contattare il reparto vendite per un preventivo Più devo mettermi a configurare tutta questa roba al posto del router, che necessita veramente di quattro click.

Evidentemente non hai cercato bene, perchè se cerchi anche solo banalmente "cloudflare tunnel howto" il primo risultato dopo la documentazione di Cloudflare (giustamente in cima ai risultati, perchè sta gente sa come si lavora e sa cosa vuol dire SEO) è un sito che presenta un tutoria passo passo su come usare Cloudflare tunnel (LINK).

E' tutto free, poi se vuoi sottoscrivere i piani a pagamento sei libero di farlo, ma tutto quello che descrivo è free, l'unico costo è quello della registrazione di un dominio (che si può trovare anche al ridicolo costo di 0,99 €/anno)

1. Configuri i dns di Cloudflare come nameserver autoritativi per il tuo dominio (da fare una tantum per dominio, quindi una volta fatto te ne dimentichi) e usi Cloudflare come DNS per il tuo dominio (pannello di amministrazione top tra l'altro)
2. vai nella sezione Zero Trust, crei un tunnel e ottieni il token di quel tunnel (oltre alle istruzioni su come installare cloudflared o farlo girare come container con docker, consigliatissimo)
3. installi cloudflared (o lo fai girare come container) e lo configuri per usare il token che ti ha dato allo step precedente la procedura di creazione del tunnel; fai partire cloudflared e hai stabilito il tunnel
4. dal pannello di amministrazione del tunnel scegli un hostname a piacere del tuo dominio e gli dici a che indirizzo e porta trovare il servizio sulla tua lan che deve esporre a web tramite il tunnel

Punto, fine, non c'è altro.

• Configurazione NAT sul router? Non serve
• Configurazione regole firewall sul router? Non serve
• Configurazione dns dinamico? Non serve
• Configurazione record dns? Non serve
• Acquisto certificato https o generazione con Let's Encrypt? Non serve, ci pensa Cloudflare creandoti automaticamente gratis un certificato https wildcard per il tuo dominio, e ti fa direttamente la riscrittura da http a https
• Monitoraggio certificato e cron per aggiornare il certificato? Non serve, ci pensa Cloudflare e lo fa in automatico con la propria CA trustata da chiunque.
• Se il tuo provider non ti da ip pubblico non devi chiedere nulla o sostenere alcun costo, pubblichi tutto in autonomia.

Aggiungo nel caso non fosse abbastanza evidente:

1. Cambi provider? Chissenefrega, automaticamente quello che esponi a web sarà automaticamente pubblicato anche col nuovo provider
2. Cambi router? Chissenefrega, non hai alcun nat o regola firewall da aggiungere al nuovo router o di cui ricordarti
3. Sposti il tuo servizio altrove (chessò su un VPS)? Chissenefrega, nel momento in cui configuri cloudflared con lo stesso token sul nuovo sistema hai tutto già perfettamente funzionante senza cambi DNS, spostamento di certificati https, riconfigurazione dei cron per rinnovare i certificati https, etc etc...
4. Sei un'azienda e ti sta sulle palle il tuo fornitore di sistemi attuale (es AWS, Azure o Google Cloud o i server in un rack nel bagno dell'ufficio) e vuoi spostarti su altro? Chissenefrega, sposti tutto fregandotene dei casini cosmici legati a cambi dns, tempi di propagazione, magheggi vari per rendere accessibili i servizi nel transitorio, regole firewall, stupide DMZ, reverse proxy, certificati da spostare... sposti i servizi + cloudflared e hai spostato tutto e tutto è raggiungibile sul nuovo provider senza porti tutti questi problemi, se poi gira tutto dentro dei container tutto diventa estremamente flessibile.

Originariamente inviato da nyo90

È stato più semplice contattare TIM e chiedere l'indirizzo IP pubblico, sulla mia SIM con giga "illimitati" e gestire tutto il resto direttamente dal router, impostando una VPN e rendendo Plex raggiungibile da remoto. Facile, veloce, sicuro e cifrato.

Il fatto che sia cifrato non significa necessariamente che sia sicuo, certamente aggiunge uno strato di sicurezza ma da qui a lavarsene le mani e pensare di essere in una botte di ferro ce ne passa.
Stai sempre esponendo servizi direttamente dal tuo indirizzo ip pubblico attestato su un'interfaccia del tuo router (che in molti casi è un router ridicolo, spesso con buchi sw clamorosi, spesso con firmware arcaici o risorse così ridicole da mandarlo in freeze con un flood da anni '90).

Se oltre alla porta 80 o 443 (tipiche per i servizi con interfaccia web) stai esponendo via NAT altri servizi (chessò l'interfaccia di amministrazione del nas di casa, o la ip camera di turno o l'interfaccia web della stampante di casa) pensi che da web nessuno se ne accorga solo perchè anzichè porte standard stai usando porte fantasiose a piacere? Seriously?
Siamo ancora al trito e ritrito "security by obscurity"?

Esporre i servizi via CDN è un enorme balzo in avanti dal punto di vista della sicurezza "per design".

Poi che c'entra la VPN?
Qui non stiamo parlando di VPN, se vuoi anche per quella è ormai diventato TOTALMENTE INUTILE avere un ip pubblico (statico o dinamico) e puoi benissimo collegarti in vpn a casa tua anche se hai un provider che ti piazza dietro nat, ti basta usare Tailscale.
Fa giusto eccezione IPSec, che però ormai è una tecnologia usata praticamente solo per le vpn site-to-site e che in tutti gli altri ambiti è stata soppiantata dalle ben più flessibili vpn ssl.

Anche qui, Tailscale è un servizio di ZTNA completamente free che ti permette di creare una mesh di vpn basate su Wireguard in modo trasparente e senza dover contattare direttamente l'ip dell'interfaccia pubblica del router.

Ragazzi, sia per l'esposizione dei servizi a web che per le vpn il mondo si è un cincinino evoluto, non è che ci sono solo supercazzole tipo AI in giro, c'è ancora gente che si da da fare e cerca di superare i limiti delle tecnologie esistenti proponendo qualcosa di migliore, di più flessibile e che non abbia i limiti delle vecchie tecnologie che girano da 40 anni...

E lo dice uno che è FORTEMENTE conservativo e tutt'altro che propenso a lanciarsi su ogni novità che viene presentata, e anzi, quando c'è una novità la guarda sempre con scetticismo e cerca di capire dov'è la fregatura e dove il marketing sta pompando.

Originariamente inviato da nyo90

Continuo a non vedere il NAT come una soluzione e preferirei mille volte un indirizzo IPv6 pubblico disponibile facilmente, piuttosto che dover lottare per un IPv4

Non devi lottare per nessun IPv4, e il motivo è semplice: non ce n'è alcun bisogno.
I primi anni in cui ho iniziato a lavorare era appena uscito il protocollo HTTP 1.1 e ricordo con stupore (e anche molta ritrosia) l'ostinazione di certe cariatidi che trovavo dai clienti (aziende di prodotto, l'ostinazione e la ritrosia tecnologica sono sempre state una caratteristica tipica delle aziende di quel tipo) che si ostinava a pubblicare servizi ciascuno con il proprio ip pubblico, il nuovo protocollo aveva introdotto il concetto di virtualhost ma loro lo ignoravano e si opponevano dicendo che era "insicuro".

Già da allora fu piantato il primo chiodo nella bara di IPv6, potenzialmente una azienda poteva usare un solo ip pubblico che pubblicare quello che voleva, ovviamente non era così semplice perchè c'erano tanti altri servizi che ne richiedevano (smtp, ipsec etc etc), ma era già un balzo epocale.

Oggi in 10 minuti su AWS puoi tirar su un cluster Kubernetes con EKS dargli quanti nodi worker vuoi, anche migliaia, ed esporre tutto lo scibile possibile con un paio di ip pubblici di un load balancer AWS (almeno 2 per garantire un minimo di ridondanza usando due reti), e persino il traffico di outbound puoi farlo uscire TUTTO (per tutte le migliaia di worker nodes e le migliaia e migliaia di applicazioni che ci possono girare sopra) con 2 ip pubblici (usando i nat gateway, anche qui 2 per ridondanza sulle reti).

Ripeto, stiamo parlando di qualcosa che si tira su in mezz'ora massimo, e che può soddisfare le necessità anche di una mega azienda da migliaia e migliaia di dipendenti, il tutto con l'uso di 2 (max 4) ip pubblici, quando fino a qualche anno fa sarebbe stato necessario dotarsi di diverse classi C di ip pubblici, centinaia e centinaia o migliaia di ip pubblici.

E' questo il motivo per cui probabilmente nessuno di noi avrà mai bisogno di usare IPv6 in tutta la sua carriera lavorativa, e non mi riferisco solo alle cariatidi del forum come il sottoscritto, ma nemmeno il ragazzino adolescente che ha sentito parlare oggi di hwupgrade e si è iscritto oggi al forum...