Due alias SSH, un server: VPN diretta o host di salto

Mantenete un percorso VPN approvato e un percorso bastion approvato come alias e segnalibri separati, così nessuna scorciatoia deve indovinare quale rotta è autorizzata.

Lo stesso server privato risponde su una VPN approvata e attraverso un bastion approvato, e volete un segnalibro Emacs per ciascuno invece di una scorciatoia che indovina. La decisione non è quale percorso sia migliore; è quale percorso sia autorizzato per il lavoro che avete davanti. Tenete entrambi espliciti, nominate li separatamente, e lasciate che il nome del file dica quale avete scelto.

Prima condizione: quali percorsi sono approvati?

Un host di salto non è un ripiego automatico rispetto a un requisito VPN, e una VPN non è una licenza per saltare un bastion approvato. Chiedete quali rotte sono autorizzate per il vostro account e per questi dati. Se lo sono entrambe, avete una scelta; se lo è solo una, l’insieme di segnalibri ha una voce. Quella risposta viene dal proprietario dei dati, non dalla rotta che oggi funziona per caso.

Scrivete la risposta, perché la distinzione sparisce in fretta durante un incidente.

Entrambi i percorsi hanno bisogno anche della propria configurazione di account e identità. Un alias condiviso che funziona su una rotta può fallire sull’altra per ragioni che non hanno nulla a che vedere con la rete.

Seconda condizione: riuscite a nominare ogni percorso in modo distinto?

Una configurazione SSH può contenere due alias host per un indirizzo, ciascuno con un comportamento proxy diverso. Mettete i blocchi specifici prima di qualsiasi jolly ampio, perché il primo valore ottenuto vince per la maggior parte delle opzioni.

Host proj-direct proj-bastion
    HostName 10.60.0.21
    User analyst
    ControlPath none

Host proj-direct
    ProxyJump none

Host proj-bastion
    ProxyJump gw.example.com

L’indirizzo qui sopra è un esempio; sostituitelo con quello che documenta il vostro team. L’alias di salto ha bisogno anche dell’account approvato del bastion, il che di solito significa un secondo blocco Host per il bastion stesso. Disattivare qui la condivisione delle connessioni mantiene onesto il confronto dei percorsi, perché una connessione multiplexata riutilizzata può sopravvivere al cambio di rotta che state cercando di osservare.

Allora i nomi dei file remoti restano distinti e leggibili.

/ssh:proj-direct:/srv/project/README.md
/ssh:proj-bastion:/srv/project/README.md

Terza condizione: l’editor conosce la differenza?

TRAMP tratta quei due nomi di file come destinazioni diverse, che è esattamente ciò che volete. Segnate ciascuno con un segnalibro sotto un nome che dica quale percorso usa, e riaprite il segnalibro invece di modificare il significato di un’unica destinazione. Due segnalibri rendono visibile anche il confronto: potete aprire entrambi e vedere quale fallisce senza cambiare alcuna configurazione.

Un’impostazione merita attenzione quando è coinvolto ProxyJump: la condivisione delle connessioni di TRAMP deve essere disattivata per le connessioni pertinenti, quindi impostate tramp-use-connection-share su nil prima di aprirle. È un’impostazione di compatibilità, non una correzione per una rotta mancante, e non rende autorizzato un percorso non autorizzato. Le FAQ di TRAMP documentano i segnalibri come il modo supportato per accorciare questi nomi.

Un segnalibro che cambia rotta in silenzio è peggio di nessun segnalibro.

Perché l’icona di rete non dimostra nulla

Il valore globale di stato 70 di NetworkManager significa che la macchina ha connettività globale. Non nomina alcun profilo VPN, e il Wi-Fi ordinario lo soddisfa. Un tunnel solo per la rete privata che porta esattamente la rotta che vi serve può lasciare intatto quel valore aggregato. Per questo una scorciatoia legata all’icona può segnalare disponibilità per un percorso che non ha mai testato.

Leggete lo stato della connessione specifica invece di quello globale.

Se automatizzate qualcosa, interrogate la connessione denominata, poi verificate la rotta di destinazione, la risposta del resolver e la raggiungibilità SSH in quest’ordine. Ognuno di questi può fallire mentre il precedente riesce, e ridurli a un solo booleano è il modo in cui l’automazione finisce per segnalare successo per un percorso che non ha mai usato.

Cosa fare quando un percorso smette di funzionare

Salvate i buffer prima di indagare, perché una sessione TRAMP esistente può sopravvivere a un cambio di rotta e poi fallire alla scrittura successiva. Chiudetela tramite la pulizia supportata, riaprite il segnalibro e confrontate i due percorsi invece di supporre che il server sia inattivo.

Tenete attiva la verifica della chiave host sia per il bastion sia per la destinazione.

Un percorso diverso non vi autorizza ad accettare una chiave server che non vi aspettavate, né rende accettabile un percorso non approvato. Entrambe sono decisioni separate da quella che stavate prendendo.

Articoli correlati