Показать полную графическую версию : [решено] Маршрутизация в подсеть через отдельный гейт
приветствую!
дано
локальная сеть 192.168.30.0/24
гейт:
eth0 Link encap:Ethernet HWaddr *
inet addr:80.*.*.* Bcast:80.*.*.* Mask:255.255.255.252
eth1 Link encap:Ethernet HWaddr *
inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.10.100.1 P-t-P:10.10.100.2 Mask:255.255.255.255
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.100.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
80.*.*.* 0.0.0.0 255.255.255.252 U 0 0 0 eth0
10.10.100.0 10.10.100.2 255.255.255.252 UG 0 0 0 tun0
192.168.100.0 10.10.100.2 255.255.255.0 UG 0 0 0 tun0
10.10.100.0 10.10.100.2 255.255.255.0 UG 0 0 0 tun0
192.168.31.0 10.10.100.2 255.255.255.0 UG 0 0 0 tun0
192.168.30.0 192.168.30.1 255.255.255.0 UG 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 80.*.*.* 0.0.0.0 UG 0 0 0 eth0
появилась новая vpn-железка, 192.168.30.250, за ней подсеть 10.10.19.0/24
при попытке завернуть траффик на подсеть через эту железку
route add -net 10.10.19.0/24 gw 192.168.30.250
SIOCADDRT: Нет такого процесса
route add -net 10.10.19.0/24 gw 192.168.30.250 dev eth1
SIOCADDRT: Нет такого процесса
при этом, если прописать на клиентах (win)
route add 10.10.19.0 mask 255.255.255.0 192.168.30.250
все прекрасно ходит
стёр свой мозг, прошу помощи)
ruslandh
27-05-2015, 15:09
192.168.30.250, за ней подсеть 10.10.19.0/24 »
Не понял, если у интерфейса 192.168.30.250, то и сеть за ней должна быть 192.168.30.0/24
А если сеть за ней 10.10.19.0/24, то и ip у железки должно быть из этой сети.
система веселая, я не спорю, попробую описать:
есть сеть локальная, 192.168.30.0/24
есть гейт из нее в мир, 192.168.30.1
есть коробочка, находится в локалке, с ip 192.168.30.250.
эта коробочка поднимает vpn через 192.168.30.1, сеть за vpn - 10.10.19.0/24
задача - прописать на гейте маршрут в 10.10.19.0/24 для всех клиентов сети 192.168.30.0/24
ruslandh
27-05-2015, 15:38
Ну VPN должен железке присвоить адрес из своей сети.
Ну, или если он разный, то просто имя интерфейса указать который при создании VPN соединения создаётся , а не gw,
впн работает, с ним все в порядке. если клиентам в сети прописать насильно маршрут (route add 10.10.19.0 mask 255.255.255.0 192.168.30.250) - все ходит и работает
но, очевидно, всей сети его вручную прописывать не будешь. надо научить гейт туда ходить :)
ruslandh
27-05-2015, 16:40
впн работает, » а никто и не сомневался. Вопрос в том, какой интерфейс (типа ppp0 и т.п.) при этом создаётся.
в том и нюанс, что коробка существует "as is", что в ней происходит неизвестно и недоступно
ruslandh
27-05-2015, 18:01
Ну, а как она видна после поднятия VPN на компе, к которому она непосредственно подключена?
PS и зачем она вообще нужна, если любой Linux сам может быть клиентом VPN?
она не подключена к компу, это microtik-роутер, который создает туннель на удаленную сеть, которая администрируется сторонними людьми
ее необходимость и тп не обсуждается, речь же об этом не идет. нужно завернуть на нее и через нее маршрут :)
ruslandh
27-05-2015, 18:28
Ну как-то она к шлюзу подключена?
Вот пример -
http://habrahabr.ru/post/227913/
eth1 Link encap:Ethernet HWaddr *
inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0 »
появилась новая vpn-железка, 192.168.30.250, за ней подсеть 10.10.19.0/24 »
в локальной сети
ruslandh
27-05-2015, 19:02
Ну и направьте :
route add -net 10.10.19.0/24 dev eth1
и что это даст?
traceroute 10.10.19.69 -n
traceroute to 10.10.19.69 (10.10.19.69), 30 hops max, 40 byte packets using UDP
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 192.168.30.1 (192.168.30.1)(H!) 2883.986 ms (H!) 2875.995 ms (H!) 2867.999 ms
tcpdump -i eth1 -n | grep 10.10.19
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
19:11:51.298993 arp who-has 10.10.19.69 tell 192.168.30.1
19:11:52.298991 arp who-has 10.10.19.69 tell 192.168.30.1
19:11:54.302992 arp who-has 10.10.19.69 tell 192.168.30.1
El Scorpio
28-05-2015, 05:40
но, очевидно, всей сети его вручную прописывать не будешь. надо научить гейт туда ходить »
А почему бы и не да?
DHCP прекрасно раздаёт клиентам статичные маршруты в отдельные подсети
route add -net 10.10.19.0/24 gw 192.168.30.250
SIOCADDRT: Нет такого процесса »
Такая ошибка выводится, когда route пытается удалить отсутствующий маршрут
Такое впечатление, будто route пытается сначала удалить что-то "ненужное".
Попробуйте написать команду как
route add -net 10.10.19.0 netmask 24 gw 192.168.30.250
Не понял, если у интерфейса 192.168.30.250, то и сеть за ней должна быть 192.168.30.0/24
А если сеть за ней 10.10.19.0/24, то и ip у железки должно быть из этой сети. »
А вот тут-то вы неправы.
Не забывайте, что у любого маршрутизатора всегда как минимум два адреса
Как я понимаю, 192.168.30.250 - это адрес с со стороны сети 192.168.30.0
А в сети 10.10.19.0 она имеет другой адрес
почему бы и не да?
DHCP прекрасно раздаёт клиентам статичные маршруты в отдельные подсети »
существует еще софтовый впн, через который клиенты и подсети подключаются в сеть 192.168.30.0/24 и должны иметь доступ в 10.10.19.0/24. мне кажется, некорректно раздвать такие маршруты на всех удаленных подсетях через dhcp, да и маршруты там не пропишешь из-за гейта в иной подсети
Попробуйте написать команду как
route add -net 10.10.19.0 netmask 24 gw 192.168.30.250 »
если вы имели в виду "-net 10.10.19.0/24", то никакой разницы нет. та же ошибка. с вашим же вариантом -
route: bogus netmask 24
в общем, если кому-то интересно, проблему решил какой-то особой магией.
route add 192.168.30.250 dev eth1
после чего
route add -net 10.10.19.0/24 gw 192.168.30.250
прекрасно отработал, как должен был
причины сего мне не ясны, если есть гуру, способные это объяснить - с интересом выслушаю
El Scorpio
30-05-2015, 03:52
причины сего мне не ясны, если есть гуру, способные это объяснить - с интересом выслушаю »
Попробую объяснить
причина в том, что компьютер не мог найти маршрут до 192.168.30.250
Ошибка находится здесь
192.168.30.0 192.168.30.1 255.255.255.0 UG 0 0 0 eth1 »
Сравните хотя бы с этим
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
Не может сетевая карта быть "шлюзом" для локальной сети.
Хотя бы потому что адрес 192.168.30.1 сам является частью диапазона 192.168.30.0/24, а значит любая попытка разбора такой "маршрутизации" приводит к зацикливанию алгоритма.
Скорее всего в сетевой подсистеме linux для таких ляпов предусмотрены проверки, просто они в разных ситуациях срабатывают по разному: при отправке пакетов отправляют их напрямую, а при модификации таблицы маршрутизации прекращают поиск. Вот потому пинги на устройство 192.168.30.250 (и прочие) проходят, а проложить маршрут в другую сеть через него уже не получается
ruslandh
30-05-2015, 05:07
Не может сетевая карта быть "шлюзом" для локальной сети. »
Да ну, сколько угодно.
Другой вопрос, что
route add -net 10.10.19.0/24 dev eth1 - просто перекидывала запрос на eth1, без указания какому компу посылать (широковещательный запрос), а шлюз не сообщал, что это его запросы.
А route add -net 10.10.19.0/24 gw 192.168.30.250 указало конкретный адрес шлюза.
El Scorpio
31-05-2015, 07:41
Цитата El Scorpio:
Не может сетевая карта быть "шлюзом" для локальной сети. »
Да ну, сколько угодно. »
Повторяю: не может быть интерфейс локальной сети быть сам себе "шлюзом" для этой же сети
route add -net 10.10.19.0/24 dev eth1 - просто перекидывала запрос на eth1, без указания какому компу посылать (широковещательный запрос), а шлюз не сообщал, что это его запросы.
А route add -net 10.10.19.0/24 gw 192.168.30.250 указало конкретный адрес шлюза. »
Вынужден констатировать, что вы имеете крайне смутное представление о работе таблицы маршрутизации
Рассмотрим самую простую таблицу
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Каждый пакет протоколов TCP, UDP, ICPM и ряда других содержит значение IP-адреса и MAC-адреса получателя.
Если для IP-адреса получателя в таблице маршрутизации есть диапазон без шлюза (адрес 0.0.0.0), тогда отправитель делает прямую передачу информации следующим образом:
1. Отправляет служебный запрос ARP "Кто здесь 192.168.0.10?".
Только этот запрос является широковещательным, потому что у него MAC получателя равен FFFFFFFFFFFF, и такой пакет принимают все устройства данной локальной сети. Все прочие пакеты содержат MAC-адреса конкретных устройств, и принимаются только этими устройствами.
2. Устройство с этим IP-адресом присылает ответ "Ну я здесь 192.168.0.10"
3. Отправитель берёт из ответа MAC-адрес устройства, и записывает его в таблицу ARP, где тот хранится некоторое время
4. Затем отправитель начинает отправлять пакеты с данными, в которых указывается IP и MAC конечного получателя.
Если для IP-адреса получателя в таблице маршрутизации есть диапазон с указанным шлюзом, тогда отправитель делает запрос ARP по адресу шлюза, а затем начинает отправлять пакеты с данными, в которых указывается IP конечного получателя и MAC шлюза. Далее подразумевается что указанный шлюз получит этот пакет и отправит далее в нужную сеть по своей таблице маршрутизации.
А теперь вопрос: если сетевая карта является шлюзом для своей локальной сети, и IP-адрес шлюза совпадает с IP-адресом самой сетевой карты, то какие значения адресов будут в отправляемом пакете?
Правильно: отправляемый пакет будет иметь IP конечного получателя и MAC самого отправителя. Как следствие, этот пакет сможет принять только сам отправитель. Затем он будет пересылать пакет снова и снова, пока в пакете не обнулится значение TTL (время жизни)
Однако сейчас такие "маршруты" работают корректно, потому что в современных реализациях стека протоколов TCP/IP предусмотрели защиту от такой глупости.
-------------------------------------------------------
Теперь вернёмся к проблеме jscar, совершившего именно такую глупость.
Команда route add -net 10.10.19.0/24 gw 192.168.30.250 завершается ошибкой, потому что route просматривает таблицу маршрутизации на предмет прямых маршрутов до 192.168.30.250. То есть он ищет нужное значение только среди среди строк, у которых адрес шлюза равен 0.0.0.0
А среди таких срок нужного диапазона нет :(
Посему нужно заменить неправильный маршрут
192.168.30.0 192.168.30.1 255.255.255.0 UG 0 0 0 eth1
на правильную запись
192.168.30.0 0.0.0.0 255.255.255.0 UG 0 0 0 eth1
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.