openvpn, czy można na chwilę zablokować i odblokować certyfikat użytkownika?

sethiel - 21-05-2010 11:55
Czy w OpenVPN można na chwilę zablokować certyfikat użytkownika, a w momencie kiedy jest potrzebny odblokować go?

Oraz drugie pytanie, rysunek poglądowy

komp1 podsiec1
| komp2 podsiec1
| |
-----------------------
Debian + openvpn
-----------------------
| |
| komp3 podsiec2
komp4 podsiec2
komp1 i komp2 są w podsieci za natem, podsiec ma adres 192.168.1.0/24
komp3 i komp4 podłączają sie openvpn'em do podsieci 1, dostają adresy z zakresu 10.0.1.0/24

komp3 i komp4 widzą komputerki komp1 i komp2
komp3 widzi komp4

Jak zrobić aby komp1 i komp2 widziały komp3 i komp4?

Innymi słowy, podsieć openvpn 10.0.1.0/24 widzi podsieci 192.168.1.0/24 i 10.0.1.0/24
podsieć wewnętrzną 192.168.1.0/24 widzi tylko podsieć 192.168.1.0/24

Jak zrobić by widziana była też podsieć 10.0.1.0/24?

Wpisy w firewallu:
iptables -I INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
iptables -I INPUT -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -j ACCEPT
iptables -t nat -I POSTROUTING -s 10.0.1.0/24 -o eth1.100 -j MASQUERADE wpisy w openvpn server.conf
push "route 192.168.1.0 255.255.255.0"
push "route 10.0.1.0 255.255.255.0"

Pacek - 21-05-2010 14:55
Ja mam to rozwiązane opcją:
tls-verify "/etc/openvpn/userlist.txt" Wszystko co nie znajdzie się na tej liscie jest odrzucane. Nalezy tam podać Common Name z certyfikaów wszystkich użytkowników a także bramy/serwera openvpn.

Nie będę cytował, ale zagadnienie nr 2:
Żeby komp3 i komp4 widział komputery komp1 i komp2 trzeba wprowadzić routing na komp3 i komp4.O ile w przypadku stacji łączących się do OpenVPN'a ten routing jest wymuszany opcją push, o tyle na stacjach komp1 i komp2 tego routingu nie ma.
Spróbuj zrobić na komp1 i komp2 (jeżeli to Windows) z wiersza polecenia (cmd):
route add 10.0.1.0 mask 255.255.255.0 10.0.1.1 gdzie: 10.0.1.1 to adres IP interfejsu OpenVPN (tun/tap). Mówiąc obrazowo działa to w taki sposób, że wszystkie pakiety adresowane do sieci 10.0.1.0/24 będą wysyłane przez interfejs OpenVPN'a. Bez tej reguły system nie wie jak ma wysłać pakiety.

sethiel - 21-05-2010 15:12
>Spróbuj zrobić na komp1 i komp2 (jeżeli to Windows) z wiersza polecenia (cmd):
route: zły adres bramy netmask Tam jest jedna karta sieciowa i jedna brama -> 192.168.1.1, więc ,,route add'' nie ma sensu.
To musi być gdzieś na serwerze do ustawienia,
Z serwera w końcu też nie mogę pingować klienta, a z klienta serwer mogę pingować.

Konfiguracja serwera: port 1194
proto tcp
dev tun
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
server 10.0.1.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 192.168.1.0 255.255.255.0"
push "route 10.0.1.0 255.255.255.0"
push "dhcp-option DNS 194.204.159.1"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3 Dodatkowo route print na kliencie wygląda tak: 0.0.0.0 0.0.0.0 79.162.43.104 79.162.43.104 1
10.0.1.0 255.255.255.0 10.0.1.5 10.0.1.6 1
10.0.1.4 255.255.255.252 10.0.1.6 10.0.1.6 30
10.0.1.6 255.255.255.255 127.0.0.1 127.0.0.1 30
10.6.6.6 255.255.255.255 79.162.43.104 79.162.43.104 1
10.255.255.255 255.255.255.255 10.0.1.6 10.0.1.6 30
79.162.43.104 255.255.255.255 127.0.0.1 127.0.0.1 50
79.255.255.255 255.255.255.255 79.162.43.104 79.162.43.104 50
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.2.0 255.255.255.0 10.0.1.5 10.0.1.6 1
192.168.4.0 255.255.255.0 10.0.1.5 10.0.1.6 1
192.168.1.0 255.255.255.0 10.0.1.5 10.0.1.6 1
224.0.0.0 240.0.0.0 10.0.1.6 10.0.1.6 30
224.0.0.0 240.0.0.0 79.162.43.104 79.162.43.104 1
255.255.255.255 255.255.255.255 10.0.1.6 10004 1
255.255.255.255 255.255.255.255 10.0.1.6 10.0.1.6 1
255.255.255.255 255.255.255.255 10.0.1.6 2 1
255.255.255.255 255.255.255.255 79.162.43.104 79.162.43.104 1
Domyślna brama: 79.162.43.104. route na serwerze jest taki (pomijam nieistotne dla sprawy wpisy):
10.0.1.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1.1
10.0.1.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 firewall: echo "1" > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/tcp_ecn
iptables -I INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
iptables -I OUTPUT -o tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

