OpenVPN Туннель офис <-> Цех

Айлоха всем!
подскажите плиз какой надо добавить маршрут на сервер. VPN настраивал по этому манну http://forum.ubuntu.ru/index.php?topic=75483.0
единственное скажу не смог добавить вот это правило sudo

правильное

но все также не вижу с цеха офис

что не кто не подскажет ?

Данная тема уже подымалась.

Соединение офисов с помощью OpenVPN

Сам столкнулся со схожей проблемой. Долго с ней не возился, поставил две Железяки (Dlink).
Выложите конфиги, правила Iptables, и таблицы маршрутизации можкт быть что и всплывет.

Server ofess Debian 6
Wan ip 95.xxx.xx.xx
Lan ip 192.168.0.1
IredMail
squid + squidGuard
маршрутизацию и раздачу инета настроил по данному скрипту

Там добавил правило чтобы пакеты заворачивались на squid вот оно

так же открыл порт для vpn туннеля вот оно

route -n

iptables -L

iptables -L -v -n

iptables -L -v -n -t nat

конфиг vpn

Server Цех Debian 6
Wan ip 10.113.153.50
Lan ip 192.168.2.1
squid + squidGuard
маршрутизацию и раздачу инета настроил по данному скрипту

дам добавил правило чтобы пакеты заворачивались на squid вот оно

также открыл порт для vpn туннеля вот оно

route -n

iptables -L

iptables -L -v -n

iptables -L -v -n -t nat

конфиг VPN

На стороне openVPN сервера в папке ccd есть файлики c именами ваших клиентов содержимой файлов примерно такое:
push "route 192.168.1.0 255.255.255.0"
iroute 192.168.0.0 255.255.255.0

эти файлы срабатывают когда клиент подключается
первая строка добавляет маршрутизацию на клиенте, вторая на самом сервере.

На складе есть правило
404 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
которое позволяет пинговать подсеть склада из офиса.
В офисе такого правила нет...

С виртуальными интерфейсами iptables работает также, как и с физическими.

Кроме того надо решить, какой транспорт использует VPN- tcp или udp
ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:33333
82 11325 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:33333

Следущее- на складе порт открывать не нужно
$IPT -A INPUT -i $WAN -p udp --dport 33333 -j ACCEPT
поскольку склад коннектится к офису, а не наоборот.

Смущает правило в цепочке FORWARD
ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED

типа летите пакетики откуда угодно и куда угодно.

Правила IPTABLES нужно выполнять от рута. SUDO не нужно.

На складе есть правило
404 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
которое позволяет пинговать подсеть склада из офиса.
В офисе такого правила нет...

ага увидел. что нужно добавить ?

С виртуальными интерфейсами iptables работает также, как и с физическими.
Кроме того надо решить,  какой транспорт использует VPN- tcp или udp
 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:33333
   82 11325 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:33333

это исправил. оставил только протокол udp

Следущее- на складе порт открывать не нужно
$IPT -A INPUT -i $WAN -p udp --dport 33333 -j ACCEPT
поскольку склад коннектится к офису, а не наоборот.

тоже исправил.

Смущает правило в цепочке FORWARD
ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED

типа летите пакетики откуда угодно и куда угодно.

Правила IPTABLES нужно выполнять от рута. SUDO не нужно.

Млин, уже не один год юзаю OpenVpn и еще раз повторяю:

Если тунель поднят и сервер с клиентом видят друг друга, но сети которые стоят за ними не видят друг друга, то здесь дело исключительно в маршрутизации!!!

1. на каждом компе локальной сети, что за сервером, что за клиентом необходимо прописать правило маршрутизации до соседней сети. Исключение составляет вариант когда клиент или сервер уже являются шлюзами.

2. На клиенте и на сервере необходимо прописать свои правила маршрутизации, сколько у вас сетей столько и правил. Причем есть ньюанс! если клиент отсоединяется от сервера, то правило автоматически без вашего участия убирается из таблицы маршрутизации, т.к. отсутствует интерфейс на которое это правило завязано. Сл-но когда интерфейс tun снова подымается нужно это правило заново добавить!! Вот именно за это и отвечают те файлы о которых я писал выше, повторяться не буду

3. ну естественно нужно включать форвардинг пакетов между интерфейсами и на сервере, и на клиенте.

Вот и все премудрости, хотя может я чего не догоняю?

andresyto написал:

ага увидел. что нужно добавить ?

