VPN aziendale dentro WireGuard: quale strato viene prima?
Due client su una stessa macchina funzionano solo quando il tunnel esterno trasporta la connessione del client interno stesso e le metriche scelgono l'interfaccia giusta per ogni prefisso.
Esistono due ragioni legittime per annidare tunnel su un portatile da sviluppatore. O il client aziendale deve sembrare che provenga da un paese specifico, oppure due reti private devono essere raggiungibili contemporaneamente. In entrambi i casi il tunnel esterno deve trasportare la connessione del client interno stesso.
Avviare due client in un ordine qualsiasi non produce questo. Lo produce l'instradamento.
Confrontate i due ordini possibili
Scegliete lo strato esterno come il tunnel il cui endpoint è raggiungibile da internet pubblico. Lo strato interno è il tunnel il cui server risponde solo attraverso quell'uscita. Su Windows la divisione pratica è WireGuard fuori e il client aziendale dentro. Il fattore decisivo è il controllo.
Il client ufficiale WireGuard applica un file di configurazione completo, rotte e DNS inclusi. I client aziendali commerciali di solito nascondono entrambi. Mettere un client nascosto fuori vi lascia a indovinare il percorso sottostante.
L'ordine inverso non è impossibile. È solo più difficile da ragionare, perché il client esterno riscrive le rotte secondo un calendario che non vedete mai.
Lasciate che AllowedIPs nomini solo l'intervallo aziendale
AllowedIPs elenca le destinazioni che WireGuard instrada nel tunnel. Per l'annidamento servono solo l'indirizzo del server interno e i prefissi aziendali. Tutto il resto resta sulla rete locale, stampanti e hypervisor inclusi. È un tunnel diviso per progetto, e evita del tutto il problema dell'esclusione.
Uno strato esterno a tunnel completo ha bisogno di 0.0.0.0/0 meno gli intervalli locali. Il formato non può esprimere un'esclusione, quindi il complemento va calcolato e incollato.
[Interface]
PrivateKey = ...
Address = 10.99.4.2/32
[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16
Quando il client interno non installa le proprie rotte, elencate voi stessi i prefissi aziendali. Un prefisso omesso da quella riga è una destinazione che il tunnel esterno non trasporta mai. Una copia obsoleta dell'elenco è peggio di nessuna, perché sembra ancora corretta.
Ordine, metriche e il secondo adattatore
Collegate prima il tunnel esterno, poi avviate il client aziendale. La sua connessione all'endpoint esce allora da WireGuard invece che dal gateway locale. Date all'interfaccia aziendale una metrica più bassa perché i suoi prefissi vincano per gli indirizzi che possiede.
# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1
# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40
wg show interfaces
Le metriche sono il passaggio che la gente salta. Senza un ordine, per il prefisso sovrapposto vince la rotta installata per ultima. Questo cambia tra un avvio e l'altro, ed è perciò che il problema sembra intermittente.
I client basati su OpenVPN 2.6 aggiungono una trappola propria. Quando l'adattatore di offload del canale dati è già occupato, una seconda istanza semplicemente si rifiuta di partire. Aggiungere disable-dco al profilo riporta al vecchio percorso TAP, e allora entrambi funzionano fianco a fianco.
Dove si rompe il percorso annidato
Disconnettere il tunnel esterno uccide quello interno. Riconnettere solo il client interno spesso lo manda direttamente su internet e rimuove in silenzio l'annidamento. Provate la sequenza da zero ogni volta, partendo con entrambi i tunnel fermi.
Aspettatevi una MTU utile più piccola. Ogni strato aggiunge overhead, quindi una coppia iniziale intorno a 1420 e 1400 è un punto di partenza. Un trasferimento che si blocca sui pacchetti grandi mentre le richieste piccole passano è il segno abituale. La politica aziendale è l'altro limite, perché un client che richiede un dispositivo gestito può considerare un percorso annidato una violazione.
Quando entrambe le estremità sono reti fisse, un tunnel site-to-site tra i gateway elimina il problema dell'ordine invece di gestirlo. Su un solo portatile, due tunnel coesistono solo quando ciascuno ha la propria interfaccia e una regola che seleziona le destinazioni per prefisso.