Chi dovrebbe possedere le rotte e il DNS quando openfortivpn si connette?

Quattro fasi si sovrappongono in una sessione openfortivpn funzionante. Il client si autentica al gateway e avvia una connessione TLS, poi esegue PPP dentro quella connessione, quindi riceve un indirizzo e informazioni DNS e infine applica le rotte dell'host e le impostazioni del resolver. Ogni fase può essere viva mentre la successiva non lo è, ed è per questo che «connesso» è una parola così scivolosa nei thread di supporto.

La decisione che elimina la maggior parte della confusione è chi possiede l'ultima fase. O il client VPN applica da solo le modifiche all'host, o lo fa un altro componente, e mescolare i due a metà è il modo in cui le rotte e i file del resolver finiscono per descrivere sessioni diverse.

Quattro fasi che sembrano una sola connessione

La prima fase è l'ammissione. un dominio di autenticazione con nome o un codice monouso, e riceve i parametri necessari per continuare. Quando il client stampa di essere connesso al gateway, significa che il trasporto TLS è attivo. Non significa che PPP abbia negoziato, e di certo non significa che un'applicazione interna sia raggiungibile.

La seconda fase è il collegamento PPP. Il client avvia un processo PPP contro il dispositivo di tunnel, e i due lati negoziano le opzioni del collegamento e gli indirizzi. Solo dopo l'host sa quali indirizzi locali e remoti usa la sessione, e solo allora una rotta verso il tunnel può avere senso.

La terza fase è applicare queste informazioni all'host, ed è qui che conta la proprietà. Il client può aggiungere le rotte e riscrivere la configurazione del resolver, oppure gli si può dire di farsi da parte e lasciare entrambe a qualunque cosa gestisca la rete su quella macchina. Il README del progetto le descrive come responsabilità separate anziché un unico comportamento automatico.

Chi modifica la tabella di routing

Per impostazione predefinita il client è il proprietario. Aggiunge una rotta verso il gateway tramite l'interfaccia fisica, una rotta per il peer del tunnel e rotte per le reti che la sessione può usare, poi le rimuove quando il processo esce. Quel default è comodo su un portatile con un solo gestore di rete e nessun altro software VPN.

Scegliete la cessione solo quando qualcos'altro possiede davvero il routing. Un'integrazione con il gestore di rete, uno spazio dei nomi di rete di un container o un agente di routing a livello di sito possono già sapere come installare e ripulire gli stessi prefissi. Passare l'opzione no-routes impedisce allora a due scrittori di contendersi la stessa tabella, una corsa che si manifesta come perdita intermittente di una sottorete anziché come un guasto pulito.

La sovrapposizione è la seconda ragione per cedere. Se le rotte spinte includono un prefisso che la rete locale già usa, il client non può risolvere il conflitto per voi. Qualcuno deve decidere se quel prefisso è raggiungibile attraverso il tunnel, il collegamento fisico o una rotta più specifica, e quella decisione appartiene a chi possiede la topologia.

La pulizia è la terza. Un client che va in crash prima di rimuovere le sue rotte lascia un buco nero che sopravvive alla sessione, e la connessione successiva può aggiungervi un duplicato sopra. Chi possiede il routing possiede anche la verifica che le vecchie voci siano sparite. Rendete quel controllo parte del percorso di avvio, non un passo di pulizia opzionale.

Chi possiede il DNS e il file del resolver

Il DNS è la stessa decisione con bordi più affilati. Il client può accettare i server DNS riportati dal gateway o dal peer PPP e scriverli nella configurazione del resolver dell'host. Su una macchina semplice è esattamente ciò che volete, perché i nomi interni si risolvono allora solo finché il tunnel è attivo.

Su un host Linux moderno il resolver può essere gestito da uno stub locale, e riscrivere il file del resolver alle spalle di quello stub produce una configurazione che sembra corretta e si comporta in modo incoerente. Se l'host esegue già un gestore di resolver, lasciategli possedere il DNS e alimentatelo con i server del tunnel tramite la sua interfaccia supportata. L'opzione no-dns del client è la scelta giusta lì, non un aggiramento.

Il DNS diviso è una questione separata da chi scrive il file. Inviare ogni query attraverso il tunnel è semplice e lento; inviare solo zone interne attraverso di esso richiede configurazione per dominio che la maggior parte dei client semplici non offre. Decidete quale comportamento serve all'host prima di abilitare le modifiche al resolver del client. Una scelta sbagliata qui sembra un'interruzione della risoluzione dei nomi anche quando il tunnel stesso va bene.

Privilegi, prontezza e la cessione

Creare il dispositivo di tunnel e modificare le rotte dell'host o lo stato del resolver richiede autorità di rete elevata. L'errore comune è concludere che quindi tutto debba girare come root, incluso il browser o l'applicazione che usa il tunnel. Mantenete piccola la parte privilegiata: il client e il suo file di configurazione, di proprietà di un amministratore, mentre le applicazioni utente conservano il loro account normale.

La prontezza dovrebbe essere definita per consumatore. Un supervisore può considerare il servizio avviato quando il processo del client è in esecuzione e il dispositivo di tunnel esiste. Un processo di backup dovrebbe considerare la VPN utilizzabile solo quando il suo endpoint di archiviazione risponde attraverso il tunnel. Sono controlli diversi, e usare il più debole per lo scopo più forte produce processi che partono troppo presto e falliscono a intermittenza. Scrivete la definizione scelta, perché un supervisore e un processo che non concordano sulla prontezza sono un ticket di supporto in attesa di accadere.

Provate il contratto con quattro osservazioni: la fase del gateway si completa, PPP assegna gli indirizzi, la rotta prevista è presente e una richiesta a un host interno riesce. Poi fermate il client e confermate che ciascuna di queste cose sia stata rimossa o ripristinata. Se l'host risolve ancora nomi interni o detiene ancora una rotta dopo la chiusura del tunnel, la cessione di proprietà è incompleta.