LINUX.ORG.RU
решено Форум — Admin  

Два устройства в разных сетях

 , , ,


0

1

Постараюсь объяснить понятно. Есть филиал (192.168.46.0/24) и сеть офиса (10.10.3.0/24, есть еще другие сети, но не суть важно). В офисе стоит сервер OpenVPN. VPN сеть 10.11.12.0/24. В филиале Synology (192.168.46.6) с поднятым клиентом. Synology не является роутером по-умолчанию для внутренних устройств, эту функцию выполняет D-Link (192.168.46.1), он же дает интернет филиалу. На нем же роут, что сеть 10.11.12.0/24 доступна на хосте 192.168.46.6. Пытался указать еще свою сеть (10.10.3.0/24), но разницы никакой.

Клиент подключается к серверу. С этого момента из офиса я могу пинговать все, что захочу в филиале. НО. Как только я пытаюсь зайти на дивайс 192.168.46.7 или 26 (это IP камера и принтер, соответственно) браузер сообщает об недоступности хоста. На Synology снял дамп проходящих пакетов:

0.000000   10.11.12.1 -> 192.168.46.7 TCP 60 56963 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=19998324 TSecr=0 WS=128
  0.000855   10.11.12.1 -> 192.168.46.7 TCP 60 56964 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=19998324 TSecr=0 WS=128
  0.001052 192.168.46.7 -> 10.11.12.1   TCP 60 http > 56963 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=725699697 TSecr=19998324 WS=2
  0.001720 192.168.46.7 -> 10.11.12.1   TCP 60 http > 56964 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=725699697 TSecr=19998324 WS=2
  0.008310   10.11.12.1 -> 192.168.46.7 TCP 52 56963 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=19998326 TSecr=725699697
  0.008531   10.11.12.1 -> 192.168.46.7 TCP 52 56964 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=19998326 TSecr=725699697
  0.008872   10.11.12.1 -> 192.168.46.7 HTTP 421 GET / HTTP/1.1 
  0.009892 192.168.46.1 -> 10.11.12.1   TCP 52 http > 56963 [ACK] Seq=1 Ack=1 Win=3432 Len=0 TSval=725699698 TSecr=19998326
  0.013386 192.168.46.1 -> 10.11.12.1   TCP 411 [TCP segment of a reassembled PDU]
  0.013651 192.168.46.1 -> 10.11.12.1   HTTP 52 HTTP/1.0 401 Unauthorized  (text/html)
  0.015833   10.11.12.1 -> 192.168.46.1 TCP 40 56963 > http [RST] Seq=1 Win=0 Len=0
  0.022099   10.11.12.1 -> 192.168.46.1 TCP 40 56963 > http [RST] Seq=1 Win=0 Len=0
  0.022306   10.11.12.1 -> 192.168.46.1 TCP 40 56963 > http [RST] Seq=1 Win=0 Len=0
  0.213779   10.11.12.1 -> 192.168.46.7 HTTP 421 [TCP Retransmission] GET / HTTP/1.1 
  0.214614 192.168.46.7 -> 10.11.12.1   TCP 40 http > 56963 [RST] Seq=1 Win=0 Len=0

10.11.12.1 - VPN сервер за которым сижу я.

Как видно, после успешного соединения с удаленным хостом, каким-то боком я начинаю общаться с 192.168.46.1. Естественно я сбрасываю соединение с этим хостом и заново пытаюсь получить данные с 192.168.46.7. Но удаленный хост уже меня сбрасывает. Надо отметить, что до этого вместо 192.168.46.1 был 10.11.12.10 - это IP клиента VPN (Synology).

Я уже долго пытаюсь понять как-так выходит, что в какой-то момент выскакивает совсем левый IP в работе с удаленным хостом...

Но интересно еще то, что есть второй филиал, с такой же конфой. И там все работает без проблем... Конфиги OpenVPN думаю не нужны.


← Что нужно Xen для проброса PCI-устройства в гостя?
brocade fc switch: got invalid domain id -1 or domain id is missing in FabricInfo data page →

посмотри через что у 192.168.46.7 обратный к тебе маршрут в 10.11.12.1, может кривое правило для nat где то в фаерволле

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

Дак, судя по всему, нету у него маршрута на 192.168.46.7 к 10.11.12.1, только default через D-Link (192.168.46.1). В результате Synology (192.168.46.6) шлёт пакет к 192.168.46.7 напрямую, а тот отвечает через D-Link.

А вобще, занятная тема, маршрутизатор D-Link, openvpn клиент другая коробочка (Synology), пытаемся работать с web-камеров. В сети филиала вобще есть нормальные компьютеры?

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