iptables -A INPUT -p all -i tun0 -j ACCEPT

Спасибо Ограненное за помощь!
Ситуация изменилась сейчас шеф просит чтобы кроме цеха можно подключить еще несколько пользователей.
Учитывая Рекомендации и Наставления на путь истинный на гуглил другой конфиг для VPN туннеля.
переделал по этой инструкции

Данные центральный офис

вот конфиг сервера

route -n

iptables -L

iptables -L -v -n

iptables -L -v -n -t nat

Данные с Сервера Цех

конфиг клиента

route -n

iptables -L

iptables -L -v -n

iptables -L -v -n -t nat

Данные с ПК клиента цеха
ipconfig /all

route print

ping 192.168.0.1 # сервер центрального офиса

ping 192.168.0.2 # ip адрес Пк в центральном офесе

как я понимаю на клиентских виндовых тачках надо добавить постоянный маршрут к сети офиса
из за разницы во времени буду пока гулить инет как самому добавить правило маршрутизации

Забыл указать клиентские /etc/openvpn/ccd
filial1
ifconfig-push 10.10.100.2 10.10.100.1
iroute 192.168.1.0 255.255.255.0

andresyto написал:

Забыл указать клиентские /etc/openvpn/ccd
filial1
ifconfig-push 10.10.100.2 10.10.100.1
iroute 192.168.1.0 255.255.255.0

Проблема в том, что в конфиге сервера вы указываете:

andresyto написал:

# Офис
push "route 192.168.0.0 255.255.255.0"
# Филиал №1
push "route 192.168.1.0 255.255.255.0"
# Филиал №2
push "route 192.168.2.0 255.255.255.0"
# Филиал №3
push "route 192.168.3.0 255.255.255.0"

но эти правила срабатывают 1 раз когда сервер идеализируется и совсем не факт, что в этот момент все ваши клиенты подсоеденены к нему!!! Сл-но эти команды правил маршрутизации на клиентах выполнены не будут!!!
Правильный подход (именно у меня так сделано) добавить эти команды для каждого клиента в свой отдельный файлик в папку /etc/openvpn/ccd
(в моем самом первом посте реальный пример одного из таких файлов)

ИМХО: и еще:

andresyto написал:

# Филиал №3
push "route 192.168.3.0 255.255.255.0"

т.е. этим правилом вы говорите клиенту, чтобы в момент соединения с сервером он выполнил у себя на хосте команду: "route 192.168.3.0 255.255.255.0 dev tun" , другими словами все пакеты которые адресованы и пришли к нему, пусть обратно отправляет их в tun????? Проще всего написать типа push "route 192.168.0.0 255.255.0.0" , а т.к. на клиенте маршрут: 192.168.3.0 255.255.255.0 dev eth0 установится автоматически при поднятия его собственного сетевого интерфейса, и т.к. маска этого маршрута точнее(255.255.255.0), нежели маршрута который передает ему VPN (255.255.0.0), поэтому этот маршрут и будет срабатывать для сети этого клиента!!!

vladlen_msk написал:

На стороне openVPN сервера в папке ccd есть файлики c именами ваших клиентов содержимой файлов примерно такое:
push "route 192.168.1.0 255.255.255.0"
iroute 192.168.0.0 255.255.255.0

эти файлы срабатывают когда клиент подключается
первая строка добавляет маршрутизацию на клиенте, вторая на самом сервере.

попробовал я подставил как ты указал тут
все равно не работает
пробовал в следующих комбинациях
Вариант №1

не помогло

Вариант №2

Тоже не помогло
Вариант №3

аналогично
Вариант №4

тоже самое
Вариант №3

Файлы как называются?, имя должно строго соответствовать имени клиента: для цеха это будет: "client"

и для цеха содержимое файла на сервере VPN: /etc/openvpn/ccd/client:

push "route 192.168.0.0 255.255.0.0"
iroute 192.168.1.0 255.255.255.0

где-то примерно так, если в цехе локалка: 192.168.1.0 255.255.255.0

P.S. и не забывайте делать /etc/init.d/openvpn restart на сервере после каждого обновления конфигов

vladlen_msk написал:

Файлы как называются?, имя должно строго соответствовать имени клиента: для цеха это будет: "client"

и для цеха содержимое файла на сервере VPN: /etc/openvpn/ccd/client:

push "route 192.168.0.0 255.255.0.0"
iroute 192.168.1.0 255.255.255.0

где-то примерно так, если в цехе локалка: 192.168.1.0 255.255.255.0

