Openvpn: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
m
(8 versioni intermedie di uno stesso utente non sono mostrate)
Riga 332: Riga 332:
Nel caso si abbia necessità di rendere un servizio, come un webserver, accessibile direttamente senza passare dal tunnel VPN è possibile procedere come segue.
Nel caso si abbia necessità di rendere un servizio, come un webserver, accessibile direttamente senza passare dal tunnel VPN è possibile procedere come segue.
{{Suggerimento|Prima di procedere si consiglia la lettura delle guide dedicate a [[Iproute2]] e [[Debian e iptables | IPtables]].}}
{{Suggerimento|Prima di procedere si consiglia la lettura delle guide dedicate a [[Iproute2]] e [[Debian e iptables | IPtables]].}}
1 - Creare una nuova tabella di routing, che sarà chiamata per semplicità "tab1".<br>
1 - Creare una nuova tabella di routing, che sarà chiamata per semplicità "tab1" (come descritto per esempio nella sezione ''Aggiungere tabelle di routing'' della guida di [[Iproute2]]).<br>
2 - Aggiungere le rotte standard del proprio computer a "tab1", ovvero le rotte definite in automatico dalla propria macchina quando non è in esecuzione alcun servizio VPN. Per esempio nel caso di macchina che funge da gateway sfruttando [[pppoeconf]] potrebbero essere sufficienti i seguenti due comandi:
2 - Aggiungere le rotte standard del proprio computer a "tab1", ovvero le rotte definite in automatico dalla propria macchina quando non è in esecuzione alcun servizio VPN. Per esempio nel caso di macchina che funge da gateway sfruttando [[pppoeconf]] potrebbero essere sufficienti i seguenti due comandi:
<pre>
<pre>
Riga 345: Riga 345:


Arrivati a questo punto il servizio prescelto dovrebbe essere normalmente raggiungibile attraverso la nostra interfaccia internet, tuttavia è importante sottolineare quanto segue:
Arrivati a questo punto il servizio prescelto dovrebbe essere normalmente raggiungibile attraverso la nostra interfaccia internet, tuttavia è importante sottolineare quanto segue:
# Le rotte e le regole create non sono permanenti, ovvero andranno perse al momento di un eventuale riavvio, quindi in tale caso l'utente dovrà nuovamente ripetere la procedura qui descritta. Il problema dovrebbe essere ovviabile dichiarando opportunamente i precedenti comandi nel file <code>/etc/network/interfaces</code>, come riportato nel seguente esempio che contiene una configurazione sia per l'interfaccia <code>ppp0</code> che <code>eth0</code>
* Le rotte e le regole create non sono permanenti, ovvero andranno perse al momento di un eventuale riavvio, quindi in tale caso l'utente dovrà nuovamente ripetere la procedura qui descritta. Il problema dovrebbe essere ovviabile dichiarando opportunamente i precedenti comandi nel file <code>/etc/network/interfaces</code>, come riportato nel seguente esempio che contiene una configurazione sia per l'interfaccia <code>ppp0</code> che <code>eth0</code>
<pre>
<pre>
auto dsl-provider
auto dsl-provider
Riga 360: Riga 360:
         netmask 255.255.255.0
         netmask 255.255.255.0
         network 192.168.1.0
         network 192.168.1.0
         broadcast 192.168.0.255
         broadcast 192.168.1.255
         post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
         post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
</pre>
</pre>
# Se non si dispone di un IP pubblico statico, ma solo dinamico, sarà necessario eliminare e dichiarare nuovamente il comando descritto al punto 3 ogni volta che detto IP pubblico cambia. A tale fastidio si può ovviare sostituendo alla regola del punto 3 una dichiarazione basata sull'uso dell'opzione <code>fwmark</code> e del target <code>mark</code> di IPtables, oppure creando uno script che ad intervalli regolari verifica il proprio IP pubblico attuale ed eventualmente aggiorna rotte e regole come necessario. A puro titolo esemplificativo si mostra lo script usato da chi scrive (e quindi ritagliato sulla propria specifica configurazione macchina):
* Se non si dispone di un IP pubblico statico, ma solo dinamico, sarà necessario eliminare e dichiarare nuovamente il comando descritto al punto 3 ogni volta che detto IP pubblico cambia. A tale fastidio si può ovviare sostituendo alla regola del punto 3 una dichiarazione basata sull'uso dell'opzione <code>fwmark</code> e del target <code>mark</code> di IPtables, oppure creando uno script che ad intervalli regolari verifica il proprio IP pubblico attuale ed eventualmente aggiorna rotte e regole come necessario. A puro titolo esemplificativo si mostra lo script usato da chi scrive (e quindi ritagliato sulla propria specifica configurazione macchina):
<pre>
<pre>
#!/bin/bash
#!/bin/bash
Riga 425: Riga 425:
         netmask 255.255.255.0
         netmask 255.255.255.0
         network 192.168.1.0
         network 192.168.1.0
         broadcast 192.168.0.255
         broadcast 192.168.1.255
         post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
         post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
         post-up /bin/ip rule add from 192.168.1.107 table 1
         post-up /bin/ip rule add from 192.168.1.107 table 1
</pre>
===== Script ausiliario =====
Poiché è scontato che prima o poi si finisca per dimenticarsi di ritornare alla configurazione di rete standard una volta finito di usare il servizio di streaming è possibile organizzarsi nel seguente modo per ridurre al minimo tale evenienza:
# usare un browser dedicato diverso da quello solito per usufruire dei servizi di streaming;
# evitare di avviare direttamente il suddetto browser, ma usare uno script apposito che si occupi anche di cambiare automaticamente il profilo di rete da usare.
Lo script indicato qui sotto, estremamente semplice, sfrutta il browser "Vivaldi" e <code>nmcli</code> (lo strumento a riga di comando per gestire network manager) per cambiare/ripristinare le configurazioni di rete:
<pre>
#!/bin/bash
# È necessario aver già creato entrambe le reti in Network Manager.
# Si suppone che l'IP di "NOVPN" sia 192.168.1.107
nmcli con down CONVPN
nmcli con up NOVPN
vivaldi indirizzo_web
nmcli con down NOVPN
nmcli con up CONVPN
</pre>
</pre>


2 894

contributi

Menu di navigazione