Linux route add сеть недоступна

route чудит.. или я

Всем привет, столкнулся с некоторой, непонятной для меня проблемой

сеть 43 поднимается по wi-fi (по требованию — инет по мобиле), 50 локалка — подключена всегда. есть значит у меня такое interfaces

и казалось бы подсеть должна подниматься со своим шлюзом, но из-за того что он один то он ставится на default и видим следующее

а после того как цепляется вафля видим такое:

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

а теперь вопрос: почему сеть недоступна?

если сделать так:

У тебя у eth0 netmask не соответствует network.

этот косяк я поправил, а сюда копирнул не исправленный, но он сути не меняет совсем.

Логично: 2 шлюза по умолчанию — это отдельные танцы с бубном.

Определись где у тебя какие подсети кроме 0.0.0.0/0 и сделай на них статические маршруты. А уже потом крути шлюз по умолчанию как тебе вздумается.

Шлюз по-умолчанию один, второй я как раз пытаюсь запилить статически, и он выдает ошибку что нет сети.

Ну так ясен пень, ты удалил connected route и хочешь зароутить сеть 192.168.50.0/24 через шлюз в сети, маршрут в которую ты только что удалил?

Зачем тебе вообще удалять сеть 192.168.50.0/24 из таблицы маршрутизации?

Зачем тебе вообще удалять сеть 192.168.50.0/24 из таблицы маршрутизации?

а как еще можно назначит другой шлюз ?

Ээээ? Ты кажется не понимаешь как это работает.

Смотри, грубо говоря(потому что есть еще всякие recursive routing и протоколы динамической маршрутизации, но давай об этом умолчим — у тебя такой дичи там нет и не будет) в твоей топологии есть 2 вида маршрутов:

1) connected route. Это сеть, которая настроена на самом интерфейсе и доступна через него напрямую без всяких шлюзов.

Выглядит такой маршрут в выхлопе route так:

Обрати внимание на вторую колонку — там вместо шлюза указан *, что означает что шлюз не используется для данной подсети

2) static route. Сеть доступная через какой-то шлюз(который в свою очередь должен быть в одной из подсетей connected route-ов).

Частным случаем static route является маршрут по умолчанию(default route) — куда слать весь трафик, который не попал под любое другое правило(connected или более специфичных static route-ов).

Шлюз по умолчанию в выхлопе route выглядит так:

Обрати внимание на маску подсети(0.0.0.0) и наличие адреса шлюза во второй колонке. default в первой колонке — это своеобразный алиас для записи адреса сети 0.0.0.0.

То есть маршрут по умолчанию имеет адрес сети 0.0.0.0 и маску 0.0.0.0.

Соответственно процедура его добавления и удаления выглядит примерно так:

Имя интерфейса при добавлении статического маршрута(и маршрута по умолчанию в том числе, т.к. как я уже сказал — это разновидность статического) можно не указывать — оно высчитается автоматически из connected route-а той сети которой принадлежит шлюз.

Соответственно ты своими действиями не добавлял шлюз по умолчанию. Ты удалил connected route для проводной подсети и при попытке прописать статический маршрут(не default) на удаленную подсеть через шлюз в этой же подсети(которой еще НЕТ в таблице маршрутизации, т.к. ты ее только что и удалил) — закономерно получил облом!

Ну и наконец: ты же понимаешь, что убрав шлюз по умолчанию из wifi-подсети ты фактически не будешь пользоваться wifi-ем, кроме как для доступа к подсети 192.168.43.0 ?

В очередной раз рекомендую первые пару-тройку частей из цикла «Сети для самых маленьких». Конкретно часть 3 про статическую маршрутизацию — разложит всё по полочкам.

Я не хотел убирать шлюз по умолчанию(43.1) я хотел добавить статический маршрут для 50.0/24 на 50.254 и все.

Эээ, ты не можешь добавить статический маршрут для connected-сети через шлюз в ЭТОЙ ЖЕ сети. А сеть 50.0/24 подключена у тебя НЕПОСРЕДСТВЕННО по Ethernet.

Источник

снова. интерфейсы и шлюз

Еще раз, извините за настойчивость

eth0 x.x.x.x (внешняя) шлюз не указан
eth1 y.y.y.y (внутряная) шлюз y.y.y.ш
route default y.y.y.ш eth1

