Hai chiesto: " Qualcuno può spiegare perché questo problema si verifica in primo luogo? "
Sulla base di quanto riportato nelle FAQ ufficiali di OpenVPN, scommetto che è causato da un problema di routing all'interno del motore OpenVPN.
Per chiarire meglio lo scenario, vorrei fare riferimento al diagramma seguente:
Qui puoi vedere:
- un "server" OpenVPN collegato alla rete interna HEADQUARTER (10.0.1.0/24)
- un "client" OpenVPN in esecuzione in un sito remoto e collegato alla rete remota 192.168.1.0/24
Anche
- stiamo assumendo che il tunnel OpenVPN sia stato istituito e:
- Il "server" OpenVPN è raggiungibile tramite la propria interfaccia tun , con l'indirizzo 10.10.0.1. Anche l'indirizzo P2P, utilizzato dall'interfaccia tun è 10.10.0.2 ( questo è importante per le discussioni successive, quindi sottolineiamo )
- OpenVPN "client" ha un'interfaccia tun con IP 10.10.0.2
Ora supponiamo che:
- il "Client" OpenVPN ha ridefinito il suo gateway predefinito, in modo da reindirizzare all'interno del tunnel tutto il traffico IP in uscita;
- il "Client" OpenVPN ha IP_FORWARDING abilitato e, come tale, può instradare i pacchetti provenienti dalla sua LAN interna (192.168.1.0/24) ( sto sottolineando questo punto, poiché è fondamentale per la nostra discussione ).
Con uno scenario simile, controlliamo in dettaglio cosa succede quando R_PC1 (192.168.1.2) invia un pacchetto, come una richiesta di eco, a L_PC1 (10.0.1.2):
- dopo aver lasciato la scheda NIC R_PC1, il pacchetto raggiunge il client OpenVPN;
- Client OpenVPN (configurato per fungere da router comune), instradalo secondo la sua tabella di routing. Poiché il gateway predefinito è il tunnel, invia il pacchetto al tunnel;
- Il pacchetto raggiunge l'interfaccia tun del server OpenVPN. OpenVPN lo "vedrà" e, poiché (server OpenVPN) sa che 10.0.1.2 è un indirizzo appartenente alla sua sottorete LAN, "inoltra" il pacchetto, da TUN a LAN;
- Il pacchetto raggiunge L_PC1.
Quindi va tutto bene ...
Ora controlliamo cosa succede con l'eco-risposta che L_PC1 risponde a R_PC1.
- echo-reply lascia la scheda NIC L_PC1 e raggiunge l'interfaccia LAN del server OpenVPN (10.0.1.1);
Ora, se vogliamo che OpenVPN Server sia in grado di raggiungere il sito remoto, dobbiamo definire il routing con una "route statica". Qualcosa di simile a:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2
Si prega di notare l'indirizzo P2P utilizzato come gateway .
Tali percorsi statici funzioneranno a livello di sistema operativo. In altre parole, è necessario che il sistema operativo instrada correttamente il pacchetto. Significa qualcosa del tipo: "Per favore, tutto il traffico indirizzato alla sottorete 192.168.1.0/24 deve essere inoltrato al motore OpenVPN, con il quale il sistema operativo è in grado di comunicare tramite l'indirizzo P2P". Grazie a tale percorso statico, ora ...
- il pacchetto lascia il contesto di routing del sistema operativo e raggiunge OpenVPN. L'istanza OpenVPN in esecuzione sul server OpenVPN. Quindi, a questo punto, il sistema operativo non ha altro da fare e tutto il routing (all'interno della VPN) viene lasciato al software del server OpenVPN.
Quindi, ora, il problema è: come, il software server openvpn, sarà in grado di decidere il percorso di un pacchetto, con SRC_IP 10.0.1.2 e DST_IP 192.168.1.2 ?
Si noti che, in base alla configurazione del server OpenVPN, non sa nulla della rete 192.168.1.0/24, né dell'host 192.168.1.2. E ' non è un client connesso. E ' non è un client locale. E così? OpenVPN, anche, sa che è non è il "OS-Router", in modo che non vuole veramente (e può ....) inviare il posteriore pacchetto al gateway locale. Quindi l'unica opzione, qui, è quella di generare un errore. Esattamente l'errore che stai riscontrando
Per dirlo con la lingua delle FAQ: " ... non sa come instradare il pacchetto su questa macchina, quindi rilascia il pacchetto ... ".
Come possiamo risolvere il problema?
Come puoi vedere dalla documentazione ufficiale , l'opzione iroute serve esattamente al nostro ambito:
--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server
to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to the
system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.
Quindi hai bisogno di un:
--iroute 192.168.1.0 255.255.255.0
da applicare (al server) quando il client OpenVPN si connette, ad esempio tramite un file di configurazione ad hoc definito sul server (client-config-dir, ecc.).
Se ti chiedi perché questo problema non si verifica al passaggio 2) sopra, la mia comprensione è che il client OpenVPN sa come instradarlo, perché sa che il tunnel VPN è un gateway predefinito.
Lo stesso non può essere fatto sul server OpenVPN, perché lì il gateway predefinito non viene tipicamente ignorato. Inoltre, considera che potresti avere un singolo server OpenVPN con un sacco di client OpenVPN: ogni client sa come raggiungere il server ma ... come può, il server, decidere quale è il client che funge da gateway per una sottorete sconosciuta?
Per quanto riguarda la tua prima domanda ( le regole richieste possono essere scritte in modo generico / una tantum? ), Mi dispiace ma non sto riscontrando il tuo problema. Puoi riformulare fornendo maggiori dettagli?