tunnel persistente su dispositivi remoti

allora, l'obiettivo e' il seguente:

a) al cliente lascio un apparecchio linux. in questo caso un server asterisk.
b) voglio gestirlo da remoto come se fosse collegato a me tramite logmein per windows, ma non c'e' niente di simile per linux. e poi non voglio servizi di terze parti. e poi è sufficiente una shell interattiva.
c) l'apparecchio linux ha accesso ad internet, ma non voglio che abbia indirizzi pubblici statici e/o porte aperte, o quanto meno non voglio imporre cio' al cliente.

soluzione trovata.

a) il server linux presso il cliente ha accesso ad internet tramite un default-gateway ed ha anche il dns configurato per benino. io spedisco la macchina al cliente e al telefono o con il foglietto lo configura in rete.
b) il server linux ha all'interno il pacchetto pptp (point-to-point protocol) in versione client.
c) pptp è configurato per cercare il mio server in dyndns
d) pptp è anche configurato per lanciare il tunnel all'avvio ed inoltre ha anche il seguente watchdog:

----------------------
#!/bin/sh
a=`/sbin/ifconfig grep \^ppp0 wc -l `
b=`/sbin/ifconfig grep 192.168.69 cut -f3 -d\: cut -f1 -d\ `
# 192.168.69.x è la subnet che ho scelto per gestirmi fino a 127 apparecchi remoti
# contemporaneamente
function giu_e_su
{
# echo rete giu
# echo allora la tiro giu del tutto
killall -9 pppd
sleep 10
# echo e poi la tiro su
/usr/sbin/pptp indirizzo-dyndns-del-server call tunnel
sleep 10
}
#
if test $a -eq 0
then
giu_e_su
else
# echo rete su
# echo indirizzo ptp $b
ping -c1 $b > /dev/null 2>&1
c=$?
# echo risultato del ping: $c
if test $c -eq 1
then
giu_e_su
fi
fi
----------------------

e) lato rete mia ho dovuto mettere a punto la configurazione del router cisco. mentre con un router fritz è stato semplice accettare i tunnel in ingresso, con cisco ho dovuto smanettare perchè l'access-list che configuro normalmente per il nat/pat era di livello 40.
sono dovuto così passare ad una access-list di livello 101.
la cosa curiosa è che così non mi funzionava più il dns server, secondo i suggerimenti cisco.
la configurazione funzionante, nella sintesi delle cose più importanti, è la seguente:

----------------------
int eth 0
ip nat inside

int dialer0
ip nat outside

ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0

ip nat inside source static udp 10.0.0.253 53 interface Dialer0 53
ip nat inside source static tcp 10.0.0.253 80 interface Dialer0 80
ip nat inside source static tcp 10.0.0.250 1723 interface Dialer0 1723
ip nat inside source list 101 interface Dialer0 overload
access-list 101 permit ip 10.0.0.0 0.255.255.255 any
access-list 101 permit udp 10.0.0.0 0.255.255.255 any
access-list 101 permit gre any any
dialer-list 1 protocol ip permit
----------------------

notare che intendo pubblicare un web server e un dns server (all'indirizzo locale 10.0.0.253), oltre al server di tunnelling all'indirizzo 10.0.0.250

la configurazione pre-esistente aveva le seguenti righe differenti (non permetteva il tunneling)):

----------------------
ip nat inside source list 40 interface Dialer0 overload
access-list 40 permit 10.0.0.0 0.255.255.255
----------------------

mentre la configurazione cisco non funzionante aveva le seguenti righe differenti:

----------------------
access-list 101 permit ip any any
----------------------

cosa non funzionava? il web veniva pubblicato, ma il dns server no.

chissà perché.

in ogni caso, il kit è stato pacchettizzato.

ho un server con indirizzo anche dinamico che funge anche da vpn server.

ho un kit di software installabile sui server remoti che senza bisogno di servizi di terze parti e/o porte aperte sul router e/o porte mappate permette loro di fare "telefono-casa".

così se il cliente ha problemi nella gestione del centralino, facilmente posso fargli manutenzione.

questo è il lavoretto di oggi.