Hypervisor del laboratorio domestico irraggiungibile via VPN: dove guardare

Il tunnel si alza, la pagina web dell'hypervisor va in timeout e il client dice di essere connesso. Questa combinazione esclude moltissimo: l'handshake VPN funziona, il client ha un indirizzo e l'endpoint è raggiungibile. Quello che resta è un breve elenco di domande di routing e policy, e hanno un ordine naturale. Affrontatele dall'hypervisor verso l'esterno e non dal client verso l'interno, perché lo stato dell'hypervisor stesso è la cosa meno costosa da confermare.

Iniziate dal segmento di gestione

Confermate l'indirizzo di gestione dell'hypervisor e il servizio in ascolto su di esso, e confermate che la pagina si carica da un altro host di quel segmento prima di diagnosticare qualcosa da remoto. Un test locale che fallisce non è un problema VPN, ed è un controllo di cinque minuti che ne fa risparmiare un'ora.

Poi i due percorsi. Il client VPN ha bisogno di una rotta verso la rete di gestione, il che di solito significa che gli AllowedIPs del client o le rotte spinte includono quella sottorete. L'hypervisor, o il suo gateway predefinito, ha bisogno di un percorso di ritorno al pool di indirizzi dei client, a meno che il progetto traduca deliberatamente la sorgente in ingresso. Sono due fatti separati e la mancanza di uno dei due produce lo stesso timeout. Verificateli separatamente: ip route get 192.168.10.20 sul client, e una cattura sull'host hypervisor che mostri se il pacchetto è arrivato o no.

Consentite l'amministratore remoto reale

L'autorizzazione è una questione separata dalla raggiungibilità. Usate policy di gateway e host limitata alle sorgenti e ai servizi che necessitano di accesso di gestione. Un account VPN ospite che necessita di un'applicazione del laboratorio non dovrebbe per questo raggiungere il piano di gestione, e una regola piatta che ammette l'intera sottorete del tunnel è il modo in cui ciò accade.

Lasciate attive l'autenticazione dell'hypervisor stesso e i controlli dei certificati. Una rotta privata non è un motivo per cliccare attraverso un avviso di identità inatteso.

Vale la pena trattare l'avviso come un riscontro e non come un ostacolo. Se il certificato non corrisponde al nome usato, o il nome è sbagliato o il servizio non è quello che pensate, ed entrambe le risposte contano più su un'interfaccia di gestione che altrove. Raggiungete la pagina con il nome per cui il certificato è stato emesso, e lasciate che il DNS punti quel nome all'indirizzo del tunnel. Un nome privato che si risolve in modo incoerente tra la LAN e il tunnel è una causa comune di lamentele sui certificati che sembrano guasti VPN.

Controllate le connessioni secondarie

Alcune funzioni usano connessioni che la pagina web non usa. Una sessione console, un caricamento ISO, un proxy VNC o SPICE e un canale di migrazione possono usare ciascuno una porta diversa o un indirizzo host diverso. Quando la pagina si carica e una funzione fallisce, leggete il requisito di quel prodotto invece di aprire ogni porta sull'host.

Aprire tutto è il modo in cui un'interfaccia di gestione diventa non gestita. Ogni porta in più è un altro ascoltatore da tenere aggiornato, e un hypervisor ne espone già abbastanza. Individuate la connessione specifica necessaria alla funzione, confermate che è raggiungibile attraverso il tunnel e lasciate il resto chiuso. Se la funzione insiste su una connessione diretta a un indirizzo host non instradabile attraverso il vostro tunnel, è un vincolo di progetto da aggirare deliberatamente, non un motivo per inoltrare un intervallo.

Tenete una via di ritorno prima di toccare la rete

Prima di modificare la rete virtuale che trasporta la vostra VPN, confermate di avere una via di ritorno locale o indipendente.

Questo conta soprattutto in un laboratorio domestico, perché l'endpoint VPN è spesso una macchina virtuale proprio sull'hypervisor che cercate di raggiungere. Cambiare uno switch virtuale, un bridge o una regola del firewall da remoto può rimuovere il percorso che state usando, e la sessione può sopravvivere abbastanza da vederlo accadere.

Provate dall'esterno del laboratorio e non dalla LAN, e verificate i rifiuti oltre ai permessi. Una rete che deve restare irraggiungibile dal tunnel deve restarlo anche dopo la vostra modifica, e questa è un'affermazione separata dal caricamento della pagina di gestione. Annotate entrambi i risultati, perché il secondo è quello che viene saltato e quello che conta quando il laboratorio cresce.

Il record da conservare è breve: l'indirizzo e il servizio di gestione, la rotta necessaria a ciascun lato, le identità autorizzate a raggiungerlo e la via di ripristino. Basta perché la persona successiva riproduca lo stato funzionante senza doverlo dedurre di nuovo.

Se la pagina va ancora in timeout dopo tutto questo, catturate sull'hypervisor e cercate il pacchetto prima di cambiare un'altra regola. Un pacchetto che non arriva mai è una questione di routing o firewall; un pacchetto che arriva e viene rifiutato è una questione di servizio o policy; un pacchetto che arriva e riceve risposta mentre il client attende è una questione di percorso di ritorno. La documentazione di strongSwan sull'inoltro spiega come un gateway Linux inoltra il traffico del tunnel a un host interno. Tre catture battono un'altra supposizione.