LINUX.ORG.RU
ФорумAdmin

Как объеденить два филиала в локальную сеть по внешним ip с каналов в 20мбит? Прошу помощи!


0

0

Доброго времени суток всем!

Прошу пролить свет на сложившуюся задачу:

Необходимо связать два филиала в одну локальную сеть. У обоих филиалов есть интернет, у филиала1 интернет по ADSL, у филиала2 WiMax. Третий провайдер выделил нам два внешних ip, гарантируя скорость в 20 мбит/с между этими двумя ip. Нужно настроить сеть таким образом, чтобы компьютеры из локальной сети филиала1 обменивались данными с комьютерами из локальной сети филиала2 по 20-ти мегабитному каналу используя внешние ip, не используя при этом интернет-каналы, т.к они достаточно медленные (1 мегабит в филиале1 и 0,5 мегабита в филиале2) В свое время, нужно чтобы каждый филиал пользовался своим интернетом.

Имеется два сервера для создания туннеля. Получается, что нужно по три сетевые карты в каждый сервер, чтобы nic1 использовался для 20 мегабитного канала для объеденения локальных сетей (openVPN туннелем, вероятно), nic2 для интернета и nic3 для локальной сети. Такаой же конфиг на сервере второго филиала.

Принимаются предложения по использованию методов осуществления данной задачи, включая выбор дистрибутива Linux и соответствущего ПО.

1-я сторона

interface Tunnel0

ip address 192.168.1.1 255.255.255.252

tunnel source GigabitEthernet0/1

tunnel destination адрес_другой_стороны

ip route 192.168.15.0 255.255.255.0 192.168.1.2

2-я сторона interface Tunnel0

ip address 192.168.1.2 255.255.255.252

tunnel source GigabitEthernet0/1

tunnel destination адрес_первой_стороны

ip route 192.168.8.0 255.255.255.0 192.168.1.1

Самый простой способ для объеденения двух подсетей. Если Вам необходимо "прозрачно" пробросить сети, следует смотреть на L2 тунели. Дефолты, естественно, смотрять на каждом офисе в сторону инета.

Это вариант на цисках, спроецировать их на Linux, xBSD не составит труда.

vladislav ★★
()
Ответ на: комментарий от vladislav

Спасибо за ответ, попробую это реализовать в Linux

superscope
() автор топика
Ответ на: комментарий от no-dashi

Набрал man openvpn в терминале и ужаснулся) Неужели оттуда выходят живыми?)

Мне бы ссылочку на пример, который бы мне подходил, просто это желательно завтра сделать, а потом уже плотно курить ман и понимать что к чему...

superscope
() автор топика

На шлюзе первого филиала:
ip route add $IP2/32 via $IP1
На шлюзе второго филиала:
ip route add $IP1/32 via $IP2
где $IP{1,2} — внешние айпишники первого и второго филиалов соответственно.

И в чем, собсно, проблема?

nnz ★★★★
()
Ответ на: комментарий от superscope

CLIENT

dev-type tap
dev vpn
route-nopull
remote yourserver.com

ping 10
ping-restart 60

client
tls-client
remote-cert-tls server
ca /etc/openvpn/vpn/ca.crt
cert /etc/openvpn/vpn/my.crt
key /etc/openvpn/vpn/my.key


SERVER

dev vpn
dev-type tap
proto udp
client-to-client
server 172.1.1.0 255.255.255.0
user nobody
group nogroup
persist-key
persist-tun
keepalive 30 180
client-config-dir /etc/openvpn/vpn/ccd
#ccd-exclusive

#SSL STUFF
dh /etc/openvpn/dh2048.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/vpn/vpnserver.crt
key /etc/openvpn/vpn/vpnserver.key

true_admin ★★★★★
()
Ответ на: комментарий от superscope

> Мне бы ссылочку на пример, который бы мне подходил root# openvpn --genkey --secret xxx.key

На одном сервере (server1):

root@server1# openvpn --remote server2.domain.com --port 5234 --rport 5234 --proto udp --secret xxx.key --dev tun --ifconfig 192.168.0.1 192.168.0.2

На втором сервере (server2):

root@server2# openvpn --remote server1.domain.com --port 5234 --rport 5234 --proto udp --secret xxx.key --dev tun --ifconfig 192.168.0.2 192.168.0.1

Да, ключ (xxx.key) надо сгенерировать один раз и разместить на обоих компах. Обрати внимание - IP-адреса поменялись местами на разных серверах. Потом осиль опцию route, и все начнет работь. Того выше, который писал про сертификаты, не слушай - оно для других целей и значительно заметно в настройках и понимании.

