Attivazione delle porte contro inoltro delle porte per un server VPN domestico
L’attivazione apre una mappatura dopo il traffico in uscita; l’inoltro mappa la porta in modo permanente. Un server VPN domestico ha bisogno del secondo, limitato all’ascoltatore reale.
L’inoltro delle porte e l’attivazione delle porte stanno nello stesso menu sulla maggior parte dei router domestici, ed è per questo che vengono trattati come due modi per fare un solo lavoro. L’inoltro è una regola statica: una connessione in ingresso su una porta WAN viene tradotta in un indirizzo e una porta interni fissi, che accada o meno qualcos’altro. L’attivazione è condizionale: il router sorveglia il traffico in uscita e apre una mappatura in ingresso solo dopo che esce una connessione corrispondente. Un server VPN aspetta che qualcun altro si colleghi per primo, quindi proprio quella condizione è l’unica cosa che non può mai soddisfare.
Due regole con cicli di vita diversi
Il NAT IPv4 è stateful. Quando un host interno invia un pacchetto verso l’esterno, il router crea una mappatura perché le risposte trovino la via del ritorno; un pacchetto in ingresso che non corrisponde a nessuna mappatura viene scartato, ed è questo comportamento che tiene un desktop non aggiornato fuori da internet. L’inoltro è una voce di traduzione permanente aggiunta a mano. L’attivazione è un buco temporaneo sorvegliato da un motivo di traffico.
La differenza pratica è il tempo. Un inoltro esiste dal momento in cui viene salvato finché qualcuno non lo cancella. Una mappatura attivata esiste dopo che il trigger scatta e si chiude con un timer di inattività, misurato in minuti su hardware di consumo, o subito al riavvio.
Nessuno dei due è più sicuro in astratto. Un inoltro espone una porta in modo continuo; un trigger la espone solo dopo un determinato traffico in uscita. Per un servizio che deve accettare il primo pacchetto da uno sconosciuto, solo uno dei due corrisponde al lavoro.
Perché l’attivazione non pubblicherà un server
Un server VPN è passivo per progetto. Il peer, che sia un portatile in un bar o un telefono su dati mobili, invia il primo pacchetto, e il router non ha alcuna mappatura per lui. Nulla all’interno ha avviato traffico verso la porta di attivazione, quindi la regola non scatta mai e la connessione muore prima che inizi lo handshake.
Dove l’attivazione sembra funzionare, qualcos’altro genera traffico sulla porta di attivazione: un client sulla LAN, una sonda di monitoraggio o i controlli in uscita del server stesso. La mappatura allora si apre per quell’unico host e si chiude quando il traffico si ferma, così il peer esterno successivo fallisce di nuovo mentre il primo successo resta nel registro e sembra una prova.
L’attivazione è anche di solito a host singolo. Molte implementazioni consentono a un solo dispositivo interno di tenere la mappatura alla volta, il che è esattamente sbagliato per un server che deve rispondere a più peer. La funzione fu costruita per applicazioni che aprono una connessione di controllo in uscita e si aspettano dati in ingresso su una seconda porta, e corrisponde ancora a quella forma.
Che cosa mappa davvero un inoltro
Un inoltro è una voce di traduzione: porta e protocollo WAN verso indirizzo e porta interni. Richiede un ascoltatore già in esecuzione dall’altra parte, e richiede che l’indirizzo interno resti dov’è. Un lease DHCP che si sposta su un’altra macchina manda ogni tunnel all’host sbagliato, in silenzio, quindi create la prenotazione prima della regola.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
Il protocollo conta più di quanto suggerisca il modulo. OpenVPN su UDP richiede un inoltro UDP, WireGuard richiede UDP, e i dati IPsec arrivano come ESP, protocollo IP 50, che non ha alcuna porta. Un modulo di inoltro che accetta solo TCP o UDP non può esprimerlo, quindi IPsec richiede passthrough o una mappatura statica uno-a-uno invece di una regola di porta.
Lo strato sopra il vostro router
Un inoltro controlla solo la traduzione che è vostra. Se l’indirizzo WAN non è vostro, come accade dietro un NAT dell’operatore dove gli abbonati condividono 100.64.0.0/10 come descritto in RFC 6598, la connessione in ingresso non raggiunge mai il vostro router perché il fornitore ha tradotto prima. Nessuna regola sul vostro dispositivo può correggere quell’ordine.
Il doppio NAT è lo stesso problema in miniatura. Il vostro router inoltra al router dell’ISP, che non ha alcuna regola corrispondente e scarta il pacchetto. O aggiungete la regola sul dispositivo esterno, oppure mettete il dispositivo esterno in modalità bridge e lasciate che il vostro tenga l’indirizzo pubblico.
Per questo il test deve venire dall’esterno. Un test dalla stessa LAN attraverso l’indirizzo pubblico dipende dal supporto hairpin NAT e può passare o fallire per motivi estranei alla regola; un telefono su dati mobili, o un amico su un’altra rete, è il controllo più pulito.
Limitate la regola, poi verificate entrambe le metà
Inoltrate una porta verso un indirizzo. Un intervallo aggiunto perché i primi tentativi fallivano è il modo in cui le interfacce di gestione finiscono su internet, e l’ascoltatore VPN non ha bisogno della pagina di amministrazione del router pubblicata accanto.
Conservate tutto ciò che già proteggeva quell’ascoltatore: identità tramite certificato o chiave, firewall dell’host, versioni aggiornate dei pacchetti. Un inoltro fa entrare un pacchetto; l’autenticazione decide se il pacchetto diventa un tunnel, e sono due guasti separati quando qualcosa va storto.
La verifica ha due metà. Lo handshake deve completarsi da una rete esterna, poi una risorsa privata dietro il server deve rispondere attraverso il tunnel. L’inoltro ammette la connessione del tunnel e nulla di più; l’instradamento e l’autorizzazione per 10.8.0.0/24 sono un’altra impostazione su un’altra schermata.
Decidete con tre domande
Tre domande risolvono la scelta più in fretta di qualsiasi tabella comparativa:
- Qualcosa si collega dall’esterno, come primo pacchetto? Allora usate l’inoltro, o un relè. L’attivazione non può aprirsi senza un traffico in uscita che non esisterà mai.
- Il buco deve sopravvivere al tempo di inattività? Allora usate l’inoltro, perché una mappatura attivata si chiude secondo il proprio calendario.
- L’indirizzo WAN è vostro per pubblicarlo? Se non lo è, correggete lo strato sopra prima di modificare qualsiasi regola.
Se la risposta a tutte e tre è no, che è il caso di un portatile che chiama da sé un fornitore commerciale, nessuna delle due regole serve. Un client dietro NAT funziona perché crea da sé la mappatura con stato, e questo copre la maggior parte delle persone che leggono una pagina sull’inoltro delle porte a mezzanotte.