route -n
Dest Gw Genmask Iface
172.18.0.16 0.0.0.0 255.255.255.252 eth1
x.x.x.x 0.0.0.0 255.255.255.248 eth0
127.0.0.0 0.0.0.0 255.0.0.0 lo
0.0.0.0 172.18.0.17 0.0.0.0 eth1

При «ping www.чегото.гдето» — тишина
При «ping www.чегото.гдето -I x.x.x.x» — все нормально
(x.x.x.x — внешний адрес на интерфейсе eth0)

Пытаюсь «route add default gw 172.18.0.17 dev eth0»
Отвечает «SIOCADDRT: Сеть недоступна»

Может запутанно объясняю, но мне надо чтобы вместо eth1 в последней строчке (в ответе на route -n) было eth0.
Т.е. необходимо чтобы пакеты уходили через внутренний шлюз (y.y.y.ш) с подстановкой как источника внешнего адреса на интерфейсе eth0.

Re: снова. интерфейсы и шлюз

попробуй сначала route del default gw 172.18.0.17 dev eth1 или посмотри, откуда эта запись берется (в редхате смотреть в /etc/sysconfig/network-scripts, в дебиан /etc/network/interfaces)

Re: снова. интерфейсы и шлюз

Вопрос
Вы хотите исходящий трафик с этого компа отправлять через внутренний шлюз с адресом отправителя внешнего интерфейса?
А есть увереность что провайдер к которому подключен шлюз 172.18.0.17 будет принимать такие пакеты?
И истчо вопрос: А зачем?

Re: снова. интерфейсы и шлюз

To Agathis:
route del default gw 172.18.0.17 dev eth1 — да, удаляет,
но после этого все равно:
route add default gw 172.18.0.17 dev eth0
Отвечает «SIOCADDRT: Сеть недоступна»

В /etc/sysconfig/network-scripts что конкретно смотреть?

To nord:
«Вы хотите исходящий трафик с этого компа отправлять через внутренний шлюз с адресом отправителя внешнего интерфейса? »
Ага, наконец то нашелся понятливый человек.

Источник

ошибки в маршрутизации openvpn

Здравствуйте. Поднимаю openvpn. Клиент подключается по впн к серверу, видит локальную сеть за сервером. А сервер в свою очередь сеть за клиентом не видит (а очень хочется чтоб видел). Преследуемая цель — пользователи обоих сетей видят сети друг друга. конфиг сервера.

выхлоп с сервера*

на чём сидит клиент?

оба сервера на убунту сервер 16.04

А на клиента перенаправление трафика разрешено?

форвардинг в /etc/sysctl.conf раскоментирован.

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

ну спасибо на добром слове, сам то ты все сразу умел?

Начнём с того, что иптаблесы никакие не нужны. Нужно, чтобы умели оба маршрутизовать (net.ipv4.ip_forward) и чтобы были прописаны маршруты. Причём на клиент маршруты до сети сервака пушатся через конфиг у тебя, а на сервере маршрута до сети клиента нет. Не знаю, можно ли это через конфиги сделать, но можешь создать статический маршрут до сети клиента через VPN адрес клиента.

Хорошо, а что говорит ip r на сервере? Если там маршрут есть, то поставь на клиенте tcpdump и посмотри, доходят ли пакеты. Если доходят — посмотри на физическом интерфейсе, уходят ли, может быть так, что они уходят, но не возвращаются. Дальше уже в зависимости от того, что увидишь

на клиенте ничего не дропается, ufw пока отключил. маршрутизация у обоих включена. При добавление маршрута

Хочу поправится, клиент действительно не является шлюзом в своей сети, поэтому цель пока чтобы и клиент и сервер видели именно по тунелю не только тунельные ip друг друга (10.8.0.1,10.8.0.2), но и физические (10.27.1.5,10.2.1.5). На данный момент это может пока только клиент.

В логе openvpn что-нибудь есть? У тебя, насколько я помню документацию, сейчас подключение идёт не как нормальная подсеть, а как peer-to-peer. Соответственно, 10.8.0.2 — это адрес пира, которому сервер посылает данные, а у клиента должен быть .3 (там у них где-то таблица разрешённых адресов была, лень гуглить). Попробуй перенастроить клиент на другой адрес

помоему в логах ничего криминального. Да, ifconfig мне подсказывает что peer-to-peer

Ты, кстати, можешь сделать нормальную подсеть, сделав dev tap, а не tun

