LINUX.ORG.RU
Форум — Admin  

Перестали ходить пинги с одной сети в другую

 , , ,


0

2

Всем привет. Ранее создавал сеть описанную в данном посте Помогите разобраться с организацией сети net2net

Не давно перестали ходить пинги с одной сети в другую, хотя с другой стороны пинги ходя нормально.

К примеру все хосты из сети 192.168.37.x могут пинговать хосты в сети 192.168.7.x, но пинги и сеть не видна из сети 192.168.7.x

Уже перепровил настройки - все вроде выглядит нормально. Может я что-то упустил. Может на тот момент я выполнил настройки и не сохранил таблицу iptables и после первой перезагрузки у меня все слетело.

Уважаемые знатоки подскажите что нужно проверить?

Спасибо!

← kswapd0 uses 100% CPU
Приоритет трафика в зависимости от порта →

Для полноты картины выкладываю tcpdump:

Пинг из сети 192.168.7.x в сеть 192.168.37.x

VPN Client Side 

#tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:57:58.870251 IP 192.168.7.55 > 192.168.37.1: ICMP echo request, id 5, seq 46118, length 40
08:58:03.871707 IP 192.168.7.55 > 192.168.37.1: ICMP echo request, id 5, seq 46119, length 40
08:58:08.871839 IP 192.168.7.55 > 192.168.37.1: ICMP echo request, id 5, seq 46120, length 40

VPN Server Side 

#tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:02:00.381279 IP 192.168.7.55 > 192.168.37.1: ICMP echo request, id 5, seq 46164, length 40
09:02:05.383399 IP 192.168.7.55 > 192.168.37.1: ICMP echo request, id 5, seq 46165, length 40
09:02:10.383096 IP 192.168.7.55 > 192.168.37.1: ICMP echo request, id 5, seq 46166, length 40



Пинги из сети 192.168.37.x в сеть 192.168.7.x

VPN Server Side:

#tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:05:03.541154 IP 192.168.37.1 > 192.168.7.55: ICMP echo request, id 1, seq 46418, length 40
09:05:03.545120 IP 192.168.7.55 > 192.168.37.1: ICMP echo reply, id 1, seq 46418, length 40
09:05:04.541119 IP 192.168.37.1 > 192.168.7.55: ICMP echo request, id 1, seq 46419, length 40
09:05:04.544505 IP 192.168.7.55 > 192.168.37.1: ICMP echo reply, id 1, seq 46419, length 40
09:05:05.542106 IP 192.168.37.1 > 192.168.7.55: ICMP echo request, id 1, seq 46420, length 40
09:05:05.546598 IP 192.168.7.55 > 192.168.37.1: ICMP echo reply, id 1, seq 46420, length 40
09:05:06.543154 IP 192.168.37.1 > 192.168.7.55: ICMP echo request, id 1, seq 46421, length 40
09:05:06.546787 IP 192.168.7.55 > 192.168.37.1: ICMP echo reply, id 1, seq 46421, length 40

VPN Client Side: 

#tcpdump icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:05:03.533930 IP 192.168.7.10 > 192.168.7.55: ICMP echo request, id 1, seq 46418, length 40
09:05:03.534415 IP 192.168.7.55 > 192.168.7.10: ICMP echo reply, id 1, seq 46418, length 40
09:05:04.533126 IP 192.168.7.10 > 192.168.7.55: ICMP echo request, id 1, seq 46419, length 40
09:05:04.533787 IP 192.168.7.55 > 192.168.7.10: ICMP echo reply, id 1, seq 46419, length 40
09:05:05.535198 IP 192.168.7.10 > 192.168.7.55: ICMP echo request, id 1, seq 46420, length 40
09:05:05.535829 IP 192.168.7.55 > 192.168.7.10: ICMP echo reply, id 1, seq 46420, length 40
09:05:06.535140 IP 192.168.7.10 > 192.168.7.55: ICMP echo request, id 1, seq 46421, length 40
09:05:06.535900 IP 192.168.7.55 > 192.168.7.10: ICMP echo reply, id 1, seq 46421, length 40

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

Смотри правила iptables на шлюзе 192.168.37.x сети. Похоже, что RELATED, ESTABLISHED пускает, а NEW - нет.

anonymous
()

Подсказка, ping - это ICMP протокол.

anonymous
()

Глянул на твою прошлую тему. У тебя там Винда. Отключи всё, что может лочить трафик. Это Брандмауэр и антивири всякие.

anonymous
()

100% сбросились iptables посмотри FORWARD правила, особенно для NEW

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

Виндовый файрвол - гораздо более прямая и простая вещь чем многие думают, и думаю автор уже это посмотрел. Вот внезапный сброс iptables после перезагрузки - может неслабо так напрягать, говорю как не один раз на эти грабли наступавший именно в контексте openvpn.