Ну, да. Два компа. Вообще там сеть такая чтоб все примитивно было. Да и вроде должно же работать, чему там ломаться. Вот кстати роут с Synology:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.12.11     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.11.12.0      10.11.12.11     255.255.255.0   UG    0      0        0 tun0
10.10.3.0       10.11.12.11     255.255.255.0   UG    0      0        0 tun0
192.168.46.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.42.0    10.11.12.11     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.46.1    0.0.0.0         UG    0      0        0 eth0

В другом филиале такая же песня и работает... Сами понимаете, что нет желания городить в филиале шибко сложное.

Грешу конечно на D-Link. Но объяснить этого не могу. Примитивно, но не работает. Получается такая же петрушка может и во втором филиале получиться на ровном месте.

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

А ну и NAT на Synology:

iptables -nvt nat -L
Chain PREROUTING (policy ACCEPT 873 packets, 65356 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 79 packets, 19730 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   68 17951 MASQUERADE  all  —  *      tun0    0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 129 packets, 36638 bytes)
 pkts bytes target     prot opt in     out     source               destination

И на Сервере:

Chain PREROUTING (policy ACCEPT 15920 packets, 1407K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   udp  —  *      *       a.b.c.d          0.0.0.0/0            udp dpt:1194 redir ports 1195

Chain INPUT (policy ACCEPT 5516 packets, 564K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1381 packets, 85843 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1650 packets, 94324 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 4598  146K MASQUERADE  all  —  *      tun0    0.0.0.0/0            0.0.0.0/0           
    0     0 MASQUERADE  all  —  *      tun1    0.0.0.0/0            0.0.0.0/0
modjo
() автор топика
Ответ на: комментарий от modjo

Что то у вас тут и на сервере и на клиенте MASQUERADE, зачем он, если прописываете нормальные маршруты?

А по поводу нормальных компов, я думал, что попробовать поработать с ними, посмотреть как будет. На них ведь можно в случае чего написать маршрут к сети 10.11.12.0 через 192.168.46.6, чтобы пустить трафик без участия D-Link.

Что именно возникает в вашей сети я не знаю, возможно, так как D-Link не получает первый пакет соединения (10.11.12.1 -> 192.168.46.7 [SYN]) он не сразу начинает NAT'ить, пропускает [SYN, ACK] пакеты без NAT'а, а потом начинает NAT'ить.

В целом ваша схема не совсем корректна, так как в ней могут возникать icmp redirect пакеты (от D-Link'а), и как на них среагирует коробочка (камера, принтер) неведомо. Уж включите тогда MASQRADE на Synology для "-i tun0" пакетов, всё одно openvpn сервер делает для них MASQRADE и web-камера не видит реальный ip-адрес клиента.

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

По логике вещей, D-Link вообще не видит трафика, что идет через коробочку, так как он шифрованный. IP камера у D-Link'а спрашивает где сеть, от которой пришел запрос. Тот ей отвечает. И все. Ничего более происходить не должно, как я понимаю.

NAT сейчас включен на клиенте чтоб устройства в филиале могли иметь доступ в офис. И на сервере в обратную сторону. Не уверен что будет работать без NAT.

Заметил что если убрать NAT на клиенте, что тогда возникает левый запрос от D-Link'a, а если NAT есть, то от 10.11.12.10 (клиент на коробочке). Дамп снимал на стороне коробочки на tun0 интерфейсе.

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

Так и не понял в чем дело поснимал дампы. Филиал1 (не работает):

$ tshark -i eth0 port 80
Running as user «root» and group «root». This could be dangerous.
Capturing on eth0
  0.000000 192.168.46.7 -> 192.168.46.6 HTTP 78 Continuation or non-HTTP traffic
  0.000108 192.168.46.6 -> 192.168.46.7 TCP 66 38283 > http [ACK] Seq=1 Ack=13 Win=365 Len=0 TSval=7413647 TSecr=419278
  3.781970   10.11.12.1 -> 192.168.46.7 TCP 74 34749 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39629511 TSecr=0 WS=128
  3.782148   10.11.12.1 -> 192.168.46.7 TCP 74 34750 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39629511 TSecr=0 WS=128
  3.782916 192.168.46.7 -> 10.11.12.1   TCP 74 http > 34749 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=419656 TSecr=39629511 WS=2
  3.783111 192.168.46.7 -> 10.11.12.1   TCP 74 http > 34750 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=419656 TSecr=39629511 WS=2
  3.838401   10.11.12.1 -> 192.168.46.7 TCP 66 34749 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39629530 TSecr=419656
  3.838734   10.11.12.1 -> 192.168.46.7 TCP 66 34750 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39629530 TSecr=419656
  3.839065   10.11.12.1 -> 192.168.46.7 HTTP 435 GET / HTTP/1.1 
  3.840258 192.168.46.1 -> 10.11.12.1   TCP 66 http > 34749 [ACK] Seq=1 Ack=1 Win=3432 Len=0 TSval=419662 TSecr=39629530
  3.847812 192.168.46.1 -> 10.11.12.1   TCP 404 [TCP segment of a reassembled PDU]
  3.848006 192.168.46.1 -> 10.11.12.1   HTTP 66 HTTP/1.0 401 Unauthorized  (text/html)
  3.897183   10.11.12.1 -> 192.168.46.1 TCP 54 34749 > http [RST] Seq=1 Win=0 Len=0
  4.125030   10.11.12.1 -> 192.168.46.7 HTTP 435 [TCP Retransmission] GET / HTTP/1.1 
  4.125663 192.168.46.7 -> 10.11.12.1   TCP 60 http > 34749 [RST] Seq=1 Win=0 Len=0

$ tshark -i tun0 port 80
Running as user «root» and group «root». This could be dangerous.
Capturing on tun0
  0.000000   10.11.12.1 -> 192.168.46.7 TCP 60 34749 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39629511 TSecr=0 WS=128
  0.000223   10.11.12.1 -> 192.168.46.7 TCP 60 34750 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39629511 TSecr=0 WS=128
  0.001093 192.168.46.7 -> 10.11.12.1   TCP 60 http > 34749 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=419656 TSecr=39629511 WS=2
  0.001262 192.168.46.7 -> 10.11.12.1   TCP 60 http > 34750 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=419656 TSecr=39629511 WS=2
  0.056473   10.11.12.1 -> 192.168.46.7 TCP 52 34749 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39629530 TSecr=419656
  0.056819   10.11.12.1 -> 192.168.46.7 TCP 52 34750 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39629530 TSecr=419656
  0.057153   10.11.12.1 -> 192.168.46.7 HTTP 421 GET / HTTP/1.1 
  0.058464  10.11.12.10 -> 10.11.12.1   TCP 52 http > 34749 [ACK] Seq=1 Ack=1 Win=3432 Len=0 TSval=419662 TSecr=39629530
  0.065990  10.11.12.10 -> 10.11.12.1   TCP 390 [TCP segment of a reassembled PDU]
  0.066164  10.11.12.10 -> 10.11.12.1   HTTP 52 HTTP/1.0 401 Unauthorized  (text/html)
  0.115227   10.11.12.1 -> 10.11.12.10  TCP 40 34749 > http [RST] Seq=1 Win=0 Len=0
  0.125125   10.11.12.1 -> 10.11.12.10  TCP 40 34749 > http [RST] Seq=1 Win=0 Len=0
  0.125322   10.11.12.1 -> 10.11.12.10  TCP 40 34749 > http [RST] Seq=1 Win=0 Len=0
  0.343102   10.11.12.1 -> 192.168.46.7 HTTP 421 [TCP Retransmission] GET / HTTP/1.1 
  0.343828 192.168.46.7 -> 10.11.12.1   TCP 40 http > 34749 [RST] Seq=1 Win=0 Len=0

Филиал2 (работает):

$tshark -i eth0 port 80
Running as user «root» and group «root». This could be dangerous.
Capturing on eth0
  0.000000   10.11.12.1 -> 192.168.44.7 TCP 74 53995 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39657820 TSecr=0 WS=128
  0.000173   10.11.12.1 -> 192.168.44.7 TCP 74 53996 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39657821 TSecr=0 WS=128
  0.009861 192.168.44.7 -> 10.11.12.1   TCP 74 http > 53995 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1380 SACK_PERM=1 TSval=101148255 TSecr=39657820 WS=2
  0.010063 192.168.44.7 -> 10.11.12.1   TCP 74 http > 53996 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1380 SACK_PERM=1 TSval=101148255 TSecr=39657821 WS=2
  0.015306   10.11.12.1 -> 192.168.44.7 TCP 66 53995 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39657824 TSecr=101148255
  0.015464   10.11.12.1 -> 192.168.44.7 TCP 66 53996 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39657824 TSecr=101148255
  0.023948   10.11.12.1 -> 192.168.44.7 HTTP 409 GET / HTTP/1.1 
  0.024757 192.168.44.7 -> 10.11.12.1   TCP 66 http > 53995 [ACK] Seq=1 Ack=344 Win=6864 Len=0 TSval=101148257 TSecr=39657826
  0.032548 192.168.44.7 -> 10.11.12.1   TCP 425 [TCP segment of a reassembled PDU]
  0.032858 192.168.44.7 -> 10.11.12.1   HTTP 66 HTTP/1.0 401 Unauthorized  (text/html)
  0.038181   10.11.12.1 -> 192.168.44.7 TCP 66 53995 > http [ACK] Seq=344 Ack=360 Win=15744 Len=0 TSval=39657830 TSecr=101148258
  0.075601   10.11.12.1 -> 192.168.44.7 TCP 66 53995 > http [ACK] Seq=344 Ack=361 Win=15744 Len=0 TSval=39657840 TSecr=101148258

$tshark -i tun0 port 80
Running as user «root» and group «root». This could be dangerous.
Capturing on tun0
  0.000000   10.11.12.1 -> 192.168.44.7 TCP 60 53995 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39657820 TSecr=0 WS=128
  0.000216   10.11.12.1 -> 192.168.44.7 TCP 60 53996 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1368 SACK_PERM=1 TSval=39657821 TSecr=0 WS=128
  0.010009 192.168.44.7 -> 10.11.12.1   TCP 60 http > 53995 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1380 SACK_PERM=1 TSval=101148255 TSecr=39657820 WS=2
  0.010180 192.168.44.7 -> 10.11.12.1   TCP 60 http > 53996 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1380 SACK_PERM=1 TSval=101148255 TSecr=39657821 WS=2
  0.015345   10.11.12.1 -> 192.168.44.7 TCP 52 53995 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39657824 TSecr=101148255
  0.015521   10.11.12.1 -> 192.168.44.7 TCP 52 53996 > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=39657824 TSecr=101148255
  0.023994   10.11.12.1 -> 192.168.44.7 HTTP 395 GET / HTTP/1.1 
  0.024877 192.168.44.7 -> 10.11.12.1   TCP 52 http > 53995 [ACK] Seq=1 Ack=344 Win=6864 Len=0 TSval=101148257 TSecr=39657826
  0.032671 192.168.44.7 -> 10.11.12.1   TCP 411 [TCP segment of a reassembled PDU]
  0.032976 192.168.44.7 -> 10.11.12.1   HTTP 52 HTTP/1.0 401 Unauthorized  (text/html)
  0.038229   10.11.12.1 -> 192.168.44.7 TCP 52 53995 > http [ACK] Seq=344 Ack=360 Win=15744 Len=0 TSval=39657830 TSecr=101148258
  0.075642   10.11.12.1 -> 192.168.44.7 TCP 52 53995 > http [ACK] Seq=344 Ack=361 Win=15744 Len=0 TSval=39657840 TSecr=101148258

Теперь понятно как приходят запросы от левого хоста. Не понятно почему. Роутер в филиале пытается выполнить свое предназначение, выступить роутером между сетями. Мне поступают запросы от клиента VPN которые я успешно отбрасываю, потому-что не жду от него каких либо запросов. Осталось понять почему в одном варианте работает, в другом нет. Почему после успешного соединения вдруг начинается бред?!

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

IP камера у D-Link'а спрашивает где сеть, от которой пришел запрос.

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

Дампы пока не смотрел.

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

Да все верно, не спорю. Если убрать с D-Link запись о том, что сеть 10.11.12.0/24 на 192.168.46.6 то и пинги идти не будут. При добавлении все как положено.

Не очень понятно на какой стадии затык. Вроде как все идет, но потом бац и в дело вступает другое устройство, от которого запросы не ожидаются. Такое ощущение что удаленный хост какое-то время знает куда слать запросы, а потом, вдруг, забывает, посылает по default route...

Если появятся идеи буду признателен, у меня идеи кончились... Вот еще: если на компе в филиале прописать ручками маршрут - будет работать; из офиса имею доступ на клиента (Synology) и на роутер - во всех случаях на устройствах в таблице маршрутизации записан маршрут до сети 10.11.12.0/24 (на Synology потому как шлюз между сетями, а на роутере чтоб устройствам удаленной сети сообщить куда идти). Филиалы настроены одинаково. Все пытался вспомнить что же может быть разного - не вспомнил.

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

Нужно, чтобы D-Link не nat'ил пакеты от 192.168.46.0/24 на адреса 10.11.12.0/24 и 192.168.46.0/24. Или, не nat'ил пакеты, пришедшие из локальной сети и уходящие в локальную сеть. Я не знаю какие у него в этом плане возможны настройки. Может быть во втором филиале D-Link «умнее» (другая версия прошивки) и при одинаковых настройках не делает ненужный NAT.

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

Да одно и тоже оборудование и прошивка. По настройкам, вроде, все проверил. Да и не должно там быть чего-то особенного... В общем я в шоке... Надо будет обновить прошивку на D-Link, поставить американскую, будет доступ по ssh. Возможно после этого будут доступны новые горизонты...

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

Решение найдено. Я действительно не совсем правильно представлял как работает маршрутизация. Решение: d-link имеет возможность на свои 8 портов кидать vlan - synology в отдельный vlan и маршрутизация начинает работать как надо. Почему в одном филиале работало в другом нет - не понятно. Видимо глючит d-link (хотя прошивки одной версии).

modjo
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Что нужно Xen для проброса PCI-устройства в гостя?
Admin
brocade fc switch: got invalid domain id -1 or domain id is missing in FabricInfo data page →