И да - прочти снова man. Теперь станет понятней.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Кстати, а openvpn имеет штатные средства для передачи своего (уже инкапсулированного) трафика через недефолтный шлюз?

Или топкистартеру обязательно надо делать так, как я писал выше в этом треде?

nnz ★★★★
()
Ответ на: комментарий от nnz

> Кстати, а openvpn имеет штатные средства для передачи своего (уже инкапсулированного) трафика через недефолтный шлюз?

О, всплыл "дефолтный шлюз". Давно из винды? Есть таблица (таблицы) маршрутизации, в них можно все. Все остальное - лишние сущности. Как в таблице маршрутизации будет записан маршрут до remote, так оно и пойдет.

no-dashi ★★★★★
()
Ответ на: комментарий от nnz

> Или топкистартеру обязательно надо делать так, как я писал выше в этом треде?

У топикстартера 100% приватные адреса внутри локалок, и поэтому какой-либо "голый" route для него неприемлем. Типичная конфигурация с правильно работающим OpenVPN "изнутри" видится примерно так:

Сервер 1:
eth0 (локалка) - 192.168.0.1/24
iface0 (интернет) - 75.1.2.1/30
tun0 (OpenVPN) - 192.168.255.1/32
Таблица маршрутизации:
0.0.0.0/0 via 75.1.2.2 dev iface0
192.168.1.0/24 dev tun0

Сервер 2:
eth0 (локалка) - 192.168.1.1/24
iface0 (интернет) - 85.1.2.1/30
tun0 (OpenVPN) - 192.168.255.2/32
Таблица маршрутизации:
0.0.0.0/0 via 85.1.2.2 dev iface0
192.168.0.0/24 dev tun0

Соответственно, все пакеты из одной локалки в другую сразу заварачиваются на OpenVPN через TUN. Этот процесс не нуждается ни в каких скриптах, и активируется сразу опцией route при запуске OpenVPN:
--route 192.168.1.0 255.255.255.0 на первом сервере
--route 192.168.01.0 255.255.255.0 на втором сервере

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Блин, забыл - на tun-итерфейсах как правило ставится маска /30, а я по очепятке написал /32

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>О, всплыл "дефолтный шлюз". Давно из винды? Есть таблица (таблицы) маршрутизации, в них можно все.

Неужели так трудно ответить на поставленный вопрос?
Я спрашивал про возможности openvpn. А вы в ответ начали лить воду. Не знаете — так и скажите.

И таки да, про /etc/iproute2/rt_tables я в курсе :)

nnz ★★★★
()
Ответ на: комментарий от no-dashi

>У топикстартера 100% приватные адреса внутри локалок, и поэтому какой-либо "голый" route для него неприемлем.

Для тех, кто медленно соображает: я вообще-то писал о том, как пустить трафик впна через выделенный канал. Предложенные команды нужно вводить на шлюзах, которые и должны, по идее, держать openvpn-клиент/сервер (или пиров).

nnz ★★★★
()
Ответ на: комментарий от no-dashi

Как в таблице маршрутизации будет записан маршрут до remote, так оно и пойдет.

Именно это я и написал выше.

А мой вопрос к вам состоял в следующем: есть ли в openvpn встроенный механизм для таких операций? Для инкапсулируемого трафика он, например, прописывает маршруты сам, на основании конфигов.

nnz ★★★★
()
Ответ на: комментарий от nnz

> Для инкапсулируемого трафика он, например, прописывает маршруты сам, на основании конфигов.

man openvpn на предмет --up ???

no-dashi ★★★★★
()
Ответ на: комментарий от chocholl

> gre используйте, openvpn - костыль.

А чт, "некостыль" уже научился работать по TCP, через HTTP/SSH--туннели, в клиент-серверном режиме, с авторизацией по сертификатам, автоматической раздаче IP-адресов, нормальной криптографии и единообразной на всех платформах конфигурации? :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

применительно к вопросу все эти фичи абсолютно непотребны.

chocholl ★★
()
Ответ на: комментарий от no-dashi

>man openvpn на предмет --up ???

Е-мае! Я же про _инкапсулированный_ трафик спрашивал! Т.е. тот трафик, по которому openvpn передает данные наружу. Маршруты для такого трафика надо прописывать _до_ поднятия туннеля.
А про тот трафик, который идет по туннелю (инкапсулируемый), я и так знаю, спасибо. (Если бы не знал — вряд ли смог бы объединить через openvpn несколько локалок.)

