Il lento passaggio ad IPv6: cosa succede con il protocollo che avrebbe dovuto salvare Internet dalla fine degli indirizzi IP?

[Bello&Monello]

Originariamente inviato da Tasslehoff

E' già da diversi anni che questo non è più un problema.
L'esigenza di "nattare" un servizio su un ip pubblico non serve più d quando esistono le CDN e i servizi di ZTNA.

Ne sei davvero così sicuro?!?

[Bello&Monello]

Originariamente inviato da Tasslehoff

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.

Mah insomma, parliamone... stai mettendo a confronto una tecnologia standard come il NAT, disponibile su qualsiasi apparato di rete e quindi utilizzabile senza nessun vincolo, con un servizio fornito da un unico operatore.
Dire che è "molto più flessibile e molto più semplice" è tutto da vedere. Visto che probabilmente col NAT hai la flessibilità di ruotare anche i santi su qualsiasi porta tu voglia e su un numero pressochè infinito di indirizzi ip.

[Notturnia]

Io me la vedo mia mamma e tutti i genitori di quelli che sono su questo forum che installano un router e creano NAT e altri servizi.. magari anche un proxy..

E perchè non una VPN ?..

Chissà perchè IPv6 non prende pieve così velocemente

Proprio non capisco

[destroyer85]

Forse non sai cosa fa il NAT...
Facciamo l'esempio del NAT in uscita:
Prende l'header del pacchetto e sostituisce l'indirizzo IP sorgente locale e la porta con quello pubblico e una porta tra quelle non usate, ricalcola il checksum dell'header e dell'intero pacchetto, scrive nella tabella l'associazione ip di destinazione, porta, indirizzo locale porta, manda il pacchetto, arriva la risposta, stessa operazione di prima su IP porta e checksum e lo consegna all'indirizzo locale.
Questo, oltre a "costare" molta CPU e RAM che viene quindi sottratta a quella disponibile per le cose importanti tipo firewall o VPN, riduce il throughput del 17 %.
Altra cosa il routing esiste senza NAT, ma non puoi avere NAT senza routing.

Il routing è "stupido" e si può implementare in hardware.

Per quanto riguarda l'ADV dei servizi di cloudflare, state mischiando due cose che non c'entrano niente.
È semplicemente un firewall in cloud che si basa sempre su Ipv4, ipv6 routing e NAT. Non c'è niente di magico

[barzokk]

ok bravi tutti, però

Originariamente inviato da Tasslehoff

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.

io guardo qui
https://tailscale.com/use-cases/remote-access
c'è l'opzione $0per active user/month, clicco su Get started free
e mi propone
Sign up with your identity provider (google, Microsoft, ecc)
You’ll use this provider to log in to your network (more)
e già mi girano i marroni

E cosa succede quando domani non sarà più 0$, ma lo mettono a pagamento ?
E se invece voglio usare OpenVpn ?

Ma non è più facile il solito IP statico che ci vuole 1 minuto, e non dipendo da troppi operatori?

[marcram]

Originariamente inviato da barzokk

Ma non è più facile il solito IP statico che ci vuole 1 minuto, e non dipendo da troppi operatori?

Dipende...
Io preferisco usare un servizio tipo TailScale, o ZeroTier, piuttosto che avere un indirizzo fisso che possa essere preso di mira...

[fraussantin]

Originariamente inviato da nyo90

Il NAT come soluzione pratica senza alternativa è ciò che rende problematici alcuni operatori telefonici, per chi deve accedere alla propria rete dall'esterno.
Preferirei avere un indirizzo pubblico IPv6 che stare sotto NAT IPv4.

Ma il nat supporta in qualche modo l'upnp?

[Tasslehoff]

Originariamente inviato da barzokk

ok bravi tutti, però

io guardo qui
https://tailscale.com/use-cases/remote-access
c'è l'opzione $0per active user/month, clicco su Get started free
e mi propone
Sign up with your identity provider (google, Microsoft, ecc)
You’ll use this provider to log in to your network (more)
e già mi girano i marroni

E cosa succede quando domani non sarà più 0$, ma lo mettono a pagamento ?
E se invece voglio usare OpenVpn ?

Hai 3 opzioni:

1. Fai fermare i maroni che girano, perchè francamente nell'anno di grazia 2024 gli integralismi sulle Bad Corp non hanno più senso, e non avere nemmeno un account GitHub probabilmente significa non aver mai avuto uno straccio di partecipazione in nessun progetto opensource, non aver mai aperto nemmeno una issue per segnalare un problema, insomma aver solo "preso" senza aver mai "dato" nulla alla community.
   Dico probabilmente, ma la percentuale di progetti che stanno su GitHub è talmente alta che si potrebbe anche sostituire con "sicuramente".
2. Ti metti in piedi un IdP OpenID (es Authentik) e lo federi con Tailscale
3. L'unica componente non opensource (ma free) è l'interfaccia di amministrazione, puoi metterti in piedi la tua usando Headscale (https://github.com/juanfont/headscale)

Se domani lo mettono a pagamento valuti il costo, se per te è eccessivo usi Headscale, non cambia nulla tranne il fatto che devi hostare il tuo control server, e per quello ti serve un ip pubblico.

Se vuoi usare OpenVPN devi per forza avere un ip pubblico (non importa se statico o dinamico), se il tuo operatore ti mette dietro NAT ti attacchi al tram e urli in curva, e OpenVPN non lo puoi usare.

Originariamente inviato da barzokk

Ma non è più facile il solito IP statico che ci vuole 1 minuto, e non dipendo da troppi operatori?

Come ho ampiamente descritto, l'ip pubblico (non necessariamente statico, può anche essere dinamico e non è un problema) non tutti gli operatori ti permettono di averlo.

A prescindere da ciò usare l'esposizione dei servizi mediante NAT è più complessa, occorre mettere mano a:

1. regole firewall
2. tabella di nat
3. risoluzione dns

Usare un meccanismo di ZTNA tipo Cloudflare tunnel per fare lo stesso richiede

1. una operazione banale sul pannello di Cloudflare
2. l'esecuzione di un eseguibile passandogli il token generato da Cloudflare

Vantaggi:

• nessun firewall su cui mettere le mani
• nessun router su cui mettere le mani
• nessun dns su cui mettere le mani
• nessun dannato certificato TLS da generare/manutenere
• totale indipendenza dal provider
• superamento di tutte le limitazioni di hosting con i provider che ti piazzano dietro nat.

Se ti sembra poco...

Già a livello domestico i vantaggi sono enormi, a livello lavorativo sono stratosferici, significa migrazioni da un provider all'altro o da un server all'altro in tempo praticamente zero e senza interruzioni, zero perdite di tempo su fw, dns, nat.
Significa pubblicare servizi senza dover fare il giro delle 7 chiese: l'ufficio rete che ti apre le porte da DMZ a LAN, l'ufficio sicurezza che ti configura il tal reverse proxy che nessuno sa mai usare bene e su cui nessuno sa mai installare un dannato certificato https per fare da terminatore, significa totale isolamento delle applicazioni senza loro raggiungibilità se non dalla CDN attraverso un canale sicuro, significa fare in 10 minuti quello che normalmente nelle grandi organizzazioni richiede settimane di richieste, cartaccia, mail, riunioni, etc etc...

[Tasslehoff]

Originariamente inviato da Bello&Monello

Ne sei davvero così sicuro?!?

Di fatto sì, nell'anno di grazia 2024, con il protocollo http che è diventato omnipresente e di fatto governa qualsiasi servizio esista, di fatto sì.

Poi tu puoi anche esporre un server ssh o LDAP o un listener Oracle con Cloudflare se proprio vuoi farti male.

Certo, ci sarà sempre il servizio di nicchia che gira solo su protocollo UDP o quello che rompe perchè deve nattare il client Bittorrent su UDP per scaricare qualche scemenza, ma non sono esempi significativi.

Di fatto da vent'anni (con l'introduzione dei web services) il protocollo http è diventato lo strumento di comunicazione standard per qualsiasi cosa, e http significa protocollo tcp, punto.

Originariamente inviato da Bello&Monello

Mah insomma, parliamone... stai mettendo a confronto una tecnologia standard come il NAT, disponibile su qualsiasi apparato di rete e quindi utilizzabile senza nessun vincolo, con un servizio fornito da un unico operatore.
Dire che è "molto più flessibile e molto più semplice" è tutto da vedere. Visto che probabilmente col NAT hai la flessibilità di ruotare anche i santi su qualsiasi porta tu voglia e su un numero pressochè infinito di indirizzi ip.

Non è da vedere, è un dato di fatto.

Domani devo pubblicare un servizio, se voglio farlo senza Cloudflare Tunnel devo:

1. Mandare una richiesta al centro operazioni rete per far configurare un nuovo vip su F5 per fare da reverse proxy
2. Mandare una richiesta al gruppo sicurezza rete per farmi aprire le porte dall'interfaccia di DMZ del vip F5 di cu sopra la cui interfaccia pubblica è nattata su un ip pubblico di un router
3. Mandare una richiesta al centro operazioni rete per far creare il record dns di turno per risolvere l'hostname con l'ip del vip F5
4. Mandare una richiesta al centro operazioni rete per richiede un certificato https, attendere lungaggini per l'acquisto o se sono fortunato attendere che qualche "mago" lo generi con Let's Encrypt su F5
5. Organizzare meeting per spiegare a ciascuno di questi perchè e percome occorre quello che è stato inserito nei ticket di cui sopra
6. Attendere settimane che ciascuno di questi gruppi faccia il proprio dovere (operazioni da 5 min che richiedono settimane di attesa)
7. Sperare che nessuno sbagli qualcosa e nel caso indire riunioni per far notare l'errore e correggere

Settimane per fare tutto questo, settimane buttate, fiumi di mail, richieste su ServiceNow, call e alla fine di questo calvario finalmente il servizio è pubblicato.

Con Cloudflare Tunnel?
10 minuti a esagerare, nessun gruppo da coinvolgere o a cui richiede ticket, aperture porte, regole fw, configurazione reverse proxy.
Nessun certificato https da richiedere, o da rinnovare, o da monitorare.
In più la protezione di una CDN con gli attributi, con un WAF che fa impallidire i ridicoli WAF enterprise (stile Imperva), riscritture configurabili via un pannello web based in tempo zero, protezione dei servizi con autenticazione form based e MFA o federazione SAML o OpenID prima del golive.

Perdonami ma non voglio ripetermi, ma i vantaggi sono talmente evidenti che non dovremmo nemmeno discuterne.

[baruk]

Originariamente inviato da aqua84

Stop a nuovi indirizzi IPv4 dopo il 2035 e miliardi di ecoincentivi per IPv6.

Anche Hybrid IPv6 va bene

io mi faccio subito la colonnina IPv6 in giardino

[barzokk]

Originariamente inviato da Tasslehoff

Hai 3 opzioni:[*]Fai fermare i maroni che girano, perchè francamente nell'anno di grazia 2024 gli integralismi sulle Bad Corp non hanno più senso,

...

Premessa, l'unica persona di cui mi fido è mia mamma. E pure lei ogni tanto mi dà dei ceffoni.
Corollario: ogni Corp diversa dalla mia, è Bad.


Detto questo, mi sembra che quando ci si vuole collegare, bisogna confermare visitando un loro link.


E se io devo automatizzare il tutto, per es per collegare un ufficio periferico a quello centrale ?
Magari con dei client-server che si connettono e sconnettono di frequente, oppure se manca tensione e il collegamento salta ?
Si paga
Meh

[gd350turbo]

Originariamente inviato da Tasslehoff

• nessun firewall su cui mettere le mani
• nessun router su cui mettere le mani
• nessun dns su cui mettere le mani
• nessun dannato certificato TLS da generare/manutenere
• totale indipendenza dal provider
• superamento di tutte le limitazioni di hosting con i provider che ti piazzano dietro nat.

Se ti sembra poco...

Ottimo davvero !

[destroyer85]

1. http3 usa UDP
2. il tunnel richiede l'installazione di un software, quindi funziona solo su sistemi dove il software è installabile
3. cloudflare, agendo sostanzialmente da proxy, vede in chiaro tutto il traffico che ci passa di mezzo
4. reputo stupido utilizzare il NAT con IPv4 quando con IPv6 si potrebbe fare semplicemente un routing figurati se vado a complicare ulteriormente la rete con un tunnel https su protocollo tcp che passa attraverso un reverse-proxy il tutto semplicemente per far passare dei pacchetti

La cosa che è veramente da superare è l'uso degli IP. Molti si sentono "più fighi" utilizzando gli IP invece dei nomi DNS non capendo che così mandano a rane un eventuale banale load balancing.
L'IPv6 in questo ci aiuta perché è impossibile da ricordare e io lo adotterei solo per questo motivo. (che è il motivo per cui molti lo odiano)

[matsnake86]

Originariamente inviato da destroyer85