Ты на клиенте добавляешь? 10.8.0.2 — это что, ип сервера? Вроде он с .1 начинает.

Чтобы видеть сеть за клиентом, этот клиент должен являться маршрутизатором в своей сети. Хотя бы для сети той, что за сервером.

Лучше начни с того, что расскажие какие ипы по впн и в локалке у клиента и сервера. И какая таблица маршрутизации на каждом.

к сожалению не заработало. Попробовал в конфигах серва и клиента поменять tun на tap соединение вообще перестало происходить (правильно я понял ? только это менять в конфигах, остальное остается без изменений?)

тунельный ip 10.8.0.1

тунельный ip 10.8.0.4 (теперь уже, до момента когда мне XMs посоветовал его поменять был 10.8.0.2)

если речь о том когда я пытался добавить

Чтобы видеть сеть за клиентом, этот клиент должен являться маршрутизатором в своей сети. Хотя бы для сети той, что за сервером.

это отдельная песня как я буду заворачивать приходящий трафик на клиента в сеть, ее я буду реализовывать сам. Пока моя задача видеть пинговать с обоих серверов друг друга как по ip тунельным так и по физическим реальным адресам

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

Не могу подключиться к интернету

Модератор: Bizdelnick

Не могу подключиться к интернету

Сообщение famely » 19.11.2007 18:23

Недавно поставил MandrivaPowerpack+ 2007 и не могу настроить соединение с интернетом через кабель. У меня IP-адрес: 10.192.20.197; маска: 255.255.254.0; шлюз: 10.192.23.254; dns1: 89.*.*.*

Через Drake делаю выше описанные установки, Drake в конце поздравляет с тем, что сеть настроена и предлагает перезапустить Х-сервер. После перезапуска сети нет. Помогите, пожалуйста.

Re: Не могу подключиться к интернету

Сообщение SLEDopit » 20.11.2007 01:50

Недавно поставил MandrivaPowerpack+ 2007 и не могу настроить соединение с интернетом через кабель. У меня IP-адрес: 10.192.20.197; маска: 255.255.254.0; шлюз: 10.192.23.254; dns1: 89.*.*.*

Через Drake делаю выше описанные установки, Drake в конце поздравляет с тем, что сеть настроена и предлагает перезапустить Х-сервер. После перезапуска сети нет. Помогите, пожалуйста.

Re: Не могу подключиться к интернету

Сообщение famely » 20.11.2007 10:30

Re: Не могу подключиться к интернету

Сообщение o_r_k » 20.11.2007 11:11

Re: Не могу подключиться к интернету

Сообщение famely » 20.11.2007 12:05

Re: Не могу подключиться к интернету

Сообщение HiGH_ZeRO » 20.11.2007 15:22

У меня такая же проблема, но у меня ЛАН,а интернет vpn, вот мои ifconfig,route & resolv.conf

ifconfig
Link encap:Ethernet HWaddr 00:19:66:11:18:0B
inet addr:172.27.32.79 Bcast:172.27.32.255 Mask:255.255.255.0
inet6 addr: fe80::219:66ff:fe11:180b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:88456 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5363691 (5.1 MiB) TX bytes:7200 (7.0 KiB)
Interrupt:20 Base address:0xe800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:136 errors:0 dropped:0 overruns:0 frame:0
TX packets:136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6960 (6.7 KiB) TX bytes:6960 (6.7 KiB)
resolve.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.27.0.1
nameserver 193.27.208.1

route
Destination Gateway Genmask Flags Metric Ref Use Iface
172.27.32.0 * 255.255.255.0 U 10 0 0 eth0
169.254.0.0 * 255.255.0.0 U 10 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo

Re: Не могу подключиться к интернету

Сообщение famely » 20.11.2007 22:23

Вот и вечер. Выкладываю свои ifconfig, route и cat /etc/resolv.conf

ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:D3:99:D5:C2
inet addr:10.192.20.197 Bcast:10.192.21.255 Mask:255.255.254.0
inet6 addr: fe80::213:d3ff:fe99:d5c2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1149 errors:0 dropped:0 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:106575 (104.0 KiB) TX bytes:7163 (6.9 KiB)
Interrupt:17

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:67 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5062 (4.9 KiB) TX bytes:5062 (4.9 KiB)

route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.192.20.0 * 255.255.254.0 U 10 0 0 eth0
169.254.0.0 * 255.255.0.0 U 10 0 0 eth0

Источник