Una NIC o due? Decidere la disposizione delle interfacce di un server VPN
Un singolo adattatore può trasportare la connessione cifrata e il traffico del tunnel. Scegli una o due NIC in base alle esigenze di routing, non a una regola hardware.
Un solo adattatore fisico basta per molti server VPN, e non è comunque una soluzione universale. La connessione cifrata arriva su quell'adattatore, il processo VPN la decifra, poi il traffico interno esce attraverso un'interfaccia virtuale prima di raggiungere un servizio locale o una LAN instradata. Se funziona dipende da tre condizioni: dove si trova la destinazione, se la LAN ha un percorso di ritorno verso il pool dei client, e se un unico collegamento fisico condiviso offre l'isolamento che dichiarate. Rispondete a queste tre e il numero di adattatori ne consegue.
Le tre condizioni che lo decidono
La prima condizione è la destinazione. Un servizio sull'host VPN stesso si raggiunge solo tramite l'interfaccia del tunnel, mentre un host sulla LAN richiede inoltro e un percorso di ritorno. La seconda condizione è quel percorso di ritorno, perché il dispositivo LAN deve sapere come raggiungere il pool dei client, tramite una rotta o tramite traduzione sul server.
La terza condizione è la separazione. Un solo adattatore significa che ogni pacchetto, cifrato o meno, condivide un collegamento e di solito una catena di regole, quindi una dichiarazione di isolamento che dipende da hardware separato non è soddisfatta da una singola interfaccia. È un fatto sul percorso, non su come è configurato il sistema operativo. Potete comunque filtrare il traffico del tunnel, ma non potete rivendicare un confine che non avete.
Nessuna delle tre riguarda il numero di porte sullo chassis. Riguardano l'instradamento, la proprietà degli indirizzi e quanto il progetto dipenda dalla separazione fisica.
Due adattatori restano una scelta legittima quando zone fisiche, uplink separati, throughput o un percorso di ripristino fuori banda li giustificano. Sono requisiti concreti e vale la pena dichiararli prima che qualcuno ordini hardware.
Quando il servizio gira sull'host VPN
Il caso più semplice non richiede alcun inoltro. Il demone riceve i pacchetti del client sull'interfaccia del tunnel e li consegna a un socket locale, e la risposta torna indietro sulla stessa interfaccia. Per l'host, l'indirizzo del pool dei client è un vero indirizzo locale.
Due cose devono comunque essere corrette: il servizio deve ascoltare su un indirizzo raggiungibile dal tunnel, e il firewall dell'host deve accettare il traffico che arriva sull'interfaccia del tunnel. Entrambe si vedono nei comandi qui sotto.
ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1Vincolare un servizio solo all'indirizzo pubblico, o filtrare per errore l'interfaccia del tunnel, produce una connessione che raggiunge l'host e poi muore. Sembra un guasto VPN ed è di solito una decisione su socket o firewall.
Quando la destinazione è sulla LAN
È qui che un progetto a singolo adattatore si guadagna la fama di essere macchinoso. Il server deve inoltrare i pacchetti del client verso la LAN, e il dispositivo LAN deve rimandare le risposte al pool dei client. O portate quel pool come rotta sulla LAN, oppure traducete l'indirizzo sorgente sul server così che le risposte tornino al server stesso.
Entrambe le risposte sono legittime e falliscono in modo diverso. Una rotta di ritorno mantiene l'indirizzo client originale visibile alla destinazione, il che è buono per i log e cattivo per le regole firewall che presuppongono indirizzi LAN. La traduzione mantiene semplice la LAN e nasconde l'identità del client alla destinazione.
sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0Un percorso asimmetrico è il sintomo classico: la richiesta del client arriva, la risposta esce da un altro router e la connessione scade senza errori a nessuna delle due estremità. Catturate su entrambi i lati prima di concludere qualcosa sul tunnel.
Perché un alias non crea una seconda zona
Aggiungere un secondo indirizzo allo stesso adattatore, o creare un'interfaccia dummy per imitare una seconda porta, cambia molto poco. I pacchetti escono ancora dallo stesso collegamento fisico, dalla stessa porta dello switch e di solito dalla stessa catena firewall, quindi tra loro non esiste un nuovo confine. È comodità di configurazione, non segmentazione. Trattarlo come confine di zona è il modo in cui una dichiarazione di isolamento sopravvive solo sulla carta.
Una zona separata richiede una separazione reale nel percorso, ed è il requisito che un secondo adattatore soddisfa. Se una regola dipende dal fatto che il traffico verso la VPN non condivida mai un dominio di broadcast con il traffico verso la LAN, un solo cavo non può offrire quella proprietà, comunque sia indirizzato l'host.
Dove un prodotto documenta una topologia multi-interfaccia per una modalità specifica, seguite la documentazione di quel prodotto invece di inventare un espediente. I fornitori cambiano anche le topologie supportate tra le versioni, il che è un'altra ragione per leggere la guida attuale invece di uno screenshot di una vecchia procedura guidata.
Verificate la disposizione rispetto al traffico che consentite
Elencate le classi di traffico che il server deve trasportare: client verso host, client verso LAN, host verso LAN e la connessione esterna cifrata. Ogni classe ha una sorgente, una destinazione e un'interfaccia, e la disposizione deve soddisfarle tutte e quattro insieme. Un progetto che ne gestisce tre è di solito quello che genera ticket.
Poi confermate le interfacce reali e la cattura reale, non il diagramma nel documento di progetto. I comandi qui sotto stampano entrambe le viste.
ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5Se la cattura esterna mostra il traffico cifrato e la cattura interna mostra il traffico decifrato sull'interfaccia del tunnel mentre l'adattatore fisico trasporta entrambi, una sola NIC sta facendo il lavoro. Se la cattura interna è vuota, il problema è nel tunnel o nelle regole di inoltro, non nel numero di adattatori. Decidete la topologia da quelle due catture e dalla tabella di routing, e il prossimo cambiamento avrà qualcosa con cui confrontarsi.