Newsgroup: it.comp.os.linux.sys
Titolo: Chiarimento su openvpn in tap

L'ultima volta che ho configurato un openvpn in tap tra un roadwarrior
e un server è stato 2 anni fa e mi devo essere dimenticato un
passaggio:
lan locale: 
192.168.1.0/24
device lan locale: eth0
device tap: tap100
lan roadwarrior: 
192.168.100.0/24
Dal roadwarrior riesco ad instaurare una connessione openvpn ed il
server riesce a fare il push delle route sul client. La vpn quindi va.
Sul client ho una route per 
192.168.1.0/24
 veicolata attraverso
192.168.100.1 (l'ip del server openvpn) che è proprio quella pushata
dal server dopo la connessione.
Ma non riesco a raggiungere la rete interna dietro il server vpn.
Il firewall sembra configurato a dovere. Ho messo due regole fatte
così:
iptables -A FORWARD -j LOG --log-prefix "FORWARD"
iptables -A FORWARD -j DROP
sopra tali regole ho solo vari ACCEPT per cui, non venendo loggato
niente inerente la vpn, non c'è nulla che vada in drop al termine
della catena.
Sul server ho una route per 
192.168.100.0/24
 via tap100 per cui dovrei
raggiungere senza problemi il roadwarrior.
Eppure un ping verso 192.168.100.2 (il RW) fatto dal firewall mi da
host unreachable.
Come è possibile? La route è presente, o meglio, è presente la tap100
con l'ip impostato e di conseguenza la route per tale rete.
Dimentico qualche cosa?
Ho volutamente semplificato, in realtà sul server ci sono ben 9 bridge
di rete con altrettante vlan e varie politiche di routing, ma non c'è
nulla che vada in conflitto con gli ip (subnet mask errate, ip
duplicati e così via).
192.168.100.0/24
 può essere raggiunto solo da tap100 eppure il server
non sa dove andarlo ad instradare.
Ultma cosa: può essere che aver messo in bridge tap100 con eth0 (la
lan locale da raggiungere via vpn) faccia a cazzotti?

 locale da raggiungere via vpn) faccia a cazzotti?
Uhm...fammi capire.
eth0 ha ip 192.168.1.x e tap100 192.168.100.1 e le due interfacce sono
in bridge, diciamo br100 per comodità.
E br100 non ha indirizzo, giusto?
L'host unreachable, in questi casi, sta a significare che il tuo firewall
non vede a layer2 il RW, perchè non riceve risposte all'arp whois.
Stai filtrando anche arp, per caso?
La domanda che poi mi sorge spontanea è: a che ti serve mettere in bridge
tap100 e eth0?

 tap100 e eth0?
Non fare queste domande, suvvia :-)

 Non fare queste domande, suvvia
Davvero, non ne vedo il senso, da quanto hai descritto.
Tu vorresti instardare traffico tra 
192.168.100.0/24
 e 
192.168.1.0/24
: a che
diamine ti serve mettere in bridge le due interfacce attraverso le quali
vorresti instradare tale traffico?

 vorresti instradare tale traffico?
Inizialmente il tap100 doveva condividere il range di eth0.
Su eth0 ho ip fissi da 50 a 100, dhcp da 150 a 200 e volevo mettere
dhcp della vpn da 220 a 230.
Così facendo, mi bastava fare un bridge per connettere le reti.
Ma non son riuscito a far attivare la vpn.
Cambiando parametri di openvpn e cambiando subnet la vpn sta su
ma non comunicano le reti.
Il problema non era tanto il range di ip, ma la configurazione vpn.
Per dare un range da 220 a 230 dovevo utilizzare determinati parametri
di configurazione che fanno a cazzotti con altri.
Nella fretta (il caldo mi da alla testa e volevo andar via) ho rimesso
tutto come era inizialmente (range ip differenti), ho abilitato il
forward tra le due reti ma ho dimenticato il bridge attivo.
Questo bridge, può dar problemi?

 vorresti instradare tale traffico?
Non solo non ha senso, ma fa a cazzotti con tutto il resto.
Tolto il bridge, la vpn ha iniziato a funzionare.
Ma:
quando dal RW cerco di accedere ad una rete connessa dietro il firewall
vpn, questo è quello che vedo nel log:
Jul 10 11:27:06 gss kernel: FORWARD-DROP: IN=tap100 OUT=br20 
SRC=192.168.100.2 DST=10.0.20.101 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 
DF PROTO=ICMP TYPE=8 CODE=0 ID=25892 SEQ=136
br20 è una delle reti che devo connettere (una delle 8).
Giustamente va in DROP, perchè non ho abilitato il forward tra tap100 e 
br20. Mi son dimenticato.
Ora l'ho abilitato, nei log non vedo nulla, ma non pingo ugualmente.
ale@rw:~$ ping 10.0.20.101 -c 1
PING 10.0.20.101 (10.0.20.101) 56(84) bytes of data.
^C
--- 10.0.20.101 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
ale@vpn:~$ ping 10.0.20.101
PING 10.0.20.101 (10.0.20.101) 56(84) bytes of data.
64 bytes from 
10.0.20.101
: icmp_seq=1 ttl=64 time=61.5 ms
64 bytes from 
10.0.20.101
: icmp_seq=2 ttl=64 time=58.2 ms
^C
--- 10.0.20.101 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 58.261/59.901/61.542/1.658 ms
dal roadwarrior non pingo, ma l'apparato è funzionante, dalla server vpn
infatti pingo correttamente.
Iptables non droppa, i log non indicano nulla.
E poi, più semplice di così si muore:
$IPTABLES -A FORWARD -i $VPNIF -o $INTIF -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $VPNIF -j ACCEPT
$IPTABLES -A FORWARD -i $VPNIF -o $CAMIF -j ACCEPT
$IPTABLES -A FORWARD -i $CAMIF -o $VPNIF -j ACCEPT
$IPTABLES -A FORWARD -i $VPNIF -o $VOIPIF -j ACCEPT
$IPTABLES -A FORWARD -i $VOIPIF -o $VPNIF -j ACCEPT

 E poi, più semplice di così si muore:
Infatti.
Ciao.

 Ciao.
Però non va....

 Però non va....
Uhm...log nulla?

 Uhm...log nulla?
No, ma ti dico io cos'è.
100 a 1 il server windows non ha il default gateway giusto.
In ingresso i pacchetti arrivano fino al server, poi il server
non sa come rispondere.
Io non ho accesso al server, per cui attendo che il tecnico
faccia i dovuti controlli.
Al 100% è quello il problema, tempo fa cambiai l'ip del
gateway ed il tecnico non l'ha mai cambiato sul server ed
inoltre riesco a pingare quasi tutti gli apparati tranne quelli
che non gestisco direttamente io (e quindi hanno l'ip del gateway
errato)