VPN da sito a sito con CGNAT

Question

Scusa se l'ho postato nel posto sbagliato. Fammi sapere se devo spostarlo su un altro sito SE. Avanti con la storia ...

Il mio ISP di casa a volte (ma non in modo coerente) ci costringe a utilizzare un CGNAT, tuttavia ho bisogno di un accesso remoto ai dispositivi locali in modo affidabile (purché ci sia connettività Internet in primo luogo; nessun modo per evitare questo requisito :)) . Prima di cambiare ISP (il vecchio ISP mi dava sempre lo stesso indirizzo IPv4 pubblico) potevo semplicemente usare OpenVPN e farla finita.

Ora che CGNAT è una possibilità reale, OpenVPN non è più un modo affidabile per connettersi da remoto alle risorse della mia LAN. Quindi sto cercando un'altra soluzione abbastanza affidabile (mi consentirà diverse cose che sono entrambe richieste - accedere alle telecamere di sicurezza da remoto - e utile - invertire il server SSH sul posto di lavoro).

Ora per la configurazione:

• A casa, ho un Raspberry Pi. Modello 3 B + se è importante (sarei sorpreso, ma fornendolo per completezza). È dietro un mio router che si collega all'ISP (PPPoE). Ha pieno accesso alle risorse LAN. Ho un IPv4 privato e fisso (anche se ora con il problema CGNAT penso di rimuovere il requisito "fisso"; probabilmente non è così utile come prima averlo risolto comunque) e un indirizzo IPv6 instradato pubblicamente automatico (SLAAC, nessuna estensione della privacy) . Non garantisce che otterrò lo stesso / 64 dalla riconnessione alla riconnessione (e quindi gli indirizzi IP varieranno nel tempo).
• Fuori sede, ho un host AWS EC2 (il più piccolo, che è "gratuito" ma credo non lo sarà veramente). Ho IPv4 elastico e IPv6 configurato sull'host, con una corretta configurazione del gateway (ho perso molto tempo ma alla fine sono riuscito a farlo). Quindi tecnicamente potrei connettermi da qui al Pi tramite IPv6 (supponendo che esista un servizio DNS dinamico appropriato che Pi può utilizzare per IPv6) o da Pi all'host AWS su IPv4 e IPv6.
• Al lavoro, ho una rete altamente sorvegliata, per la quale desidero solo eseguire SSH inverso. Probabilmente posso semplicemente utilizzare l'istanza AWS come jump host e risolverlo molto rapidamente. Voglio dire, posso comunque eseguire il server SSH sull'istanza AWS sulla porta 443. Quindi non è un vero problema (la porta 22 è bloccata dal firewall di lavoro :()

Ciò per cui ho bisogno di aiuto è duplice:

1. Innanzitutto, come configurare la connessione diretta dal mio Raspberry Pi all'host AWS in modo che l'host AWS abbia accesso diretto a tutte le mie risorse LAN (eventualmente personalizzabili dalle mie regole firewall sul Raspberry Pi)
2. In secondo luogo, come garantire che questo supporto si avvii automaticamente ogni volta che il Pi viene riavviato (tendo a riavviarlo abbastanza spesso e anche le interruzioni di corrente causeranno riavvii involontari).

Nota che ho una soluzione alternativa, ma fa davvero schifo. Implica il riavvio del mio router tramite il servizio cloud TP-Link più volte ogni volta che ottengo un indirizzo IP CGNAT fino a quando non ne ottengo uno pubblico. Quindi il mio ISP è abbastanza utile da fornire un adeguato servizio di DNS dinamico in modo da poter risolvere il problema con il mio indirizzo pubblico (O il mio indirizzo privato, se ottengo CGNAT; non è così utile). Voglio essere in grado di dimenticare queste soluzioni alternative, davvero.

Answer 1

Alla fine l'ho capito da solo. Ho seguito i soliti tutorial:

• Innanzitutto, installa OpenVPN sia sul server (istanza EC2) che sul client (Raspberry Pi dietro CGNAT) e installa anche Easy-RSA solo sul server.
• Quindi, genera alcune cose usando Easy-RSA (informazioni prese direttamente dai tutorial sulle pagine della community di OpenVPN):
  • Prima di tutto, configura le variabili nel file "vars". Le impostazioni predefinite funzionano bene ma si consiglia di modificarle comunque.
  • Copia openssl-1.0.0.cnf in openssl.cnf (potrebbero funzionare anche altre versioni).
  • Esegui ./clean-all (questo cancellerà eventuali chiavi preesistenti e configurazioni extra, in modo da iniziare da una lavagna vuota).
  • Esegui ./build-ca (questo genererà keys / ca.crt e keys / ca.key; quest'ultimo deve essere protetto: puoi distruggerlo una volta che sei sicuro di non aver bisogno di aggiornare la configurazione per aggiungerne altri clienti. Il primo è il certificato che deve rimanere)
  • Esegui ./build-key-server per generare una coppia di chiavi del server. Solo il server lo richiede.
  • Esegui ./build-key per generare le chiavi per i client. Eseguilo una volta per client. L'ho eseguito solo una volta in totale, per il mio client "raspberrypi". I file generati dovranno essere copiati sul lato client.
  • Copia i file nella posizione a cui appartengono:
    • keys / ca.crt è necessario sia per il server che per il client.
    • keys / ca.key è necessario se si desidera aggiungere ulteriori client ed è l'elemento principale che si desidera proteggere. Se non hai bisogno della flessibilità extra, ti consigliamo di eseguire il comando "shred" su di esso o di spostarlo su un sistema sicuro noto (che potrebbe essere air-gap per quello che vale)
    • keys / raspberrypi. {crt, key} appartengono al client (nel mio caso, il client è raspberrypi, digiti il ​​tuo nome specifico per i client) e dovrebbe essere copiato di conseguenza sui client.
    • keys / server. {crt, key} rimangono sul server. Il file .crt viene inviato automaticamente a ogni tentativo di connessione, quindi non è necessario copiarlo manualmente sul client.
  • La parte Easy-RSA è ora terminata.
• Imposta OpenVPN sul lato server
  • La configurazione del server predefinita va bene, salvo alcune modifiche:
    • Le opzioni ca, cert e key devono essere aggiornate in modo che puntino ai file ca.crt, server.crt e, rispettivamente, server.key. Il file server.key dovrebbe essere protetto (autorizzazioni 0400), anche se non sono sicuro che sia effettivamente controllato.
    • Ho impostato "subnet topologia". Questo non è strettamente necessario ma è una buona cosa.
    • Ho cambiato la direttiva "server" in un altro intervallo IPv4 privato, per assicurarmi di non entrare in conflitto con un altro server OpenVPN (quello del mio router). Dopotutto, eseguirò un po 'di routing statico in seguito in modo che gli intervalli non si sovrappongano.
    • client-config-dir client (imposta la sottocartella "client" in modo che sia speciale e contenga configurazioni specifiche del client; questo è importante per il routing)
    • client-to-client continuo, di nuovo in modo che il routing funzioni correttamente.
    • Ho commentato l'opzione "tls-auth ta.key 0" in entrambi i casi; questo genera un avviso ma non ho bisogno della sicurezza aggiuntiva. Potrei rimuoverlo in futuro una volta che avrò capito come funziona. Per motivi di sicurezza è comunque estremamente consigliato avere questa opzione.
    • Ho aggiunto una dichiarazione push "route 172.31.0.0 255.255.240.0"per inviare il percorso alla rete privata di AWS verso il mio Raspberry Pi.
  • Inoltre, per il client è necessario disporre di un file client / raspberrypi (sempre in base al nome del client) che contiene iroute 192.168.1.0 255.255.255.0(in modo che il routing funzioni dall'istanza AWS verso il Pi e la rete domestica.
• Anche il cliente deve essere configurato
  • Imposta l'indirizzo remoto. Ho appena inserito l'indirizzo IP elastico che ho sulla mia istanza AWS, perché non cambierà fino a quando non ci mancherò.
  • Imposta le direttive ca, cert, key (ca to ca.crt, cert to raspberrypi.crt, key to raspberrypi.key).
  • Commenta la direttiva tls-auth, proprio come sul server. Deve corrispondere al server.
• Abilita i servizi SystemD (questo si occupa di abilitare il tunnel all'avvio). Sul server, systemctl enable openvpn@server; systemctl start openvpn@serverpresumendo che il file di configurazione sia /etc/openvpn/server.conf. Non è possibile utilizzarlo per le sottocartelle. Sul client è lo stesso tranne perché è client.conf per il nome del file che hai inserito openvpn@client.

Ora quello che mi resta è fare alcuni port forward, che però non sono oggetto di questa domanda.