Newsgroup: it.comp.os.linux.sys
Titolo: openvpn, roadwarrior multipli e bridge differenti

secondo voi si riesce a configurare openvpn per stare in ascolto su un singolo endpoint e quindi fare il bridge tra interfacce multiple in base al certificato usato per la connessione?
 
ad esempio:
 
roadwarrior1, certificato1, bridge tra tap0 e eth0
roadwarrior2, certificato2, bridge tra tap0 e eth1
 
e così via, senza dover mettere in piedi istanze multiple di openvpn

 e cosï¿œ via, senza dover mettere in piedi istanze multiple di openvpn
 
No, non puoi direttamente. Puoi perï¿œ fare un unico bridge e filtrare con
iptables o ebtables, anche se piï¿œ complesso.
 
Puoi, ma te lo sconsiglio vivissimamente, far girare openvpn come root e
fare eseguire uno script personalizzato che esegua il bridging come piï¿œ
ti aggrada. Ma ï¿œ andare a mettere il culo nelle pedate.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 ti aggrada. Ma ï¿œ andare a mettere il culo nelle pedate.
 
No no, non ci penso nemmeno.

 e fatto ciò, dovrei essere in grado di filtrare a livello di firewall.
 
Questo sì.


 che possono fare quel che vuoi tu.
 
il bridge non è fondamentale, ho tutti protocolli ruotabili, anche
se avere un bridge attivo mi semplificherebbe parecchie cose.
 
Da quel che ho letto, nel CCD posso mettere le ruote da inviare al client
e l'ip da assegnargli, una volta che assegno una /30 e metto la route che
guarda il resto della sua vlan, sono a cavallo, poi mi resto solo filtrare
il traffico in forward dalla /30 verso una data vlan e droppare il resto.
(e per farlo, posso scriptare le regole di netfilter e tenerle sempre attive,
anche a VPN spenta)
 
In sostanza:
iptables -s 
10.0.0.0/30
 -d 
10.10.0.0/26
 -j ACCEPT
iptables -s 
10.0.0.0/30
 -j DROP
iptables -s 
10.10.0.0/26
 -d 
10.0.0.0/30
 -j ACCEPT
iptables -s 
10.10.0.0/26
 -j DROP

 che è possibile farlo mediante una apposita direttiva in configurazione.
 
Certo, mediante ccd puoi sparare route e anche l'associazione utente-ip.
Non mettere però limiti allla "creatività" degli utenti...
 
Esempio semplice semplice:
Questo è l'indirizzo che normalmente mi assegna un server vpn
 
client:~# ip addr ls dev tap3
159: tap3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 9a:fd:8e:c8:69:b6 brd ff:ff:ff:ff:ff:ff
    inet 
172.17.57.2/24
 brd 172.17.57.255 scope global tap3
    inet6 fe80::98fd:8eff:fec8:69b6/64 scope link
       valid_lft forever preferred_lft forever
 
Lato server vediamo cosa ho nella arp cache:
 
 
server:~# ip addr ls dev tap1
36: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 00:ff:de:ca:4d:4d brd ff:ff:ff:ff:ff:ff
    inet 
172.17.57.1/24
 brd 172.17.57.255 scope global tap1
    inet6 fe80::2ff:deff:feca:4d4d/64 scope link
server:~# arp -an | grep 172.17.57
? (172.17.57.2) at 9a:fd:8e:c8:69:b6 [ether] on tap1
 
Nulla mi impedisce lato client di fare le seguenti porcate, ad esempio:
 
client:~# ip addr add 
172.17.57.5/24
 dev tap3
client:~# iptables -t nat -I POSTROUTING -d 172.17.57.1 -j SNAT --to 172.17.57.5
client::~# ping -c 2 172.17.57.1
PING 172.17.57.1 (172.17.57.1) 56(84) bytes of data.
64 bytes from 
172.17.57.1
: icmp_req=1 ttl=64 time=51.8 ms
64 bytes from 
172.17.57.1
: icmp_req=2 ttl=64 time=25.1 ms
 
e questo è ciò che osservo lato server
server:~# tcpdump -n -i tap1 icmp or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap1, link-type EN10MB (Ethernet), capture size 96 bytes
14:01:29.291261 IP 172.17.57.5 > 
172.17.57.1
: ICMP echo request, id 1730, seq 1, length 64
14:01:29.294462 arp who-has 172.17.57.5 tell 172.17.57.1
14:01:29.318493 arp reply 172.17.57.5 is-at 9a:fd:8e:c8:69:b6
14:01:29.318508 IP 172.17.57.1 > 
172.17.57.5
: ICMP echo reply, id 1730, seq 1, length 64
14:01:30.292197 IP 172.17.57.5 > 
172.17.57.1
: ICMP echo request, id 1730, seq 2, length 64
14:01:30.292240 IP 172.17.57.1 > 
172.17.57.5
: ICMP echo reply, id 1730, seq 2, length 64
 
Chiaro quali sono i potenziali rischi, vero?

 Chiaro quali sono i potenziali rischi, vero?
 
Si, ma mediante netfilter dovrei essere tutelato filtrando su ip sorgente
in base alla destinazione.