Ubuntu не работает маршрутизация
Обновлено: 05.07.2024
Про правила добавления маршрутов в Windows я уже написал. Пришла пора написать про правила добавления маршрутов в любимой мною Ubuntu. Так же есть немного общей информации по данной теме, относящейся к Ubuntu и маршрутизации. И сразу поясню, что все действия требуется делать от имени суперпользователя ( root ).
Динамическая маршрутизация необходима в том случае, если у вас сложная, постоянно меняющаяся структура сети и одна и та же машина может быть доступна по различным интерфейсам (например, через разные Ethernet или SLIP интерфейсы). Маршруты, заданные статически, обычно не меняются, даже если используется динамическая маршрутизация. Для персонального компьютера, подключаемого к локальной сети, в большинстве ситуаций бывает достаточно статической маршрутизации командой route. Прежде чем пытаться настраивать маршруты, просмотрите таблицу маршрутизации ядра с помощью команды netstat -n -r . Вы должны увидеть что-то вроде следующего
Если таблица пуста, то вы увидите только заголовки столбцов. С помощью команды route можно добавить или удалить один (за один раз) статический маршрут. Вот ее формат:
Здесь аргумент “операция” может принимать одно из двух значений: add (маршрут добавляется) или delete (маршрут удаляется).
Аргумент “адресат” может быть IP-адресом машины, IP-адресом сети или ключевым словом default .
Аргумент “шлюз” - это IP-адрес компьютера, на который следует пересылать пакет (этот компьютер должен иметь прямую связь с вашим компьютером).
удаляет из таблицы данные обо всех шлюзах. Необязательный аргумент тип принимает значения net или host. В первом случае в поле адресата указывается адрес сети, а во втором - адрес конкретного компьютера (хоста). Как правило, бывает необходимо настроить маршрутизацию по упоминавшимся выше трем интерфейсам:
- локальный интерфейс ( lo ),
- интерфейс для платы Ethetnet ( eth0 ),
- интерфейс для последовательного порта ( PPP или SLIP ).
Локальный интерфейс поддерживает сеть с IP-номером 127.0.0.1 . Поэтому для маршрутизации пакетов с адресом 127.0.X.X используется команда:
Если у вас для связи с локальной сетью используется одна плата Ethernet, и все машины находятся в этой сети (сетевая маска 255.255.255.0 ), то для настройки маршрутизации достаточно вызвать:
Если же вы имеете насколько интерфейсов, то вам надо определиться с сетевой маской и вызвать команду route для каждого интерфейса. Поскольку очень часто IP-пакеты с вашего компьютера могут отправляться не в одну единственную сеть, а в разные сети (например, при просмотре разных сайтов в Интернете), то в принципе надо было бы задать очень много маршрутов. Очевидно, что сделать это было бы очень сложно, точнее просто невозможно. Поэтому решение проблемы маршрутизации пакетов перекладывают на плечи специальных компьютеров-маршрутизаторов, а на обычных компьютерах задают маршрут по умолчанию, который используется для отправки всех пакетов, не указанных явно в таблице маршрутизации. С помощью маршрута по умолчанию вы говорите ядру “а все остальное отправляй туда”. Маршрут по умолчанию настраивается следующей командой:
Опция gw указывает программе route , что следующий аргумент - это IP-адрес или имя маршрутизатора, на который надо отправлять все пакеты, соответствующие этой строке таблицы маршрутизации.
Имеются следующие интерфейсы /etc/network/interfaces :
Интерфейс eth0 это связь с локальной сетью состоящей из 20 подсетей 192.168.1.х-192.168.20.х
Интерфейс eth1 это связь с ADSL модемом с выходом в интернет. Так большинство запросов идут в Инет на этом интерфейсе прописываем шлюз ( gateway 192.168.254.1 ) данный параметр указывает в системе шлюз по-умолчанию, обращаю внимание, что шлюз надо прописывать только на одном интерфейсе, иначе в системе появятся 2 маршрута по умолчанию и естественно будет затупление в работе. С интернетом разобрались.
Но требуется еще просматривать ресурсы локальной сети для этого надо выполнить вот эти команды:
На этом примере маршрутизируются 3 подсети Все эти команды и многие другие можно прописать в файлк /etc/network/interfaces в итоге получится следующее:
По аналогии настраиваются любое кол-во маршрутов и сетевых интерфейсов. Обратите внимание:
так легко можно изменить MAC , не забываем после редактирования файла делать рестарт
Так же отмечу, что:
- Для того, чтобы просмотреть таблицу маршрутов достаточно запуска команды route без параметров или route -n , если в сети нет DNS .
- Маска может быть записана проще, в виде /x , где x - число единичных битов, например:
Настройки сети размещаются в файле /etc/network/interfaces :
При подключение к Inet через VPN ( ppp0 ), необходимо заменять маршрут по умолчанию на ppp0 . А проще указать в файле /etc/ppp/options следующее:
тогда маршрут заменяется сам и при отключении восстанавливается.
Есть прога, серверная часть которой стоит во внутренней сети, например Radmin Server, чтобы к нему подключиться клиентская прога (Radmin Viewer) запрашивает соединение по порту 5588 (например). Все работает внутри локальной сети. Есть шлюз (с внешним IP), через который обеспечивает доступ в и-нет всех компов внутренней сети. Теперь вопрос, как настроить шлюз, чтобы при обращении из вне клиентсокой частью к IP шлюза по порту 4799 , он пробрасывал этот запрос дальше, например на 192.168.0.2 по томуже порту? Для этого есть команда iptables .
up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0
Получаю следующую ошибку:
$sudo /etc/init.d/networking restart
* Reconfiguring network interfaces. SIOCADDRT: File exists
Failed to bring up eth0.
Я в принципе понимаю, что гейтвэй должен находиться в родной подсети, но других вариантов реализации не вижу. Может кто-нибудь поможет советом?
Может нужно добавить маршрут на 10.0.100.35?
up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
По идее должна показать где искать хост, но даже если оставить только
up route add -net 10.0.100.35 netmask 255.255.255.255 gw 10.10.0.254 dev eth0
up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0
то выдает такую же фигню SIOCADDRT: No such process
Если ты пропишешь поднятие этих маршрутов для другого интерфейса, то все заработает. Был такой баг и у меня когда-то. Заметил только одну закономерность, что если при установке системы не назначать интерфейсу статический адрес, а получать через DHCP, то после смены с DHCP на статику, при прописывании этому интерфейсу post и post-up команд, была такая же ошибка при поднятии интерфейса. Так как на машине было несколько интерфейсов, разбираться сильно не стал, и прописал маршруты при поднятии другого интерфейса - все заработало.
Пропиши эти маршруты при поднятии lo интерфейса.
Спасибо, но все равно не помогло. Если указать гейт по умолчанию до инициализации eth0, то в таблице роутов вообще ниче не будет, если после, то ошибка No such process.
>up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0
А маска для дефолтного маршрута не должна быть 0.0.0.0?
Я и так пробовал
up route add default gw 10.0.100.35 dev eth0
Тогда, помимо маски на дефолтный маршрут, попробуй везде заменить up на post-up - может, поможет.
И попробуй один раз перед тем, как делать invoke-rc.d networking start, выполнить ifconfig eth0 down - иногда, при изменении настройки интерфейсов, помогает. Потом, если нормально запустится, будет не нужно.
Спасибо, но не помогло, категорически отказывается устанавливать маршрут по умолчанию, если он из другой подсети. Я растроен и подавлен, в винде такой фокус на ура проскочил.
route add default gw 10.0.100.35
не помогает?
и попробуйте вручную по одному добавлять маршруты, и посмотреть при добавлении какого выдается ошибка.
Уже попробовал вручную :(
Результат тот же, что у автора треда.
Запостил на форумы убунты - может там чего подскажут:
>up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
>up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
>up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0
так писать нельзя. а что, на 10.10.0.254 настроить маршрутизацию нельзя?
короче, без карты твоей сети и решений по дизайну, которые заставили так сделать, ничем помочь не могу. есть серьезное подозрение, что ты лезешь за гландами через жопу.
кстати, default gateway это 0.0.0.0/0
Немного почти оффтопа:
val-amart, вот пример из жизни (чего я собственно так и заинтересовался этим тредом):
Есть машина в подсети А. Для всех машин в этой подсети есть дефолтный шлюз а1. Для него в свою очередь дефолтный шлюз - б1 в подсети Б. Для б1 дефолт гейтвей где-то в сети провайдера 1.
Провайдер 1 нас по ряду причин не устраивает, и мы сделали тестовое подключение к провайдеру 2. Поскольку подключение тестовое, в подсеть Б добавили шлюз б2, который смотрит в сеть нового провайдера.
Теперь мы хотим для нескольких машин из подсети А устроить тестовую эксплуатацию нового линка. Менять настройки шлюза а1 (а тем более б1, через который в инет ходит десятка два подсетей) нам не с руки - это только тест, и если линк упадет (в жизни он действительно падал, и не раз :) ), мы помешаем работе большого количества пользователей.
Стало быть, надо тестовым машинам в подсети А указать в настройках новый дефолт шлюз - б2 из подсети Б, и играться новым линком сколько влезет. Дык вот, для машин под оффтопичной системой этот фокус прошел на ура, а с Убунтой были проблемы. В конце концов, новый линк таки потестили как хотели - но это уже совсем другая история. А вопросы про Убунту остались.
Лазанье по форуму Убунты навело на мысль (хоть прямых указаний на это и не было), что отказ добавлять шлюз по умолчанию из другой подсети может быть связан с активностью замечательной тулзы NetworkManager.
Если ты планируешь использовать только статические настройки сети - попробуй удалить из системы NetworkManager, и посмотреть, как оно будет. Я до машин под 8.04, с которых он был снесен за ненадобностью, раньше вторника не доберусь - потому сам проверить сейчас не могу.
тут у вас проблемы не с убунту, а с оффтопиком, по рфц так делать нельзя.
корректные решения:
настроить дефолтгейт через б2 на а1 только для тестовых машин из сети А, остальных дальше пускать через б1. таким образом, конфигурировать надо только а1, а не десятки машин
Перенести тестовые машины из сети А в Б. физически, вланами, впном, да как угодно.
перенести б2 в сеть А. например, просто дополнительным портом с адресом из сети А.
первый вариант самый правильный и без проблемный, вы сами себе геморрой придумали. кстати, а зачем еще один роутер, почему не реализовать роутинг для второго провайдера на б1?
>Перенести тестовые машины из сети А в Б. физически, вланами, впном, да как угодно.
Так и сделали. Настроили соотв. порты на свичах в vlan для подсети Б. Но все равно - абыдна, да.
>первый вариант самый правильный и без проблемный, вы сами себе геморрой придумали. кстати, а зачем еще один роутер, почему не реализовать роутинг для второго провайдера на б1?
Пробовали и так и так. Поимели ряд небольших, но неприятных глюков - а1 и б1 достаточно нагруженные и не очень новые. В общем, не стоило оно колупаний - нам всего несколько машин погонять надо было, так что вариант с вланом все успешно решил.
P.S. А какой РФЦ (номер) запрещает настройку дефолтного шлюза в другой подсети, если путь к ней известен? Хочу почитать, дабы впредь так не морочиться.
> Пробовали и так и так. Поимели ряд небольших, но неприятных глюков - а1 и б1 достаточно нагруженные и не очень новые. В общем, не стоило оно колупаний - нам всего несколько машин погонять надо было, так что вариант с вланом все успешно решил.
Так бы и написал - ниасилили настроить роутер.
> P.S. А какой РФЦ (номер) запрещает настройку дефолтного шлюза в другой подсети, если путь к ней известен? Хочу почитать, дабы впредь так не морочиться.
internet host requirements, в секции про роутинг (1122, если память мне не изменяет).
похоже, ты вообще слабо представляешь, как работает routing algorithm, и путаешь routing table с routing cache. поэтому читай также 823.
дело в том, что роутер (по рфц) проходит по таблице маршрутов только однажды. ну, вот нашел он маршрут в сеть Z через маршрутизатор b2 (он находится в другой подсети, за другим ротером). дальше он попытается разрешить этот ip в mac, и конечно будет fail и ICMP type 3 code 1. Кстати, еще один вариант решения проблемы - настроить прозрачный арп-прокси на роутере а1, т.е. заставить его отзываться на арп-запросы к ип б2 и форвардить такие пакеты ему. но это еще больший изврат, и на многих современных НОС (убунте тоже, хаха) работать не будет.
>Так бы и написал - ниасилили настроить роутер.
Вай, дарагой. Даже отвечать на такое не хочется. Так и я могу сказать: "да ты рутеры только на картинках видел" - но это ж будет неправда. А в моем случае - как было, так и написал. Конкретно а1 и б1 - это L3 свичи cat4507, на каждом из которых проц загружен примерно на 60%. Если ты думаешь, что идеальная операционка IOS (точно версию, извини, не скажу - в отпуске сейчас) в таких условиях работает замечательно, и аж побежала тебе слать пакеты от хоста Зю через шлюз Кю, как только ты ей роут-мэп прописал и щелкнул пальцами - значит, у тебя впереди еще много увлекательных открытий :) В нашем случае это выглядело так: с тестовых хостов около 90% пакетов шло через новый шлюз, а около 10% - через старый. И не в моих или моих коллег кривых руках тут дело, да.
>похоже, ты вообще слабо представляешь, как работает routing algorithm, и путаешь routing table с routing cache. поэтому читай также 823.
Дядьку телепат, опять я рад за тебя безумно :) А за РФЦ 1122 - пасиб, почитаю.
>дело в том, что роутер (по рфц) проходит по таблице маршрутов только однажды. ну, вот нашел он маршрут в сеть Z через маршрутизатор b2 (он находится в другой подсети, за другим ротером). дальше он попытается разрешить этот ip в mac, и конечно будет fail и ICMP type 3 code 1.
Ясно. Пошел читать.
Ишшо раз благодарю за РФЦ. Еще б разобраться, как Виндоуз работает в подобной ситуации - ведь работает же, блин - а никакого подобия арп-прокси у нас 100% нету. Выйду на работу - буду глядеть.
очень просто - он совмещает route table и route cache в одной таблице, и ходит по ней трижды (!)
ну что ж, рад признать, что и ты не дурак. просто ранее оснований полагать иначе небыло, ты уж извини, больно наивно и по-детски твои выглядели предыдущие посты.
а конкретно по твоей проблеме могу сказать только, что роут мап вроде как отлично работает на л3 свитчах от цисок, правда с головы ни версию иоса, ни железа не скажу, но точно работает, в нормальных условиях. а какие у вас там были сложности мне ведь неизвестно. не думаю, что 60% загрузки основного цп (ты ведь про него?) сильно мешали. бюджетки 93 года отлично работают и при 90%. иос далеко не идеален, но инженеры циско не зря получают зарплату.
еще раз сорри если чем обидел.
> up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
> up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
Подсети перекрываются по IPv4-адресам?
> up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0
>> up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
>> up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
> Подсети перекрываются по IPv4-адресам?
сам-то понял, что сказал?
Добрый день! Хочу реализовать такую схему (Тык!). Прописал route в /etc/network/interfaces:
После чего маршруты показались в таблице route. Но результатов это не дало, стали пинговаться только сами роутеры (192.168.x.1), а дальше в сеть не пускает. Что делать в такой ситуации?
А что на сервере один интерфейс ?
eth0 смотрит в интернет. eth1 в локалку.
А сети за роутерами знают о существовании твоего компьютера?
А почему ты решил что gw 10.98.
90.1?
почему-то мне кажется, что из сетей 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24 нет маршрутов в сеть 10.98.90.1. проверь таблицу маршрутизации на соответствующих маршрутизаторах.
Все сети знаю о существовании 10.98.90.1, у всех через него идет интернет.
А не так:
up route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.3.1 eth0
А там не NAT ненароком на трех роутерах?
Ставил галочку не использовать NAT, не помогло.
Или, более правильно:
Где X,Y,Z - соотвествующие адреса роутеров из сети 10.98.90.0
А можно целиком
Вообще, как я понимаю, должно быть:
На сервере:
eth1 10.98.90.1
eth0.1 192.168.0.1
eth0.1 192.168.1.1
eth0.1 192.168.2.1
И три роутера не нужны, роутится на сервере, но все компы в одном ШВ домене, т.к. управляемых комутаторов у тебя нет.
На сервере:
wan eth1 10.98.90.1
lan eth0 192.168.8.1
На роутерах:
к серверу 192.168.8.3
к локалкам 192.168.2.1
пробовал также и
Про настройку роутеров не понял.
Скорее 10.98.90.2, но это так, гадание на кофейной гуще, нужны более точные данные.
Какой дефолтный шлюз на клиенте?
У роутера 192.168.1.1 - 10.98.90.198, роутера 192.168.2.1 - 10.98.90.196, роутера 192.168.3.1 - 10.98.90.197.
У всех прописан шлюз 10.98.90.1.
И как должен попасть клиент к 10.98.90.1 не зная промежуточных шлюзов? У роутеров шлюзом должен быть 10.98.90.1, у клиентов 192.168.2.1
Является промежуточным шлюзом?
Ой простите, сейчас зарисую схему от клиента до сервера.
Схема (Тык!), ну вообщем у меня так и есть, у роутеров шлюз 10.98.90.1, у клиентов шлюз 192.168.х.1.
Нарисуй, пожалуйста, схемку с обоими адресами на роутерах.
У тебя 10.98.90.1 это внутренний интерфейс сервера?
Если да, то:
1 роутер
wan 10.98.90.2 lan 192.168.1.1
2 роутер
wan 10.98.90.3 lan 192.168.2.1
3 роутер
wan 10.98.90.4 lan 192.168.3.1
Дальше на сервере маршруты в 192.168.3.x через 10.98.90.4.
У клиентов шлюз по умолчанию ip роутера из их подсети, на роутерах NAT выключен.
Вроде так.
Ну у меня ведь так и есть только адреса роутеров в сети 10.98.90.х отличаются.
Схема нормальная, работоспособная. От клиентов сервер пингуется?
В том то и дело, что клиенты видят сервер, а сервер их видеть не желает, так же как и клиенты друг друга из разных сетей.
А клиенты вобще должны пинговатся? ОС на них какая?
Windows 7, и пару 8.
Если даже роутер пингуется 192.168.1.1, то на него не получается зайти. Может что-то блокирует его?
А они в пределах подсети пингуются?
В пределах сети пингуются. Еще заметил что не возможно зайти на роутер по внешнему адресу 10.98.90.196, а внутри сети по этому адресу пускает. Как будто что-то фильтрует.
Бытовые роутеры по-умолчанию не пускают в админку с внешнего интерфейса.
Снял запрет, роутер впустил. Спасибо! Клиенты по прежнему не пингуются.
А ещё попробуй разрешить в роутере в межсетевом экране пакеты от всех внешних ip
Роутеры также внутрь ICMP по-умолчанию не пускают. Ищи настройку, а также добавь пути на соседние подсети.
На соседние подсети маршруты можно не добавлять на самих роутерах, но тогда все пакеты между соседними подсетями будут ходить через сервер. Будет больше прыжков.
Спасибо большое, все заработало. Проблема была в настройках роутера! (Настройка межсетевого экрана помогла)
Если нет простого решения - ищи очень простое (с)
Одно сделал, другое сломалось. Если кто знает, подскажите. До тога как начал настраивать маршруты, все клиенты видели все ресурсы в сети 10.98.90.х, Видимо когда шаманил что-то не туда написал. Проблема в том что клиенты 192.168.х.х видят не все ресурсы в сети 10.98.90.х. С чем это может быть связано?
ТС, кажется, доступы к сервисам собрался прописывать по IP.
Просто у меня в сети 10.98.90.х находится несколько серверов. Клиенты которые находятся на других подсетях видят не все сервера, а только 10.98.90.1, и еще пару клиентов сети 10.98.90.х., хотя раньше все видели всю сеть 10.98.90.х. Просто хотел узнать может кто сталкивался.
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.254.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.254.1 0.0.0.0 UG 0 0 0 eth1
Если таблица пуста, то вы увидите только заголовки столбцов. Тогда надо использовать route. С помощью команды route можно добавить или удалить один (за один раз) статический маршрут. Вот ее формат:
route -f операция -тип адресат шлюз интерфейс
Здесь аргумент операция может принимать одно из двух значений: add (маршрут добавляется) или delete (маршрут удаляется). Аргумент адресат может быть IP-адресом машины, IP-адресом сети или ключевым словом default . Аргумент шлюз -- это IP-адрес компьютера, на который следует пересылать пакет (этот компьютер должен иметь прямую связь с вашим компьютером). Команда
route -f
удаляет из таблицы данные обо всех шлюзах. Необязательный аргумент тип принимает значения net или host. В первом случае в поле адресата указывается адрес сети, а во втором -- адрес конкретного компьютера
(хоста).
Как правило, бывает необходимо настроить маршрутизацию по упоминавшимся выше трем интерфейсам:
* локальный интерфейс (lo),
* интерфейс для платы Ethetnet (eth0),
* интерфейс для последовательного порта (PPP или SLIP).
Локальный интерфейс поддерживает сеть с IP-номером 127.0.0.1. Поэтому для маршрутизации пакетов с адресом 127. используется команда:
route add -net 127.0.0.1 lo
Если у вас для связи с локальной сетью используется одна плата Ethernet, и все машины находятся в этой сети (сетевая маска 255.255.255.0), то для настройки маршрутизации достаточно вызвать:
route add -net 192.168.36.0 netmask 255.255.255.0 eth0
Если же вы имеете насколько интерфейсов, то вам надо определиться с сетевой маской и вызвать команду route для каждого интерфейса. Поскольку очень часто IP-пакеты с вашего компьютера могут отправляться не в одну единственную сеть, а в разные сети (например, при просмотре разных сайтов в Интернете), то в принципе надо было бы задать очень много маршрутов. Очевидно, что сделать это было бы очень сложно, точнее просто невозможно. Поэтому решение проблемы маршрутизации пакетов перекладывают на плечи специальных компьютеров - маршрутизаторов, а на обычных компьютерах задают маршрут по умолчанию, который используется для отправки всех пакетов, не указанных явно в таблице маршрутизации. С помощью маршрута по умолчанию вы говорите ядру "а все остальное отправляй туда". Маршрут по умолчанию настраивается следующей командой:
route add default gw 192.168.1.1 eth0
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.17.8
hwaddress ether 00:E0:4C:A2:C4:48
netmask 255.255.255.0
broadcast 192.168.17.255
auto eth1
iface eth1 inet static
address 192.168.254.2
netmask 255.255.255.0
gateway 192.168.254.1
broadcast 192.168.254.255
Интерфейс eth0 это связь с локальной сетью состоящей из 20 подсетей 192.168.1.х-192.168.20.х
Интерфейс eth1 это связь с ADSL модемом с выходом в интернет. Так большинство запросов идут в Инет на этом интерфейсе прописываем шлюз (gateway 192.168.254.1) данный параметр указывает в системе шлюз по-умолчанию, обращаю внимание, что шлюз надо прописывать только на одном интерфейсе, иначе в системе появятся 2 маршрута по умолчанию и естно будет затупление в работе. С интернетом разобрались.
Но требуется еще просматривать ресурсы локальной сети для этого надо выполнить вот эти команды
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
На этом примере маршрутизируются 3 подсети
Все эти команды и многие другие можно прописать в файлк
/etc/network/interfaces в итоге получится следующее:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.17.8
hwaddress ether 00:E0:4C:A2:C4:48
netmask 255.255.255.0
broadcast 192.168.17.255
up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
up route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
up route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
auto eth1
iface eth1 inet static
address 192.168.254.2
netmask 255.255.255.0
gateway 192.168.254.1
broadcast 192.168.254.255
Ну вот и все по аналогии настраиваются любое кол-во маршрутов и сетевых интерфейсов
Дополнение 1.
hwaddress ether 00:E0:4C:A2:C4:48
так легко можно изменить MAC, не забываем после редактирования файла делать рестарт
sudo /etc/init.d/networking restart
Дополнение 2.
Следует отметить, что:
1) Для того, чтобы просмотреть таблицу маршрутов достаточно запуска команды route без параметров или route -n, если в сети нет DNS.
2) Маска может быть записана проще, в виде /x, где x - число единичных битов, например:
route add -net 192.168.36.0/24 eth0
вместо
route add -net 192.168.36.0 netmask 255.255.255.0 eth0
Настройки сети размещаются в файле /etc/network/interfaces. При подключение к Inet через VPN (ppp0. ), необходимо заменять маршрут по умолчанию на ppp0. А проще указать в файле /etc/ppp/options следующее:
тогда маршрут заменяется сам и при отключении восстанавливается.
Дополнение 3.
Есть прога, серверная часть которой стоит во внутренней сети, например Radmin Server, чтобы к нему подключиться клиентская прога (Radmin Viewer) запрашивает соединение по порту 4799 (например). Все работает внутри локальной сети. Есть шлюз (с внешним IP), через который обеспечивает доступ в и-нет всех компов внутренней сети. Теперь вопрос, как настроить шлюз, чтобы при обращении из вне клиентсокой частью к IP шлюза по порту 4799, он пробрасывал этот запрос дальше, например на 192.168.0.2 по томуже порту?
Для этого есть команда iptables:
iptables -t nat -D PREROUTING -i <интерфейс> -s <IP откуда будет коннект> -p tcp --dport 4899 -j DNAT --to-destination 192.168.0.2:4899
Если ограничивать входящие IP не требуется, то опцию -s можно опустить.
Пример:
iptables -t nat -D PREROUTING -i vlan1 -s 213.87.34.20/24 -p tcp --dport 4899 -j DNAT --to-destination 192.168.128.24:4899
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 3658 -j DNAT --to-destination 192.168.0.2:3658
Читайте также: