Un client WireGuard non raggiunge un client OpenVPN?

Entrambi i tunnel si collegano, ogni client raggiunge il gateway, e nel momento in cui uno prova l’indirizzo dell’altro i pacchetti svaniscono. Niente è sbagliato in nessuna delle due strette di mano, e nessuna riemissione di chiavi lo cambia. Il gateway trasporta pacchetti IP normali non cifrati tra due delle proprie interfacce, quindi i protocolli non devono mai capirsi tra loro; ciò che serve loro sono tre cose che nessuna stretta di mano fornisce. Copertura della destinazione sul client di origine, proprietà della sorgente sul gateway e un percorso di ritorno sul lato remoto. Il sintomo è identico per tutte e tre, per questo vengono diagnosticate insieme.

Al sintomo manca un pezzo alla volta

Questo progetto usa un pool WireGuard 10.71.0.0/24 su wg1 e un pool OpenVPN 10.72.0.0/24 su tun1, entrambi terminano su un solo gateway. La richiesta in prova va da 10.71.0.5 a HTTPS su 10.72.0.30. Ogni passo qui sotto riguarda quell’unico flusso. Ogni verifica ha una firma di guasto diversa anche se l’utente le vive allo stesso modo, e di solito ne manca solo una delle tre alla volta.

Inizia confermando che entrambi i pool sono davvero su questo gateway e che l’inoltro è attivo nello spazio dei nomi in cui vivono i tunnel. Un gateway che termina entrambi i protocolli in spazi dei nomi diversi non inoltra nulla tra loro, e vale la pena escluderlo prima di leggere qualsiasi configurazione di peer.

Estendi la copertura della destinazione sul nodo radiale

Sul client WireGuard, la voce di peer esistente deve selezionare il gateway per la destinazione OpenVPN, il che significa che il prefisso di destinazione deve comparire nella lista consentita di quel peer. Aggiungerlo non crea un secondo tunnel; cambia quale peer il client sceglie quando cerca quell’indirizzo, e con wg-quick la rotta di solito segue la lista automaticamente.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lascia intatte le righe reali di chiave e punto finale, e ricorda che un gestore che usa Table = off non prende alcuna rotta da questa lista. In quel caso lo stesso prefisso deve essere installato nella tabella di routing del sistema da chi lo possiede, e una rotta mancante lì appare esattamente come un prefisso consentito mancante.

Mantieni la proprietà della sorgente sul gateway

La voce di peer di questo client sul gateway deve continuare a possedere esattamente l’indirizzo sorgente di quel client. Gli indirizzi consentiti vengono controllati in entrambe le direzioni: scelgono un peer per il traffico in uscita e validano che la sorgente di un pacchetto in entrata appartenga al peer che lo ha inviato. Mettere il pool OpenVPN nella voce del nodo radiale perché il nodo radiale vuole raggiungerlo è l’errore che manda il traffico verso il partecipante sbagliato.

AllowedIPs = 10.71.0.5/32

Leggi quella voce come una dichiarazione di proprietà e non come una comodità di routing. Tutto il resto a cui il client deve arrivare appartiene alla lista delle destinazioni del client, non all’idea che il gateway ha di ciò che questo peer può inviare.

Dai al lato OpenVPN una rotta di ritorno

La destinazione ora ha bisogno di una rotta verso la sorgente WireGuard, e per i client di un pool di solito arriva come rotta spinta dal server OpenVPN. Spingila solo ai client che devono averla, e conferma sul client che è stata accettata invece di dare per scontato che la direttiva sia stata applicata.

push "route 10.71.0.0 255.255.255.0"

La distribuzione delle rotte non è un’autorizzazione. Quando la destinazione sta dietro un altro client OpenVPN invece che nel pool, la proprietà della sua LAN e i suoi requisiti di inoltro entrano nel progetto, e la rotta spinta è solo la prima metà. Riformula il requisito come grafo prima di aggiungere direttive: quale nodo possiede quale prefisso e quale nodo inoltra verso di esso.

Consenti solo il servizio che volevi consentire

Con l’inoltro attivo e entrambi i pool instradabili, la domanda che resta è di politica. Scrivi la regola per il flusso concreto e non per la coppia di interfacce in generale, visualizzala in anteprima prima di applicarla e mantieni il percorso di ritorno con stato perché le risposte non vengano bloccate come nuove connessioni. Una prova a secco non costa nulla e mostra esattamente cosa verrebbe aggiunto.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Queste sono regole per il traffico inoltrato, distinte dalle regole di ascolto del gateway per i due servizi VPN. Aprire le porte UDP esterne non autorizza la richiesta interna, e autorizzare la richiesta interna non richiede SSH senza restrizioni verso il gateway né un permesso predefinito sull’inoltro. Anche il firewall della destinazione e il suo indirizzo di ascolto devono concordare, dato che un servizio legato a loopback rifiuta il pacchetto instradato con più cura. Una politica che copre solo un verso della conversazione di solito fallisce con una richiesta riuscita e una risposta silenziosa, che è il risultato più confuso dei tre.

Rotte reciproche di solito significano che non serve alcuna traduzione della sorgente, il che conserva l’indirizzo WireGuard sulla destinazione e rende leggibili i log. Non aggiungere un masquerading generale perché sono coinvolti due protocolli, e non rimuovere una regola di traduzione esistente senza sapere cosa ne dipende. Poi verifica l’unico flusso da un capo all’altro e prova anche una sorgente o una porta vietate: una stretta di mano che funziona su ciascun lato non dimostra né la rotta incrociata né l’isolamento.