Perché una VPN non può unirsi a una rete Wi-Fi senza server
Un tunnel ha bisogno di un punto di terminazione all’interno della rete di destinazione. I dettagli del Wi-Fi, un server locale o un’uscita commerciale non possono creare un accesso che la rete non ha mai offerto.
La richiesta di solito arriva come una versione della stessa speranza: puntare il client a una rete Wi-Fi e finire al suo interno. Non è ciò che fa un tunnel. Un tunnel collega un client a qualcosa che sta già ascoltando. Se la rete di destinazione non ha nulla in ascolto per l’accesso remoto, non c’è un altro estremo.
Un tunnel è una relazione, non un’impostazione
Un lato ascolta, l’altro si connette, ed entrambi concordano un protocollo e delle credenziali. Il lato in ascolto deve trovarsi all’interno della rete che vuoi raggiungere. Quella parte non può essere inventata dal client. Un profilo con l’indirizzo giusto e la rete sbagliata dietro produce un timeout, non un accesso.
Ecco perché la risposta onesta ad alcune di queste domande è che l’accesso remoto non esiste per quella rete. Aggiungere un protocollo, una porta o un client diverso non crea un punto di terminazione che il proprietario non ha mai distribuito.
I dettagli del Wi-Fi non sono credenziali del tunnel
Un SSID, una sottorete, un gateway e una passphrase sono fatti sull’essere dentro l’edificio. Nessuno di essi ti autentica presso un servizio altrove su Internet. Le reti di campus e alberghi pubblicano quelle informazioni per gli ospiti dell’edificio, non per i client su Internet.
Copiare una sottorete interna in un profilo VPN produce un tentativo di raggiungere un indirizzo che non è instradabile da dove ti trovi. Il tentativo fallisce prima che venga controllata qualsiasi credenziale, per questo cambiare il nome utente o il metodo di autenticazione non aiuta mai.
Se l’organizzazione gestisce un servizio di accesso remoto, la sua documentazione nomina il punto di terminazione e il metodo. Chiedi espressamente quei due fatti, perché altrimenti l’assistenza risponderà alla domanda che sente di solito, quella sul Wi-Fi.
Un’uscita non sceglie la tua rete di origine
Alcuni server rispondono solo ai client il cui indirizzo cade dentro un intervallo. È un controllo di origine. Un’uscita commerciale si trova fuori da quell’intervallo, quindi la connessione viene rifiutata prima che qualsiasi dato applicativo venga scambiato. L’aritmetica non cambia quando scegli un altro fornitore, perché l’indirizzo non è ancora quello che il server vuole.
Restano tre opzioni, e solo tre. Trova un punto di terminazione nell’intervallo consentito, usa un host di salto approvato che è già lì, oppure chiedi al proprietario di cambiare la politica. Qualsiasi altra cosa è una variante della speranza che il controllo non venga applicato.
Un tunnel locale cifra il segmento sbagliato
Un server legato all’interfaccia di loopback protegge il traffico tra due processi sulla stessa macchina. Oltre quel percorso di loopback, i pacchetti lasciano l’host esattamente come prima. La protezione che volevi per la rete non è mai esistita, anche se il costo di elaborazione è reale.
Quella disposizione ha un uso legittimo: testare un client, una rotta o una configurazione prima di distribuirla. Non è una misura di privacy e non è un modo per raggiungere una rete remota, e confondere le due cose porta a una grande quantità di configurazione sprecata.
Ciò che funziona davvero senza server
Quando un dispositivo non ha un percorso in ingresso stabile, lo schema utile è un punto d’incontro anziché una connessione diretta. Un relè ospitato all’esterno, un tunnel inverso dal dispositivo a un piccolo server che controlli, o un fornitore che offre indirizzamento in ingresso mettono tutti qualcosa di raggiungibile nel mezzo. Un abbonamento VPN consumer non è quella cosa, perché non colloca alcun punto di terminazione all’interno della tua rete.
ssh -N -R 2222:localhost:22 [email protected] ss -tlnp | grep 2222 nc -vz 198.51.100.7 2222
Il primo comando apre un tunnel inverso dal dispositivo a un relè, il secondo conferma l’ascoltatore locale e il terzo prova il percorso dall’esterno. Sostituisci l’indirizzo della documentazione con il tuo relè e conferma esplicitamente la direzione, perché le connessioni in uscita spesso riescono tramite la traduzione, mentre quelle in ingresso non richieste non arrivano mai.
Se l’obiettivo è semplicemente raggiungere un servizio che esiste già su una rete che controlli, metti il client sul dispositivo che ne ha bisogno. Condividere un tunnel da un portatile è un progetto di routing e traduzione con i suoi modi di fallire, e un client gestito di solito lo bloccherà.