il tunnel richiede l'installazione di un software, quindi funziona solo su sistemi dove il software è installabile

Praticamente ovunque. Gira anche su un raspberry talmente è leggero.
Con l'immagine docker poi è talmente facile da risultare imbarazzante. Quando generi il tunnel ti danno già il comando da eseguire su podman o docker che sia.

Originariamente inviato da destroyer85

cloudflare, agendo sostanzialmente da proxy, vede in chiaro tutto il traffico che ci passa di mezzo

Di qualcuno ti dovrai fidare. Che sia un hosting, il tuo isp, il sistema operativo... Nella catena del software ci sarà sempre qualcosa al di fuori del tuo controllo di cui dovrai semplicemente fidarti.

Originariamente inviato da destroyer85

reputo stupido utilizzare il NAT con IPv4 quando con IPv6 si potrebbe fare semplicemente un routing figurati se vado a complicare ulteriormente la rete con un tunnel https su protocollo tcp che passa attraverso un reverse-proxy il tutto semplicemente per far passare dei pacchetti
La cosa che è veramente da superare è l'uso degli IP. Molti si sentono "più fighi" utilizzando gli IP invece dei nomi DNS non capendo che così mandano a rane un eventuale banale load balancing.
L'IPv6 in questo ci aiuta perché è impossibile da ricordare e io lo adotterei solo per questo motivo. (che è il motivo per cui molti lo odiano)

Su questo sono parzialmente d'accordo. Per me potrebbero proibire ipv4 dall'anno prossimo e sarei sostanzialmente contento.

Certo la comodità di un tunnel rimane intaccata.
Tutti i vantaggi che sono stati già spiegati non cambiano.

Pensa solo ad eventuali attacchi ddos. Con cloudflare in mezzo che ha le spalle grosse puoi dormire sostanzialmente tranquillo.

[DjLode]

Originariamente inviato da barzokk

Detto questo, mi sembra che quando ci si vuole collegare, bisogna confermare visitando un loro link.

Puoi usare anche le Authkeys, quindi puoi automatizzare il tutto.
La chiave può essere settata come "never expiry" e te ne puoi dimenticare.

[destroyer85]

Originariamente inviato da matsnake86

Praticamente ovunque. Gira anche su un raspberry talmente è leggero.
Con l'immagine docker poi è talmente facile da risultare imbarazzante. Quando generi il tunnel ti danno già il comando da eseguire su podman o docker che sia.

Quindi anche un PBX proprietario, il dispositivo di allarme, il telecontrollo del riscaldamento...

Originariamente inviato da matsnake86

Di qualcuno ti dovrai fidare. Che sia un hosting, il tuo isp, il sistema operativo... Nella catena del software ci sarà sempre qualcosa al di fuori del tuo controllo di cui dovrai semplicemente fidarti.

L'hosting non c'entra perché stiamo parlando di una soluzione per esporre app su host interni, l'ISP può vedere al massimo il traffico http e non l'https checché ne dicano NordVPNisti, e il sistema operativo... va beh su questo non ti rispondo neanche...

Originariamente inviato da matsnake86

Su questo sono parzialmente d'accordo. Per me potrebbero proibire ipv4 dall'anno prossimo e sarei sostanzialmente contento.

Certo la comodità di un tunnel rimane intaccata.
Tutti i vantaggi che sono stati già spiegati non cambiano.

Pensa solo ad eventuali attacchi ddos. Con cloudflare in mezzo che ha le spalle grosse puoi dormire sostanzialmente tranquillo.

Ma infatti, e lo ripeto, state confondendo due cose NAT routing e questo servizio che apparentemente fanno la stessa cosa ma non sono la stessa cosa.

[Bello&Monello]

Originariamente inviato da Tasslehoff

Di fatto sì, nell'anno di grazia 2024, con il protocollo http che è diventato omnipresente e di fatto governa qualsiasi servizio esista, di fatto sì.

Poi tu puoi anche esporre un server ssh o LDAP o un listener Oracle con Cloudflare se proprio vuoi farti male.

Certo, ci sarà sempre il servizio di nicchia che gira solo su protocollo UDP o quello che rompe perchè deve nattare il client Bittorrent su UDP per scaricare qualche scemenza, ma non sono esempi significativi.

Di fatto da vent'anni (con l'introduzione dei web services) il protocollo http è diventato lo strumento di comunicazione standard per qualsiasi cosa, e http significa protocollo tcp, punto.

