28/01/2018, 08:38
Carissimi tutti, vi leggo da diverso tempo e vi ringrazio.
Grazie a voi ho finora fatto tutto quello che desideravo con Raspberry e ho risolto tutti i problemi che ho incontrato.
Ora ho deciso di iscrivermi perché proprio non ne vengo fuori e avrei bisogno di un vostro parere e consiglio.
Uso Raspberry principalmente come mediacenter con OSMC.
Ho tuttavia installato alcuni servizi, tra cui Apache, MySQL, per far girare un sito su Wordpress e in aggiunta OwnCloud e Transmission.
Ho anche un abbonamento annuale ad un servizio VPN a pagamento che uso tranquillamente con OpenVPN.
Il dilemma è questo:
1) vorrei che Raspberry fosse accessibile da remoto per i servizi di mio interesse (SSH, Wordpress, OwnCloud e Transmission) anche se è connesso costantemente alla VPN.
2) vorrei, al tempo stesso, che Raspberry non possa connettersi ad internet in caso la VPN cada (anche detto "killswitch").
Se prendo i due punti singolarmente, sono riuscito a fare tutto.
Non riesco però a configurare il tutto affinché le due condizioni coesistano.
In rete ho trovato questo articolo: https://serverfault.com/questions/425493...631#444631
Attraverso questo articolo ho risolto il primo punto, ossia quello di potermi connettere da remoto ai servizi interni di Raspberry anche se quest'ultimo è connesso alla VPN.
Ecco come ho risolto il primo punto:
dopo aver connesso Raspberry alla VPN con OpenVPN, da terminale do:
sudo ip rule add fwmark 65 table novpn
sudo ip route add default via 192.168.1.1 dev eth0 table novpn
sudo ip route flush cache
sudo iptables -t mangle -A OUTPUT -p tcp --sport 22 -j MARK --set-mark 65 #SSH/Ftp
sudo iptables -t mangle -A OUTPUT -p tcp --sport 9091 -j MARK --set-mark 65 #Transmission
sudo iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 65 #Apache
sudo iptables -t mangle -A OUTPUT -p tcp --sport 443 -j MARK --set-mark 65 #Https
Odio iptables, mi è proprio indigesto ma se non ho capito male, questi comandi creano una "strada parallela" alla VPN, dicendo al firewall di instradare tutte le richieste fatte alle porte 22, 9091, 80 e 443 su eth0 (sulla quale transita la normale connessione intenret) e non su tun0 (sulla quale transita invece il traffico instradato su VPN).
Bene, funziona!
Il problema nasce quando cerco di creare una regola di killswitch che conservi anche la validità delle regole precedentemente impostate.
Premetto che iptables è piuttosto difficoltoso per me. Ragion per cui, per creare il killswitch, mi sono affidato al buon caro UFW, con le seguenti regole:
# Blocca qualsiasi connessione
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default deny outgoing
# Permetti la connessione solo sulla rete VPN
sudo ufw allow in on tap0 from any to any
sudo ufw allow out on tap0 from any to any
# Permetti le connessioni sulla rete locale
sudo ufw allow out on eth0 from any to 192.168.1.0/27
sudo ufw allow out on wlan0 from any to 192.168.1.0/27
sudo ufw allow in on eth0 from 192.168.1.0/27 to any
sudo ufw allow in on wlan0 from 192.168.1.0/27 to any
# Abilita il firewall UFW
sudo ufw enable
Ora il "killswitch" funziona ma così facendo però, le regole impostate con UFW vanno ad annullare i benefici delle regole precedentemente impostate con iptables ed una volta attivato UFW, tutti i servizi interni non sono più raggiungibili da remoto.
Ho perso ore su ore nel provare impostazioni, comandi... ecc...
Sui forum inglesi ognuno dice la sua ma non ho trovato nessuna discussione che affronti la casistica di "VPN + Killswitch + Accesso da remoto"...
Mi viene anche il dubbio che effettivamente sia possibile fare quello che vorrei... dal momento che il Killswitch così impostato con UFW sembra preclude ogni possibile accesso a eth0.
Il problema è che digitando prima i comandi con iptables e poi quelli con UFW, prevale quanto scritto con UFW.
Anche se scrivo prima i comandi con UFW e poi quelli con iptables, UFW prevale e impedisce tutti gli accessi da remoto.
Possibile che non ci sia una soluzione?! Possibile che davvero non si possa fare...?
Chiedo scusa per essere stato prolisso, ma volevo esporre chiaramente il mio problema...
Grazie a voi tutti per ogni idea che possiate darmi.
Un abbraccio, Franco.
Grazie a voi ho finora fatto tutto quello che desideravo con Raspberry e ho risolto tutti i problemi che ho incontrato.
Ora ho deciso di iscrivermi perché proprio non ne vengo fuori e avrei bisogno di un vostro parere e consiglio.
Uso Raspberry principalmente come mediacenter con OSMC.
Ho tuttavia installato alcuni servizi, tra cui Apache, MySQL, per far girare un sito su Wordpress e in aggiunta OwnCloud e Transmission.
Ho anche un abbonamento annuale ad un servizio VPN a pagamento che uso tranquillamente con OpenVPN.
Il dilemma è questo:
1) vorrei che Raspberry fosse accessibile da remoto per i servizi di mio interesse (SSH, Wordpress, OwnCloud e Transmission) anche se è connesso costantemente alla VPN.
2) vorrei, al tempo stesso, che Raspberry non possa connettersi ad internet in caso la VPN cada (anche detto "killswitch").
Se prendo i due punti singolarmente, sono riuscito a fare tutto.
Non riesco però a configurare il tutto affinché le due condizioni coesistano.
In rete ho trovato questo articolo: https://serverfault.com/questions/425493...631#444631
Attraverso questo articolo ho risolto il primo punto, ossia quello di potermi connettere da remoto ai servizi interni di Raspberry anche se quest'ultimo è connesso alla VPN.
Ecco come ho risolto il primo punto:
dopo aver connesso Raspberry alla VPN con OpenVPN, da terminale do:
sudo ip rule add fwmark 65 table novpn
sudo ip route add default via 192.168.1.1 dev eth0 table novpn
sudo ip route flush cache
sudo iptables -t mangle -A OUTPUT -p tcp --sport 22 -j MARK --set-mark 65 #SSH/Ftp
sudo iptables -t mangle -A OUTPUT -p tcp --sport 9091 -j MARK --set-mark 65 #Transmission
sudo iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 65 #Apache
sudo iptables -t mangle -A OUTPUT -p tcp --sport 443 -j MARK --set-mark 65 #Https
Odio iptables, mi è proprio indigesto ma se non ho capito male, questi comandi creano una "strada parallela" alla VPN, dicendo al firewall di instradare tutte le richieste fatte alle porte 22, 9091, 80 e 443 su eth0 (sulla quale transita la normale connessione intenret) e non su tun0 (sulla quale transita invece il traffico instradato su VPN).
Bene, funziona!
Il problema nasce quando cerco di creare una regola di killswitch che conservi anche la validità delle regole precedentemente impostate.
Premetto che iptables è piuttosto difficoltoso per me. Ragion per cui, per creare il killswitch, mi sono affidato al buon caro UFW, con le seguenti regole:
# Blocca qualsiasi connessione
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default deny outgoing
# Permetti la connessione solo sulla rete VPN
sudo ufw allow in on tap0 from any to any
sudo ufw allow out on tap0 from any to any
# Permetti le connessioni sulla rete locale
sudo ufw allow out on eth0 from any to 192.168.1.0/27
sudo ufw allow out on wlan0 from any to 192.168.1.0/27
sudo ufw allow in on eth0 from 192.168.1.0/27 to any
sudo ufw allow in on wlan0 from 192.168.1.0/27 to any
# Abilita il firewall UFW
sudo ufw enable
Ora il "killswitch" funziona ma così facendo però, le regole impostate con UFW vanno ad annullare i benefici delle regole precedentemente impostate con iptables ed una volta attivato UFW, tutti i servizi interni non sono più raggiungibili da remoto.
Ho perso ore su ore nel provare impostazioni, comandi... ecc...
Sui forum inglesi ognuno dice la sua ma non ho trovato nessuna discussione che affronti la casistica di "VPN + Killswitch + Accesso da remoto"...
Mi viene anche il dubbio che effettivamente sia possibile fare quello che vorrei... dal momento che il Killswitch così impostato con UFW sembra preclude ogni possibile accesso a eth0.
Il problema è che digitando prima i comandi con iptables e poi quelli con UFW, prevale quanto scritto con UFW.
Anche se scrivo prima i comandi con UFW e poi quelli con iptables, UFW prevale e impedisce tutti gli accessi da remoto.
Possibile che non ci sia una soluzione?! Possibile che davvero non si possa fare...?
Chiedo scusa per essere stato prolisso, ma volevo esporre chiaramente il mio problema...
Grazie a voi tutti per ogni idea che possiate darmi.
Un abbraccio, Franco.