lovesan ★★★
()

подскажите что нужно проверить?

На хостах и на шлюзе:

ip a; ip r; sudo iptables-save; sysctl -a 2>/dev/null | grep net.*forward

На хостах должны быть разрешение на приём и отправку ICPM и симметричные роуты через шлюз, либо общий дефолтный шлюз.
На шлюзе нужно разрешение на форвард трафика между сетями на каждом из интерфейсов, соответствующие правила iptables filter/FORWARD и отсутствие правил для nat.

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

Пожалуйста напишите правильное правило для iptables. Я уже подзабыл написание правил. Давно настраивал...

На данный момент у меня пусто:

На клиентском OpenVPN:

# sudo iptables-save
# Generated by iptables-save v1.4.7 on Mon Apr 25 10:34:08 2016
*mangle
:PREROUTING ACCEPT [18:1616]
:INPUT ACCEPT [14:1376]
:FORWARD ACCEPT [4:240]
:OUTPUT ACCEPT [9:1367]
:POSTROUTING ACCEPT [13:1607]
COMMIT
# Completed on Mon Apr 25 10:34:08 2016
# Generated by iptables-save v1.4.7 on Mon Apr 25 10:34:08 2016
*filter
:INPUT ACCEPT [14:1376]
:FORWARD ACCEPT [2:120]
:OUTPUT ACCEPT [9:1367]
-A FORWARD -i eth0 -j ACCEPT
COMMIT
# Completed on Mon Apr 25 10:34:08 2016
# Generated by iptables-save v1.4.7 on Mon Apr 25 10:34:08 2016
*nat
:PREROUTING ACCEPT [4:591]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [1:120]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Apr 25 10:34:08 2016

На серверном OpenVPN: 

# iptables-save
# Generated by iptables-save v1.4.7 on Mon Apr 25 10:37:51 2016
*filter
:INPUT ACCEPT [246:40664]
:FORWARD ACCEPT [378:22680]
:OUTPUT ACCEPT [229:41705]
COMMIT
# Completed on Mon Apr 25 10:37:51 2016
# Generated by iptables-save v1.4.7 on Mon Apr 25 10:37:51 2016
*nat
:PREROUTING ACCEPT [5:477]
:POSTROUTING ACCEPT [3:369]
:OUTPUT ACCEPT [2:309]
-A POSTROUTING -s 10.10.3.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Apr 25 10:37:51 2016

OpenVPN сервер и клиент используются Linux CentOS 6.x Клиенты с обеих сторон Windows. В Windows Firewall разрешён прием ICMP.

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

Пробовал применить следующие правила

OpenVPN сервере: 

iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Результат такой же пинг не ходил.

Далее попробовал применить то же правило на OpenVPN клиенте: 

iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Дополнение: до этого поста при попытке пинговать с клиентского OpenVPN хост в сети OpenVPN сервера - пинги идут. Т.е. проблема в том что из сети OpenVPN клиента не проходят пинги.

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

Трассировка c IP 192.168.7.55: 

>tracert 192.168.37.1
Трассировка маршрута к SERVER-01 [192.168.37.1]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  DESKTOP-5D4KAQG [192.168.7.10]
  2    47 ms    21 ms     7 ms  10.10.3.1
  3     *        *        *     Превышен интервал ожидания для запроса.

10.10.3.1 - IPшник OpenVPN сервера - пингуется нормально. Но сетку за ним не пигует :(

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

FORWARD с -s и -d фигани, где -s это 10*** твоя т.е. vpn, а -d - маска подсети сетки к которой надо стучаться

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

Если я правильно догадался то на серверной стороне 37-я сетка. Если да, то попробуйте добавить -A POSTROUTING -s 192.168.7.0/24 -o eth0 -j MASQUERADE

anc ★★★★★
()

вылавливай, где теряются пакеты дампом.Тоесть на каком этапе пакет уходит в «небо». Да и насколько я помню, эти все маскарады и наты, при такой конфигурации сети и нафиг не нужны. Всё решается средствами самого openvpn.

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

добавил правило в конфигурацию iptables: 

-A POSTROUTING -s 192.168.7.0/24 -o eth0 -j MASQUERADE

перезагрузил iptables и роутер на стороне клиента - и все заработало!

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

Вот после этого разбирайте вин fw который может блокировать (что скорее всего), или с роутингом что тоже может иметь место быть, если клиент/сервер не являются маршрутами по умолчанию.
В случае если вам интересно разобраться кто именно виноват, скиньте сюда ip ro s и ip a, как с клиента так и сервера, плюс напишите какой адрес является шлюзом для вин клиентов в сети 37 и 7.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← kswapd0 uses 100% CPU
Admin
Приоритет трафика в зависимости от порта →