openvpn, czy można na chwil

[sethiel]

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

Kod: Zaznacz cały

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:

Kod: Zaznacz cały

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

Kod: Zaznacz cały

push "route 192.168.1.0 255.255.255.0"
push "route 10.0.1.0 255.255.255.0"

[Pacek]

Czy w OpenVPN można na chwilę zablokować certyfikat użytkownika, a w momencie kiedy jest potrzebny odblokować go?

Ja mam to rozwiązane opcją:

Kod: Zaznacz cały

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):

Kod: Zaznacz cały

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]

>Spróbuj zrobić na komp1 i komp2 (jeżeli to Windows) z wiersza polecenia (cmd):

Kod: Zaznacz cały

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:

Kod: Zaznacz cały

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:

Kod: Zaznacz cały

          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):

Kod: Zaznacz cały

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:

Kod: Zaznacz cały

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]

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ć.

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]

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]

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.

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:

Kod: Zaznacz cały

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]

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/open-s ... howto.html
W szczególności tego akapitu:

client-config-dir -- This directive sets a client configuration directory, which the OpenVPN server will scan on every incoming connection, searching for a client-specific configuration file (see the the manual page for more information). Files in this directory can be updated on-the-fly, without restarting the server. Note that changes in this directory will only take effect for new connections, not existing connections. If you would like a client-specific configuration file change to take immediate effect on a currently connected client (or one which has disconnected, but where the server has not timed-out its instance object), kill the client instance object by using the management interface (described below). This will cause the client to reconnect and use the new client-config-dir file.

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]

Pod tym linkiem to dość dokładnie opisałem:
http://rpc.one.pl/index.php/lista-artyk ... ptem-hasem

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