nnz ★★★★
()
Ответ на: комментарий от no-dashi

>А чт, "некостыль" уже научился работать по TCP,...
>в клиент-серверном режиме, с авторизацией по сертификатам,

>автоматической раздаче IP-адресов, нормальной криптографии...


Странно слышать такое от человека, который несколькими постами выше предложил конфигурацию p2p через UDP с симметричным шифрованием и ручной конфигурацией интерфейсов ;)

nnz ★★★★
()
Ответ на: комментарий от no-dashi

На всякий случай объясняю идею на пальцах.
Есть два сервера, связанные быстрым каналом. Также у каждого из них есть доступ к сравнительно медленному интернету. Вполне естественно предположить, что «медленные» провайдеры будут дефолтными шлюзами в таблицах main обоих серверов (чтобы выпустить свои локалки в инет).

Однако возникает задача связать обе локалки через некий туннель (опенвпн, гре, айписец...). Разумеется, туннель целесообразно устанавливать по «быстрому» каналу. Для этого, соответственно, нужно прописать специальные роуты, как я уже говорил выше.

А вопрос мой был всего лишь в том, умеет ли опенвпн автоматически прописывать такие роуты? Не для внутреннего трафика, а для внешнего?

nnz ★★★★
()
Ответ на: комментарий от nnz

Всем спасибо за ответы!

Ситуация несколько изменилась - интернет на оба флиала будет один, который будет подключен в первом филиале. Второй филиал будет ходить в инет через первый филиал.

Да, и еще - целесообразно ли использовать ipcop для этих целей? Если да, то как его правильно настроить?

superscope
() автор топика
Ответ на: комментарий от superscope

>Ситуация несколько изменилась - интернет на оба флиала будет один, который будет подключен в первом филиале. Второй филиал будет ходить в инет через первый филиал.

Сути задачи это не меняет. Разве что во втором филиале openvpn надо будет запускать с redirect-gateway, ну и в фаерволе на первом филиале слегка поковыряться, чтобы он транзитный трафик пропускал (iptables -A FORWARD -m state ESTABLISHED,RELATED -j ACCEPT; iptables -A FORWARD -i tun0 -j ACCEPT; sysctl net.ipv4.ip_forward=1).

Насчет IPCop — емнип, он сдох год назад. Для шлюза важна секурность, а для секурности важны в т.ч. и регулярные обновления безопасности.
Лично я рекомендую debian — из всех известных мне дистров там лучше всего собран фаервол.

nnz ★★★★
()
Ответ на: комментарий от nnz

> Странно слышать такое от человека, который несколькими постами выше предложил конфигурацию p2p через UDP с симметричным шифрованием и ручной конфигурацией интерфейсов

При наличии двух инструментов позволяющих решить задачу с примерно одинаковыми трудозатратами, имеет смысл выбирать тот инструмент, который более гибок. Даже если его возможности сейчас не востребованы, они почти наверняка понадобятся завтра (проверено многолетним опытом)

no-dashi ★★★★★
()
Ответ на: комментарий от nnz

> А вопрос мой был всего лишь в том, умеет ли опенвпн автоматически прописывать такие роуты? Не для внутреннего трафика, а для внешнего?

Я тебе по русски сказал - опция --up в конфиге. Сделай там все что надо. При работе в режиме p2p по UDP (а этот режим как раз и сравним c GRE) у openvpn нет понятия "соединение", так что сразу после запуска активируется TUN-интерфейс, после чего выполняется указанный в конфиге скрипт. В котором можешь написать какие угодно маршруты.

Правда нормальные люди, если знают что какой-то target быстрей достигается по другому маршруту, вписывают его в system-wide конфиг - в основном для того, чтобы не заниматься сексом индивидуально с каждым продуктом для организации туннеля.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>При наличии двух инструментов позволяющих решить задачу с примерно одинаковыми трудозатратами, имеет смысл выбирать тот инструмент, который более гибок. Даже если его возможности сейчас не востребованы, они почти наверняка понадобятся завтра (проверено многолетним опытом)

Вот поэтому я когда-то и поднял опенвпнку, связывающую один сервак с новой (тогда) работы с моим домашним серваком — сразу на TCP, с сертификатами, в режиме клиент-сервера и т.п.
Сейчас эта впнка разрослась до нехилых размеров, объединяет несколько локалок. Некоторые клиенты коннектятся через прокси, поэтому TCP незаменим. Впрочем, подумываю о создании отдельной сетки на UDP.