совпадают

делал тоже

/etc/openvpn/ccd# ls
filial1 filial2 filial3 sysadmin


keys# ls
01.pem 04.pem ca.crt filial1.crt filial1.p12 filial2.key filial3.csr index.txt index.txt.old server.crt sysadmin.crt sysadmin.p12
02.pem 05.pem ca.key filial1.csr filial2.crt filial2.p12 filial3.key index.txt.attr serial server.csr sysadmin.csr ta.key
03.pem 06.pem dh2048.pem filial1.key filial2.csr filial3.crt filial3.p12 index.txt.attr.old serial.old server.key sysadmin.key

Странно, премудростей то здесь практически нет, у меня 4 сети объединены посредством OpenVpn и все уже не первый год как часики работает. вот мои рабочие конфиги сервер:

# Использовать tun-интерфейсы вместо tap
dev tun
# Используемый транспортный протокол
proto udp
# Порт клиента и сервера
port 3784
# Локальный IP и IP дальней стороны туннеля
#ifconfig 192.168.111.1 192.168.111.2
tls-server
server 10.10.0.0 255.255.255.0
# Сжимаем пакеты с помощью lzo, используя адаптирующийся алгоритм.
comp-lzo
client-to-client
client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ccd/ipp.txt
dh /etc/openvpn/dh1024.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
persist-tun
persist-key
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
# проверяем работу туннеля каждые 10 секунд и перезапускаем в случае обрыва через 120
keepalive 10 120
# Не проверять таймауты, если клиент не подключен
ping-timer-rem
# не выключаем интерфейс при перезапуске соединения
persist-tun
# Очень полезная опция - не перечитывать ключ при рестарте соединения.
# Дело в том что OpenVPN может снижать привелегии (см ниже) при запуске после 
# чтения конфигурационного файла и ключа в целях безопасности. 
persist-key
# Пользователь, под которым работает демон после запуска
user nobody
group nobody 
# Собственно, становиться ли демоном
daemon
# добавляется в маршрутизацию текущего сервера (ОБЯЗАТЕЛЬНО!!)
route 192.168.0.0 255.255.0.0 
# Куда пишем журнал. 
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log
verb 4

и клиента:

dev tun
proto udp
remote  my_domain 3784
route-delay 3
client
tls-client
ns-cert-type server
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ping-restart 60
ping 10
status /home/vlad/openvpn-status.log
status /home/vlad/openvpn.log
verb 3

Ну а файлы ccd я выкладывал выше.

и iptables до кучи:

# Разрешаем прохождение любого трафика по интерфейсу обратной петли.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
# Принимать все пакеты, которые инициированы из уже установленного соединения, и имеющим признак ESTABLISHED.
# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
-A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Отбрасывать все пакеты, которые не могут быть идентифицированы и поэтому не могут иметь определенного статуса.
#-A INPUT   -m state --state INVALID -j DROP
#-A FORWARD -m state --state INVALID -j DROP
-A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 5678 -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 5679 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
#-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
# OpenVpn
-A INPUT -i eth0 -p udp --dport 3784 -j ACCEPT
#-A INPUT -i eth0 -p tcp --dport 1521 -j ACCEPT
# ssh
-A INPUT -i eth0 -j DROP
COMMIT

Причем 3 правило я сразу после перезагрузки сервера ручками отменяю: iptables -D INPUT 3
Это правило для подстраховки:
если с сервером проблема и OpenVpn не поднимается ( ни разу такого не было, но на всяк случай) я сервер через удаленную консоль просто перегружаю и получаю ssh на 22 порту, все остальное время SSH только через openVpn

может ты подкосившийся ко мне № и пас я тебе отправил

Привет всем проблема пока осталось

Гуру Подскажите как увидеть Windows машины по локалке из Цеха -> машины Windows центрального офиса ?

Пример настроек клиентов- которые в папке /etc/openvpn/ccd

# присваиваем ip-адрес клиенту
ifconfig-push 192.168.10.102 255.255.255.0

# роутинг на сети центрального офиса
push "route 192.168.1.0 255.255.255.0 192.168.10.1"
push "route 192.168.2.0 255.255.255.0 192.168.10.1"

Тут описываем подсети, которые должен получить клиент при подключении.
Как видим, мы сообщаем, что маршрут до сети такой то, с маской такой то, через шлюз такой то.
Шлюз в данном случае- ip интерфейса tun0 у сервера VPN.