Non è da vedere, è un dato di fatto.

Domani devo pubblicare un servizio, se voglio farlo senza Cloudflare Tunnel devo:

1. Mandare una richiesta al centro operazioni rete per far configurare un nuovo vip su F5 per fare da reverse proxy
2. Mandare una richiesta al gruppo sicurezza rete per farmi aprire le porte dall'interfaccia di DMZ del vip F5 di cu sopra la cui interfaccia pubblica è nattata su un ip pubblico di un router
3. Mandare una richiesta al centro operazioni rete per far creare il record dns di turno per risolvere l'hostname con l'ip del vip F5
4. Mandare una richiesta al centro operazioni rete per richiede un certificato https, attendere lungaggini per l'acquisto o se sono fortunato attendere che qualche "mago" lo generi con Let's Encrypt su F5
5. Organizzare meeting per spiegare a ciascuno di questi perchè e percome occorre quello che è stato inserito nei ticket di cui sopra
6. Attendere settimane che ciascuno di questi gruppi faccia il proprio dovere (operazioni da 5 min che richiedono settimane di attesa)
7. Sperare che nessuno sbagli qualcosa e nel caso indire riunioni per far notare l'errore e correggere

Settimane per fare tutto questo, settimane buttate, fiumi di mail, richieste su ServiceNow, call e alla fine di questo calvario finalmente il servizio è pubblicato.

Con Cloudflare Tunnel?
10 minuti a esagerare, nessun gruppo da coinvolgere o a cui richiede ticket, aperture porte, regole fw, configurazione reverse proxy.
Nessun certificato https da richiedere, o da rinnovare, o da monitorare.
In più la protezione di una CDN con gli attributi, con un WAF che fa impallidire i ridicoli WAF enterprise (stile Imperva), riscritture configurabili via un pannello web based in tempo zero, protezione dei servizi con autenticazione form based e MFA o federazione SAML o OpenID prima del golive.

Perdonami ma non voglio ripetermi, ma i vantaggi sono talmente evidenti che non dovremmo nemmeno discuterne.

Perdonami ma mi sembra che tu stia andando a prendere degli esempi un po' "forzati" col solo scopo di dare supporto alla tua tesi.

Non sto dicendo che sia sbagliato quello che dici, ma fai esempi in infrastrutture parecchio burocratizzate come potrebbe essere un carrier o una grossa multinazionale.

Per fortuna non è sempre così. E non sempre devi per forza usare un F5.

Puoi anche avere clienti che lavorano in ambienti virtualizzati (ad esempio un VDC su un cluster NSX-T) che hanno davanti al loro ambiente un firewall che è collegato direttamente alla pubblica e su quel firewall gestisci comodamente i NAT.

Che con l'hardware di oggi non sono dispendioni in termini di CPU e RAM. Per nulla.

[Tasslehoff]

Originariamente inviato da Bello&Monello

Perdonami ma mi sembra che tu stia andando a prendere degli esempi un po' "forzati" col solo scopo di dare supporto alla tua tesi.

Non sto dicendo che sia sbagliato quello che dici, ma fai esempi in infrastrutture parecchio burocratizzate come potrebbe essere un carrier o una grossa multinazionale.

Per fortuna non è sempre così. E non sempre devi per forza usare un F5.

Puoi anche avere clienti che lavorano in ambienti virtualizzati (ad esempio un VDC su un cluster NSX-T) che hanno davanti al loro ambiente un firewall che è collegato direttamente alla pubblica e su quel firewall gestisci comodamente i NAT.

Che con l'hardware di oggi non sono dispendioni in termini di CPU e RAM. Per nulla.

No, chiaro che ho fatto un esempio estremo, però è per dire che usare una cosa del genere per l'esposizione di un servizio permette di risparmiare un sacco di tempo, un sacco di rogne e di concentrarsi su quello che è strategico, ovvero il servizio, non tutto il cucuzzaro di roba che ci sta attorno.

Non voglio passare per il PM di turno che parla per supercazzole, ma se io devo pubblicare un servizio mi interessa quello, firewall, appliance di sicurezza, nat, dns sono solo perdite di tempo, richiedono risorse specifiche, dispositivi specifici e quindi costi maggiori.

