доступ к локальному интерфейсу сервера из сети подключенной по VPN

[debcat12]

Привет! Никак не могу разобраться с проблемой!

Имеется локальная сеть 192.168.100.0, в ней сервер для веб сервиса 100.3, из локалки все работает нормально - доступ к веб и пинг есть. К данной сети по VPN подключена другая локальная сеть. Хосты между двумя сетями пингуются, но до сервера 100.3 пинга нет. Копаясь с этой проблемой обнаружил вот что, пинг появляется при старте системы (после перезагрузки сервера), пакетов 15 проходит а дальше пинг пропадает. Решил что блокирует файрвол, стал смотреть iptables, насколько я понял правил нету, все открыто:

root@topserv:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
root@topserv:~#

Не могу понять что еще может блокировать доступ из сети VPN

Если упустил что-то очевидное прошу камнями не закидывать, в linux системах еще начальный уровень.

Сервер 100.3 правда работает на debian а не на ubuntu, но думаю для данного вопроса это не критичный момент.

[AnrDaemon]

Не бывает так, что 15 пакетов проходят, а потом вдруг всё ломается.
Проверяйте каждый узел цепочки отдельно.

[debcat12]

Не бывает так, что 15 пакетов проходят, а потом вдруг всё ломается.
Проверяйте каждый узел цепочки отдельно.

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

[fisher74]

Linux системы здесь не при чём. Это вопрос построения сетей, который не зависит от ОС.
Как всегда новички лезут в iptables не разобравшись в более простых вещах. Например, в маршрутизации.

Таблицы маршрутизации смотрели? Нам покажете?

(Нажмите, чтобы показать/скрыть)

на всякий случай: таблицы нужно смотреть ВСЕХ элементов, участвующих в процессе

[AnrDaemon]

Проверил через трассировку

Вы понимаете разницу между "все" и "каждый"?…

[debcat12]

Linux системы здесь не при чём. Это вопрос построения сетей, который не зависит от ОС.
Как всегда новички лезут в iptables не разобравшись в более простых вещах. Например, в маршрутизации.

Таблицы маршрутизации смотрели? Нам покажете?

(Нажмите, чтобы показать/скрыть)

на всякий случай: таблицы нужно смотреть ВСЕХ элементов, участвующих в процессе

Все получилось, действительно маршрутизация! Прописал в таблицу целью удаленную сеть, шлюз основной сети (не VPN) пошел пинг и появился доступ к веб фейсу. Спасибо за помощь!

Правда не получается сделать после перезагрузки.
Прописал в /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet static
        address 192.168.100.3
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        post-up route add -net 192.168.120.0/24 gw 192.168.100.1

После ребута не работает, но если сделать service networking restart работает, до ребута.

[fisher74]

post-up route add -net 192.168.120.0/24 gw 192.168.100.1

После ребута не работает, но если сделать service networking restart работает, до ребута.

Вообще странно, что после рестарта networking срабатывает эта строка.

Удивительное дело. Для описания интерфейса в interfaces указываете архаичные параметры network и broadcast. А в качестве параметров утилиты route используете альтерантивный формат записи подсети.

Приведите команду в соответствие и будет срабатывать всегда.

Пользователь добавил сообщение 01 Ноября 2017, 07:08:50:И, ИМХО, это костыль. И вообще, все допы в настройках сети, сделанные на хостах - костыли.
Чтобы это не было костылём - нужно такие вещи делать на основном шлюзе.
Да, появляется лишнее колено, но в целях администрирования сети - это правильней.
Например завтра Вы решите перенести VPN-шлюз или вообще организуете резервирование канала до удалённой сети...

[debcat12]

И, ИМХО, это костыль. И вообще, все допы в настройках сети, сделанные на хостах - костыли.
Чтобы это не было костылём - нужно такие вещи делать на основном шлюзе.
Да, появляется лишнее колено, но в целях администрирования сети - это правильней.
Например завтра Вы решите перенести VPN-шлюз или вообще организуете резервирование канала до удалённой сети...

Странное дело! На хосте убрал из interfaces этот маршрут, прописал на шлюзе, та же проблема - после ребута (хоста) не работает. Потом убрал его из шлюза, то есть маршрут нигде не прописан. После service networking restart на хосте, доступ появляется. Куда копать?

[fisher74]

Вглубь конечно.
1. Вы точно правильно поняли словосочетание "основной шлюз"? (не сарказм - уточнение)
2.

Код: [Выделить]

cat /etc/network/interfaces в студию

[debcat12]

Вглубь конечно.
1. Вы точно правильно поняли словосочетание "основной шлюз"? (не сарказм - уточнение)
2.

Код: [Выделить]

cat /etc/network/interfaces в студию

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

2.

Код: [Выделить]

cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet static
        address 217.***.***.**
        netmask 255.255.255.224
        gateway 217.***.***.**
        dns-nameserver 217.***.***.** 217.***.***.**


allow-hotplug eth0
iface eth0 inet static
        address 192.168.100.3
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255

Этот хост еще используется как резервный шлюз, не основной

[fisher74]

1. Нет, Вы не правильно поняли. Имелось ввиду Default Gateway хоста.

НО!!! Тут выяснились ещё кое-какие детали построения сети.

Этот хост еще используется как резервный шлюз

А значит, вышеозвученный "костыль" выходит из статуса "костыль".

Значит надо выяснять, почему маршрут не добавляется при подъеме интерфейса eth0.
Может есть ещё какие-то тонкости в структуре сети?