Rilevamento dei server NAT e consigli sul tunnel

Questo documento illustra come il pannello identifica automaticamente i server NAT, distingue i «NAT con porte configurabili» dai «NAT senza porte configurabili» e, quando necessario, guida l'utente all'uso di Operations tramite tunnel.

Prima di tutto: cosa è il NAT

Un server NAT è un server che «ha solo un IP di rete interna e nessun IP pubblico dedicato». Per esempio, molti VPS NAT economici ricevono dal provider un indirizzo di rete interna (come 192.168.x.x) e non è possibile accedervi direttamente da Internet, ma solo tramite il port mapping fornito dal provider (che inoltra una porta pubblica verso la tua rete interna).

Panoramica della funzione

Dopo l'aggiunta di un server, quando la connessione SSH riesce il pannello rileva automaticamente se la macchina è di tipo NAT (solo indirizzi di rete interna, nessun IP pubblico dedicato). Rilevato il NAT viene mostrato un piccolo badge sulla scheda del server e una spiegazione sintetica in cima a «Panoramica». L'utente può cliccare il badge giallo per confermare se quel server NAT consente di impostare da sé il port forwarding nel pannello del provider, e quindi decidere se è necessario usare Operations tramite tunnel.

Perché è necessario distinguere i NAT

«IP di rete interna» ≠ «serve il tunnel». I server NAT si dividono in due categorie:

Solo i «NAT senza porte configurabili» richiedono Operations tramite tunnel. Nei NAT con porte configurabili le porte si mappano da soli e l'uso è identico a quello di una macchina con IP pubblico: non devono ricevere avvisi ripetuti.

Principio di rilevamento

Dopo il successo della connessione SSH, il pannello esegue il comando di sola lettura ip -4 addr show, legge gli IP delle schede di rete locali del server e stabilisce se appartengono tutti a reti private:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10 (CGNAT, NAT di livello operator)
• 127.0.0.0/8, 169.254.0.0/16, 0.0.0.0/8

Se esiste anche un solo IP di un intervallo pubblico, il server è considerato «con IP pubblico» (non NAT); se sono tutti di rete interna, è considerato «NAT».

> Il comando di rilevamento è di sola lettura e non modifica alcuno stato del server. Il risultato viene scritto nel database: il rilevamento avviene una sola volta alla prima connessione, poi il risultato viene riutilizzato senza rallentare la connessione.

Posizione dei badge e delle spiegazioni

Una volta rilevato il NAT, l'avviso compare in due punti:

1. Scheda «Panoramica» del pannello di Gestione di sistema: cliccando «Gestione di sistema» sulla scheda di un server, nella prima scheda «Panoramica» compare il banner NAT corrispondente — i server con contrassegno giallo mostrano una spiegazione gialla (con le istruzioni per rimuoverlo), quelli con contrassegno rosso mostrano la guida al tunnel. L'avviso compare solo sui server NAT diretti e non ancora confermati, senza occupare spazio nella scheda.

2. Piccolo badge sulla scheda: sulla scheda resta solo un piccolo badge, con tre stati:

Il badge giallo NAT indica lo stato «da confermare»: cliccandolo si apre una finestra di conferma con due scelte:

• «Le porte vanno bene, rimuovi il contrassegno» → il badge scompare e non compare più alcun avviso;
• «Le porte non sono raggiungibili, contrassegna come serve tunnel» → il badge diventa rosso e si apre la guida a Operations tramite tunnel.

Il badge rosso Serve tunnel è un «avviso»: cliccandolo si va direttamente a Operations tramite tunnel + Tunnel di porta.

> Perché non è stata implementata una «rilevazione automatica della raggiungibilità delle porte»: il server del pannello e il server di destinazione possono trovarsi nello stesso data center, e la verifica dal pannello passerebbe dalla rete interna; un esito «raggiungibile» non significa che un visitatore esterno possa raggiungerlo, quindi il risultato non è affidabile. Per questo «serve tunnel» viene contrassegnato manualmente dall'utente nella finestra gialla.

Perché i server NAT «si disconnettono dopo un po'»

Presso il gateway del provider, i server NAT hanno un idle timeout (timeout delle connessioni inattive). Dopo qualche minuto di inattività della connessione SSH, il gateway la interrompe silenziosamente (TCP half-open) senza che nessuna delle due parti se ne accorga.

Il pannello risolve il problema alla radice in due modi:

1. keepalive attivo sulle connessioni SSH: dopo l'apertura di ogni connessione viene inviato un pacchetto di keepalive ogni 30 secondi, che sia evita l'interruzione per inattività del NAT sia permette di individuare subito le connessioni semi-morte.

2. pulizia periodica del pool di connessioni: un thread in background chiude ogni 2 minuti le connessioni inattive da più di 2 minuti, evitando l'accumulo illimitato di connessioni semi-morte.

Avvertenze

1. Il rilevamento dipende dal successo della connessione SSH: se il server è offline o la password è errata non è possibile rilevare nulla e il badge non viene mostrato.

2. Server senza badge: i server con IP pubblico, i telefoni Android (Termux) e i dispositivi già in tunnel (con tunnel_token) non mostrano il badge NAT — usano già canali propri e non hanno bisogno dell'avviso NAT.

3. Spazio per i casi particolari: in rarissimi casi di «NAT 1:1» (server con tutte le porte aperte) anche l'IP locale è di rete interna e il server verrà rilevato come NAT. In questo caso basta che l'utente scelga «Va bene» nella finestra di conferma: l'uso non ne risente.

4. Modificabile dopo la conferma: lo stato del badge dipende dalla conferma dell'utente e può essere modificato in qualsiasi momento cliccando sul badge.

Documentazione correlata

• Gestione server
• Operations tramite tunnel
• Tunnel di porta