Ti faccio un esempio molto banale, se io sono una PMI e ho il classico rack nell'antibagno, mi basta avere connettività in outbound tale e quale a quella che ha chiunque di noi a casa (anche senza ip pubblico e dietro nat del provider in stile Iliad), e usando Cloudflare tunnel posso hostare servizi a piacimento senza bisogno di prendermi una appliance perimentrale, senza bisogno di qualcuno che la sappia configurare e metterci le mani, mi libero di tutte queste cose e mi concentro su quello che mi serve: pubblicare i miei servizi.

Mi libero perfino dell'onere di gestire i certificati https guarda, lo fa in automatico Cloudflare con la sua CDN.

Altro esempio (che mi è capitato non più di 6 mesi fa): migrazione di vm da Vmware presso un provider ignobile a Proxmox hostato su host baremetal da Hetzner.

1. migrato l'esposizione di tutti i servizi da configurazione classica con reverse proxy + nat (AS + reverse proxy Apache o Nginx, o Ingress Controller Nginx su K8s + reverse proxy Apache o Nginx di frontend) a Cloudflare Tunnel (bloccando nel frattempo l'accesso alle applicazioni in LAN, non serve --> maggiore sicurezza)
2. setup vpn site-to-site tra vecchio site con Vmware e nuovo su Hetzner
3. migrato le vm da Vmware a Proxmox
4. accese le vm e riconfigurato la rete affinchè potessero raggiungere i nuovi dns e default gateway della rete su Proxmox

FINE, tutti i servizi online dall'istante in cui le vm nuove hanno potuto fare traffico in outbound e cloudflared ha ripreso a contattare la CDN Cloudflare.

La migrazione più indolore che abbia mai affrontato, letteralmente la pace dei sensi, e sfido chiunque a fare qualcosa del genere in modo così indolore.

E se dovessi migrare ancora? Stop, sposto le vm, le rimetto in rete e tutto funziona sul nuovo site.

Capisci cosa voglio dire? E' un approccio talmente flessibile e che permette di tagliare tempi e costi in modo tale da far sembrare letteralmente preistorica la pubblicazione di servizi via nat + reverse proxy + risoluzione dns.

E la facilità con cui si può fare è mostruosa.

Puoi letteralmente pubblicare servizi da un container che gira sul tuo pc in tempo zero, fare una demo con hostname pubblici, certificati https e tutto quello che può avere un servizio in produzione in 5 minuti, letteralmente.

[gsorrentino]

Originariamente inviato da matsnake86

Di qualcuno ti dovrai fidare. Che sia un hosting, il tuo isp, il sistema operativo... Nella catena del software ci sarà sempre qualcosa al di fuori del tuo controllo di cui dovrai semplicemente fidarti.

Appunto. Se ho un IP pubblico mi fido solo del sistema operativo.

Nel caso citato mi fido (molto ma molto) pure di altra società che legge il mio traffico...

Originariamente inviato da Tasslehoff

Non voglio passare per il PM di turno che parla per supercazzole, ma se io devo pubblicare un servizio mi interessa quello, firewall, appliance di sicurezza, nat, dns sono solo perdite di tempo, richiedono risorse specifiche, dispositivi specifici e quindi costi maggiori.

Ti faccio un esempio molto banale, se io sono una PMI e ho il classico rack nell'antibagno,
........

mi libero di tutte queste cose e mi concentro su quello che mi serve: pubblicare i miei servizi.

Dipende. Se i tuoi servizi richiedono altri servizi, in determinati settori, quello che dici NON funzionerebbe per nulla in quanto essendo servizi ad alta garanzia richiedono scambi di certificati e IP noti o, in alternativa, VPN IPSEC con regole molto rigide.

Altro esempio (che mi è capitato non più di 6 mesi fa): migrazione di vm da Vmware presso un provider ignobile a Proxmox hostato su host baremetal da Hetzner.

........

Spento un FW, acceso quello nuovo con la stessa configurazione del vecchio site, spostato i dns, migrato le VM in funzione da un site all'altro senza interrompere i servizi se non i 10 minuti dei FW e DNS.

Probabilmente la migrazione ha richiesto più tempo in background della tua, ma con un totale di oltre 80 VM e 100 TByte di datastore senza interrompere i servizi....

[gsorrentino]

Originariamente inviato da marcram

Dipende...
Io preferisco usare un servizio tipo TailScale, o ZeroTier, piuttosto che avere un indirizzo fisso che possa essere preso di mira...

Mi sembrano una specie di Hamachi evoluto e (troppo) semplificato o sbaglio?