|
Маршрутизация в подсеть через отдельный гейт
приветствую!
дано локальная сеть 192.168.30.0/24 гейт: Код:
eth0 Link encap:Ethernet HWaddr *Код:
Kernel IP routing tableпри попытке завернуть траффик на подсеть через эту железку Код:
route add -net 10.10.19.0/24 gw 192.168.30.250Код:
route add 10.10.19.0 mask 255.255.255.0 192.168.30.250стёр свой мозг, прошу помощи) |
Цитата:
А если сеть за ней 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 |
Ну VPN должен железке присвоить адрес из своей сети.
Ну, или если он разный, то просто имя интерфейса указать который при создании VPN соединения создаётся , а не gw, |
впн работает, с ним все в порядке. если клиентам в сети прописать насильно маршрут (route add 10.10.19.0 mask 255.255.255.0 192.168.30.250) - все ходит и работает
но, очевидно, всей сети его вручную прописывать не будешь. надо научить гейт туда ходить :) |
Цитата:
|
в том и нюанс, что коробка существует "as is", что в ней происходит неизвестно и недоступно
|
Ну, а как она видна после поднятия VPN на компе, к которому она непосредственно подключена?
PS и зачем она вообще нужна, если любой Linux сам может быть клиентом VPN? |
она не подключена к компу, это microtik-роутер, который создает туннель на удаленную сеть, которая администрируется сторонними людьми
ее необходимость и тп не обсуждается, речь же об этом не идет. нужно завернуть на нее и через нее маршрут :) |
|
|
Ну и направьте :
route add -net 10.10.19.0/24 dev eth1 |
и что это даст?
Код:
traceroute 10.10.19.69 -nКод:
tcpdump -i eth1 -n | grep 10.10.19 |
Цитата:
DHCP прекрасно раздаёт клиентам статичные маршруты в отдельные подсети Цитата:
Такое впечатление, будто route пытается сначала удалить что-то "ненужное". Попробуйте написать команду как route add -net 10.10.19.0 netmask 24 gw 192.168.30.250 Цитата:
Не забывайте, что у любого маршрутизатора всегда как минимум два адреса Как я понимаю, 192.168.30.250 - это адрес с со стороны сети 192.168.30.0 А в сети 10.10.19.0 она имеет другой адрес |
Цитата:
Цитата:
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причины сего мне не ясны, если есть гуру, способные это объяснить - с интересом выслушаю |
Цитата:
причина в том, что компьютер не мог найти маршрут до 192.168.30.250 Ошибка находится здесь Цитата:
Код:
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 (и прочие) проходят, а проложить маршрут в другую сеть через него уже не получается |
Цитата:
Другой вопрос, что 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Если для 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 |
| Время: 21:32. |
Время: 21:32.
© OSzone.net 2001-