> Странно слышать такое от человека, который несколькими постами выше предложил конфигурацию p2p через UDP с симметричным шифрованием и ручной конфигурацией интерфейсов

А вообще это шутка была :)

nnz ★★★★
()
Ответ на: комментарий от no-dashi

>При работе в режиме p2p по UDP
Ну, лично меня в первую очередь интересует клиент-сервер по TCP :)

Вообще, как я понял из документации, --up исполняется уже после создания туннеля. Он нормально перенесет смену маршрута на лету? Даже с включенным rp_filter?

nnz ★★★★
()
Ответ на: комментарий от nnz

> Странно слышать такое от человека, который несколькими постами выше предложил конфигурацию p2p через UDP с симметричным шифрованием и ручной конфигурацией интерфейсов ;)

Да, пример из реальной жизни: необходимо было связать два офиса, выбор был GRE или OpenVPN. Выбрали OpenVPN. Через год вдруг выяснилось, что надо дать возможность подключаться по VPN с точек, где единственная связь это GPRS. Клиенты которого естественно выпускаются через NAT. В случае с OpenVPN мы просто добавили еще один конфиг и сгенерировали пачку сертификатов. В случае с GRE мы бы начали поднимать OpenVPN.

Ну и как я уже говорил, это практически единственное гибкое, кроссплатформенное, бесплатное и работающее даже в самых тяжелых условиях решение.

no-dashi ★★★★★
()
Ответ на: комментарий от nnz

> Ну, лично меня в первую очередь интересует клиент-сервер по TCP :)

TCP-шный режим обладает немаленькой такой латентностью и оверхедом. Если удаленные объекты "статичны", то рекомендуют использовать UDP.

> Вообще, как я понял из документации, --up исполняется уже после создания туннеля. Он нормально перенесет смену маршрута на лету?

Да, даже в TCP-шном режиме. Разве что не следует забывать про опцию --local чтобы указать на какой интерфейс надо биндиться.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Ну, насчет кроссплатформенности мне не так давно один товарищ доказывал, что в этом смысле рулит PPTP. Товарищ связывал виндовых клиентов (нативная реализация) через фряшный сервер (mpd5).

А вообще опенвпн под виндой создает определенное впечатление костыльности. Начиная от дров для виртуального интерфейса, которые помечены как «экспериментальные» и заканчивая постоянно висящим черным окошком :)

nnz ★★★★
()
Ответ на: комментарий от no-dashi

>TCP-шный режим обладает немаленькой такой латентностью и оверхедом. Если удаленные объекты "статичны", то рекомендуют использовать UDP.
Да знаю я. Но жить через прокси захочешь — не так раскорячишься.

>Да, даже в TCP-шном режиме.

Спасибо, буду иметь в виду.

nnz ★★★★
()
Ответ на: комментарий от nnz

> А вообще опенвпн под виндой создает определенное впечатление костыльности. Начиная от дров для виртуального интерфейса, которые помечены как «экспериментальные» и заканчивая постоянно висящим черным окошком :)

Да пожалуйста, никто не держит - используйте сертифицированные быдлопродукты типа VIPNet(c)Инфотекс, Kerio(tm)VPN, "ФПСУ-IP клиент" и им подобное УГ. Только потом жаловаться не приходите. Я скорей уж потерплю черное окошко или работу openvpn через srvany :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>Да пожалуйста, никто не держит - используйте сертифицированные быдлопродукты типа VIPNet(c)Инфотекс, Kerio(tm)VPN, "ФПСУ-IP клиент" и им подобное УГ.

Дык PPTP же нативный!
А насчет того, что несекурный — какая вообще секурность в винде?

nnz ★★★★
()
Ответ на: комментарий от nnz

> А насчет того, что несекурный — какая вообще секурность в винде?

Мало ты общался с муд^W деб^W идио^W быдл^W ИТ-бюрокр^W^W безопасниками :-) Для них "защищенной" является система с бумажкой, а система без бумажки - незащищеной. Так что Win98 с "Аккордом" будет защищеная, а Linux с SELinux в режиме enforced, файрволом, noexec и прочим будет "незащищеным" :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>Мало ты общался с муд^W деб^W идио^W быдл^W ИТ-бюрокр^W^W безопасниками :-)

Я, оказывается, очень счастливый человек :)

nnz ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.