iptables -I INPUT -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -j ACCEPT
iptables -t nat -I POSTROUTING -s 10.0.1.0/24 -o eth1.1 -j MASQUERADE

Pacek - 22-05-2010 15:50
Jesteś w błędzie, ponieważ masz dwie karty sieciowe - fizyczna eth0 z adresem IP 192.168.1.1 oraz wirtualna tun0 o adresie 10.1.0.1 (chyba taki adres ma ta karta ponieważ nigdzie nie dałeś listingu z ifconfig.
Skoro sam serwer nie widzi klientów (nie może pingować) to przyczyny są dwie:
- zła trasa routingu i serwer nie wie przez którą bramę ma pchać pakiety do sieci 10.0.1.0/24
- włączona Zapora Windows na klientach, która domyślnie blokuje pakiety ICMP i to polecam sprawdzić w pierwszej kolejności zanim rozbabrze się configi ;)

bzyk - 24-05-2010 08:51
Ale po co grzebać w windowsach? Tam nie trzeba zadnych routigow ustawiac, o ile nie masz kilku bram.Jedyne co, to dodaj w ichnich firewallach regulki dla sieci lan po drugiej stronie vpna (tak zeby mozna bylo mapowac dyski, pingowac itp). O ile te firewalle oczywiscie sa w windowsach wlaczone.

No i doczytaj w dokumentacji openvpn o opcji client-config-dir.

Pacek - 24-05-2010 11:26
client-config-dir dotyczy tylko klientów OpenVPN, a Ci zgodnie z opisem sethiel'a są OK, więc tam nie potrzeba nic modyfikować. Klienci VPN widzą całą sieć bez żadnych problemów. Problem jest w drugą stronę, a więc "widzialność" z LANu klientów VPN. W przypadku kiedy są dwie sieci (a taki przypadek tu jest) to powinny być dwie bramy. Ja też używam OpenVPN i wygląda to u mnie tak:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
83.15.125.16 0.0.0.0 255.255.255.248 U 0 0 0 eth0
10.10.1.0 10.10.1.1 255.255.255.0 UG 0 0 0 tap0
10.10.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
0.0.0.0 83.15.125.17 0.0.0.0 UG 0 0 0 eth0 Interfejs eth0 to WAN, eth1 to LAN a tap0 to VPN. Sieć LAN nie potrzebuje bramy bo pakiety przechodzą w obrębie jednej sieci (wyznaczonej przez maskę). jednakże VPN i WAN potrzebują. Jeżeli nie ustawi się prawidłowych bram (tras routingu) to pakiety są jak dzieci we mgle. Nie wiedzą dokąd pójść ;)

bzyk - 26-05-2010 10:26

Problem jest w drugą stronę, a więc "widzialność" z LAN-u klientów VPN. W przypadku kiedy są dwie sieci (a taki przypadek tu jest) to powinny być dwie bramy. O do tego właśnie używane jest client-config-dir. Żeby lan za serwerem vpn mógł się łączyć z lanem klienta.
Odsyłam do dokumentacji;
http://www.openvpn.net/index.php/ope...ion/howto.html
W szczególności tego akapitu: Nie wiem jak u Ciebie, ale u mnie ten client-config-dir po prostu działa. Nie grzebię w żadnym Windowsie i nie ustawiam mu routingu (warunek - serwer vpn pracuje na tym ip co brama). No i lany klientów powinny mieć stałą adresację.

rpc - 27-05-2010 21:43
Pod tym linkiem to dość dokładnie opisałem:
http://rpc.one.pl/index.php/lista-ar...skryptem-hasem

Wystarczy użytkownika usunąć z listy nie trzeba nic robić z certyfikatem - plik userlist.txt