ky0, если я со второго шлюза обращаюсь по внешнему IP - адрес недоступен. Как я предполагаю, потому что пакет приходит с одного интерфейса (внешнего), а отправляется по второму, через туннель. Как заставить туннель использовать определённый интерфейс?
Здесь этот вопрос обсуждался, но я так и зашёл в тупик с настройками. Собственно вы мне и советовали. Но я пробовал способы описанные в статье по ссылке, в результате только хуже стало, и эксперименты пришлось свернуть - удалённый сервер на одном из этапов вообще стал недоступен, пришлось скидывать всё до дефолтных настроек.
UPD. Причём очень желательно отделить так траффик на обоих шлюзах - так чтобы телефония и туннель использовали один канал, а интернет - другой. Сложность ещё в том, что сервер телефонии использует и обычный входящий траффик (не через туннель), от sip-провайдера.
iddqda, а можно более подробно? Я уже пробовал заворачивать туннель (телефония работает через него) на нужный интерфейс, но столкнулся с проблемой ассиметричности. Как заставить туннель использовать определённый интерфейс?
В ссылке которую дали воды столько, что уже непонятно, где рабочие советы, а где из разряда "ну попробуй, может так прокатит".
Ведь есть же наверняка рабочая схема, как отделить один траффик от другого, так чтобы телефония не глючила
iddqda, сервисы в сети сервисов... вы меня путаете.
Есть шлюз. Внутри сети есть сервер телефонии. Мне нужно чтобы обычный трафик из сети шёл по одному каналу, а трафик телефонии - по другому, дабы не было провисаний связи. Можете подсказать, как это сделать? И да, серевер телефонии использует ещё и туннель, через оный к телефонии подключается офис в другом городе.
Набрал в браузере toster.ru. Я всё правильно сделал?
Это маршрут по умолчанию, у меня ещё есть туннель, и по хорошему некоторые сервисы нужно пускать по другому каналу. Например ту же телефонию отделить от основного канала.
res2001, у старого и у нового шлюза адреса остались те же самые - 192.168.0.1 у серверного и 192.168.1.1 у клиентского. Шлюз и VPN сервер это одна и та же машина. Так же как VPN клиент является ещё и шлюзом в своей сети. Так как у нового шлюза ip адрес внутри своей сети такой же как у старого, менять у машин шлюз по умолчанию не требуется.
По сути сейчас вся загвоздка в том, что почему-то из сети клиента недоступна сеть сервера. Сам шлюз/сервер (192.168.0.1) доступен, а сеть за ним - нет, несмотря на вышеприведённые настройки iptables и вроде бы правильные маршруты.
res2001, а что, нужно на каждом компе сети прописывать маршрут? Но в старой конфигурации такого не было. Были указаны шлюзы по умолчанию и всё.
192.168.0.127 - это комп в сети сервера. Я его и пинговал с клиента. Результат выше.
Пинг изнутри сети клиента компьютера внутри сети сервера:
spoiler
20:26:11.696101 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 19, length 40
20:26:16.688104 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 20, length40
20:26:21.695406 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 21, length 40
res2001, так открыто всё на tun0, настройки iptables тоже приложил выше. Ошибок судя по всему в логах нет, но на всяки случай скину тоже их.
лог сервера:
res2001, причесал настройки OpenVPN. Маршруты есть, судя по выхлопу ip route
Сервер:
spoiler
ip route
default via 94.181.xxx.xxx dev eth2 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
94.181.xxx.x/24 dev eth2 proto kernel scope link src 94.181.xxx.xx
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0
клиент:
spoiler
default via 94.180.zzz.zzz dev eth0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
94.0.0.0/8 via 94.180.zzz.zzz dev eth0
94.180.zzz.z/24 dev eth0 proto kernel scope link src 94.180.zzz.zzz
94.180.250.0/24 dev eth2 proto kernel scope link src 94.180.250.147
192.168.0.0/24 via 10.8.0.9 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
iptables на сервере:
spoiler
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT
И всё равно не работает - с клиента пингуется только сервер, сеть за сервером не пингуется. С сервера не пингуется даже клиент.
Да это я уже экспериментировал с настройками. Изначально так и было - на сервере route 192.168.1.0 255.255.255.0, в ccd указано iroute 192.168.1.0 255.255.255.0.
Изначально конфиг переносился с уже работающего сервера, на клиенте только заменили ip адрес по которому он обращается к серверу, и всё. Но всё равно не работало. Точнее, работало, но только в одну сторону - со стороны сети сервера сеть клиента пинговалась, со стороны клиента пинговался только сервер. Все настройки iptables тоже были перенесены со старого шлюза, с заменой адресов на пробросах. Вот разве что у нового и старого сервера не совпадают сетевые интерфейсы. Сегодня вечером попробую переподключить их так же как на старом
res2001, да, шлюз, он же сервер OpenVPN. Клиент OpenVPN остаётся на старом месте, там ничего не меняется. Внутри сети IP адрес тот же, да (192.168.0.1). Поменялся собственно только сетевой интерфейс локальной сети (и в настройках был изменён), и внешний IP-адрес. Хотя возможно было правильнее подключить сети к тем же интерфейсам что и на старом...
res2001, да, клиент видит и пингует сервер (192.168.0.1), но дальше не видит. А сервер не пингует клиента. Логи щас уже приложить не могу, днём приходится переключать всё на старый шлюз, чтобы хоть как-то работало.
С маршрутизацией и прошу подсказать - вроде маршруты такие же как на старом шлюзе, но не работает.
local 94.181.xx.xx
port 649xx
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0 10.8.0.2"
client-config-dir xxx
route 192.168.1.0 255.255.255.0 10.8.0.1
tls-auth ta.key 0
auth SHA512
tls-version-min 1.2
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
log /var/log/openvpn.log
Клиент
spoiler
client
dev tun
proto udp
remote 94.181.xx.xx 649xx
route 192.168.0.0 255.255.255.0
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert kaxxx.crt
key kaxxx.key
ns-cert-type server
tls-auth ta.key 1
auth SHA512
cipher AES-128-CBC
comp-lzo
verb 3
log /var/log/openvpn.log
Ответ ip ro li
сервера:
spoiler
default via 94.181.xxx.xxx dev eth0 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
94.0.0.0/8 via 94.181.180.254 dev eth0
94.181.xxx.0/24 dev eth0 proto kernel scope link src 94.181.xxx.xx
94.181.xxx.0/24 dev eth1 proto kernel scope link src 94.181.xxx.xxx
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0
клиента:
spoiler
default via 94.180.zzz.zzz dev eth0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
94.0.0.0/8 via 94.180.249.254 dev eth0
94.180.zzz.0/24 dev eth0 proto kernel scope link src 94.180.zzz.zzz
94.180.zzz.0/24 dev eth2 proto kernel scope link src 94.180.zzz.zzz
192.168.0.0/24 via 10.8.0.9 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
Собственно все настройки перенесены с другого сервера, к котором раньше подключался клиент. Но понадобилось перенести всё это на другую машину, с другими наружными IP-адресами. При переключении на старый шлюз всё работает. На новом, с аналогичными настройками (само собой заменены сетевые интерфейсы и IP-адреса в настройках) - не работает. Вывод ip ro li у старого шлюза тоже не отличается.
ky0, Нет, недоступен по адресу на eth1. Если маршрут убрать, снова становится доступен. Думаю дело в том, что я в маршруте прописываю адрес сервера, с которого потом и обращаюсь. Но что делать в этой ситуации, не соображу никак.
Как заставить туннель использовать определённый интерфейс?
Здесь этот вопрос обсуждался, но я так и зашёл в тупик с настройками. Собственно вы мне и советовали. Но я пробовал способы описанные в статье по ссылке, в результате только хуже стало, и эксперименты пришлось свернуть - удалённый сервер на одном из этапов вообще стал недоступен, пришлось скидывать всё до дефолтных настроек.
UPD. Причём очень желательно отделить так траффик на обоих шлюзах - так чтобы телефония и туннель использовали один канал, а интернет - другой. Сложность ещё в том, что сервер телефонии использует и обычный входящий траффик (не через туннель), от sip-провайдера.