Gateway VPN di Windows: tre compiti, tre responsabili

Tre funzioni finiscono insieme ogni volta che qualcuno dice server VPN: chiudere il tunnel cifrato, spostare i pacchetti tra reti e, facoltativamente, riscrivere gli indirizzi. In Windows vivono in parti diverse dello stack, anche quando una sola macchina le svolge tutte. Ognuna ha i propri input e il proprio modo di fallire, e ognuna può essere affidata a un prodotto diverso. Separarle sulla carta è il modo meno costoso per mantenere comprensibile un piccolo impiego.

Un progetto leggibile nomina il responsabile di ogni flusso invece di descrivere la macchina come un ruolo.

Chiudere, inoltrare, tradurre

RRAS gestisce il tunnel per il caso nativo di Windows: autentica l’utente, assegna un indirizzo da un pool e decide quali destinazioni sono consentite. Un altro prodotto VPN può invece possedere il listener e l’adattatore virtuale, lasciando a Windows l’inoltro dei pacchetti decifrati. La documentazione Remote Access di Microsoft separa i ruoli VPN, da sito a sito e di routing, e installare il ruolo di routing non crea una seconda identità VPN. Aggiungere un’altra applicazione VPN non consegna nemmeno il suo adattatore a tutte le funzioni gateway esistenti.

La traduzione è il terzo compito e il più facoltativo. Arriva dopo l’inoltro e cambia l’indirizzo di origine che la rete remota vede. Se vi serve dipende da ciò che la rete di destinazione accetterà come origine, non dal fatto che la macchina si chiami gateway VPN.

A chi appartengono l’adattatore e il pool

Quando più prodotti condividono l’host, quattro cose richiedono un solo responsabile ciascuna: le porte di ascolto, la durata dell’adattatore, il pool di indirizzi client e le rotte. L’adattatore è il caso scomodo, perché un servizio VPN può crearlo dinamicamente e distruggerlo alla disconnessione. Trattare quell’interfaccia come una scheda di rete dal nome permanente e scrivere regole contro il suo nome funziona fino alla riconnessione successiva. Usate il punto di integrazione supportato dal prodotto invece di codificare il nome di un’interfaccia.

Il pool di indirizzi è la seconda collisione. Due prodotti che distribuiscono intervalli sovrapposti producono un routing che sembra corretto e non consegna nulla. Tenete i pool nello stesso documento delle rotte, così che una modifica all’uno sia visibile rispetto all’altro.

Preservare l’origine o riscriverla

Preservare l’indirizzo di origine del client mantiene la visibilità per utente: log, quote e regole del firewall possono distinguere un utente dall’altro. Il prezzo è che la LAN di destinazione ha bisogno di una rotta di ritorno verso il gateway, e qualcuno deve mantenerla. Riscrivere l’origine con NAT elimina quel requisito ed elimina la visibilità con esso. Scegliete deliberatamente e annotate quali informazioni la riscrittura nasconde.

L’accesso alla rete privata, l’uscita verso internet e le connessioni che terminano sul gateway stesso sono tre percorsi diversi. Non tutti richiedono lo stesso trattamento.

Descrivere il flusso in una frase

Una frase dovrebbe descrivere il progetto: quali client ammette questo servizio, quali risorse concede quella politica di inoltro e come il percorso di ritorno completa il flusso. Se la frase ha bisogno di un secondo livello NAT per essere vera, di solito è il segno che i pezzi precedenti non erano stati risolti. L’host è anche un confine condiviso di guasto e di fiducia, perciò una modifica al routing può influire sia sull’accesso degli utenti sia sull’amministrazione. Mantenete un percorso di ripristino indipendente per quest’ultima.

Tenete un inventario dei ruoli accanto alla configurazione: quale prodotto chiude, quale inoltra, quale traduce e chi può modificare ciascuno. Quell’elenco è ciò che rende verificabile la modifica successiva.

Quando la frase diventa poco chiara, aggiungere un altro livello di traduzione raramente la chiarisce. Toglierne uno di solito sì.