LINUX - В вопросах и ответах.

[CraVen]

Собственно назрела идея создания единой прикрепленной темы, ввиду набора популярности этой операционки. Здесь будем обмениваться знаниями.

[bear]

Для начала я бы поставил Шлюзом по умолчанию ИП провайдера. Потом такой вопрос, циска и Убунта НАТят пакеты на выходе в сторону провайдера или как? Если не НАТят, то пров, просто моджет не знать куда ему пробросить пакеты, как об этом написал bear.

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

ЗЫЖ даже думаю что будет проще и эфективней поднять тунель, чем поднимать динамик нат, а нат это значит при высоком трафике достаточно сильно грузить циску

[Crypt]

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

ЗЫЖ даже думаю что будет проще и эфективней поднять тунель, чем поднимать динамик нат, а нат это значит при высоком трафике достаточно сильно грузить циску

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

[Faust]

Шлюз по умолчанию на убунте изменять нельзя, ибо она прокси=)
Сейчас таблица такая:
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.0.0      172.16.1.2      255.255.255.252 UG    0      0        0 eth1
172.16.1.0      *               255.255.255.252 U     1      0        0 eth1
192.168.5.0     *               255.255.255.0   U     1      0        0 eth0
192.168.10.0    172.16.1.2      255.255.255.0   UG    0      0        0 eth1
link-local      *               255.255.0.0     U     1000   0        0 eth1
default         192.168.5.254   0.0.0.0         UG    0      0        0 eth0
Что изменилось:
1. После добавления маршрута

route add -net 172.16.0.0 netmask 255.255.255.252 gw 172.16.1.2

пинги от убунты до циски и обратно бегают
2. После добавления маршрута
route add -net 192.168.10 netmask 255.255.255.0 gw 172.16.1.2
Стали ходить пинги от рабочих станций в сети за циской (192.168.10.х) до моей убунты (172.16.1.1)
Однако, с моих локальных машин (192.168.5.х) нет пинга до 172.16.1.2 (шлюз провайдера)
О как...

IPSec сейчас есть, однако ИП телефония сильно зависит от качества тырнета. Когда кто-то начинает сливать что-то большое по почте, разговаривать невозможно, а это довольно критично. Поэтому заказали канал точка-точка, чтобы снизить нагрузку на тырнет и от него не зависеть. Вот как-то так...

[bear]

Шлюз по умолчанию на убунте изменять нельзя, ибо она прокси=)
Сейчас таблица такая:
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.0.0      172.16.1.2      255.255.255.252 UG    0      0        0 eth1
172.16.1.0      *               255.255.255.252 U     1      0        0 eth1
192.168.5.0     *               255.255.255.0   U     1      0        0 eth0
192.168.10.0    172.16.1.2      255.255.255.0   UG    0      0        0 eth1
link-local      *               255.255.0.0     U     1000   0        0 eth1
default         192.168.5.254   0.0.0.0         UG    0      0        0 eth0
Что изменилось:
1. После добавления маршрутапинги от убунты до циски и обратно бегают
2. После добавления маршрута
route add -net 192.168.10 netmask 255.255.255.0 gw 172.16.1.2
Стали ходить пинги от рабочих станций в сети за циской (192.168.10.х) до моей убунты (172.16.1.1)
Однако, с моих локальных машин (192.168.5.х) нет пинга до 172.16.1.2 (шлюз провайдера)
О как...

IPSec сейчас есть, однако ИП телефония сильно зависит от качества тырнета. Когда кто-то начинает сливать что-то большое по почте, разговаривать невозможно, а это довольно критично. Поэтому заказали канал точка-точка, чтобы снизить нагрузку на тырнет и от него не зависеть. Вот как-то так...

на рабочих станциях должен прописан либо шлюз по умолчанию на 192.168.105.2
либо чтобы пингалась циска
сеть 172.16.0.0 255.255.255.252 на шлюз 192.168.105.2
чтобы пингалась другая сетка
сеть 192.168.10.0 255.255.255.0 на шлюз 192.168.105.2

ЗЫЖ а вообще есть такая вещь как QOS для ip телефонии

[Faust]

на рабочих станциях должен прописан либо шлюз по умолчанию на 192.168.105.2
либо чтобы пингалась циска
сеть 172.16.0.0 255.255.255.252 на шлюз 192.168.105.2
чтобы пингалась другая сетка
сеть 192.168.10.0 255.255.255.0 на шлюз 192.168.105.2

ЗЫЖ а вообще есть такая вещь как QOS для ip телефонии

На рабочей станции
IP-адрес  . . . . . . . . . . . . : 192.168.5.34
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.5.2

Обмен пакетами с 172.16.1.1 по 32 байт:
Ответ от 172.16.1.1: число байт=32 время<1мс TTL=64
Ответ от 172.16.1.1: число байт=32 время<1мс TTL=64

Обмен пакетами с 172.16.1.2 по 32 байт:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

[bear]

95% - шлюз провайдера не знает куда маршрутизировать пакеты для сети 192.168.105.0/24
сделай с рабочей станции tracert 172.16.0.1 и покаж, что получится

[Faust]

95% - шлюз провайдера не знает куда маршрутизировать пакеты для сети 192.168.105.0/24
сделай с рабочей станции tracert 172.16.0.1 и покаж, что получится

Все прыжки "Превышен интервал"
Почему нет пинга с рабочей станции до 172.16.1.2? Ведь это же должна убунта обрабатывать....

Трассировка маршрута к 172.16.0.1 с максимальным числом прыжков 30

  1     *        *        *     Превышен интервал ожидания для запроса.
  2     *        *        *     Превышен интервал ожидания для запроса.
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     *        *        *     Превышен интервал ожидания для запроса.
  5     *        *        *     Превышен интервал ожидания для запроса.
  6

[bear]

Все прыжки "Превышен интервал"
Почему нет пинга с рабочей станции до 172.16.1.2? Ведь это же должна убунта обрабатывать....

Трассировка маршрута к 172.16.0.1 с максимальным числом прыжков 30

 

убунта знает, что пакеты нада отправлять на 172.16.1.2 и где находится сеть 172.16.0.0
а вот шлюз провайдера не знает куда девать пакеты пришедшие с адреса 192.168.105.хх/24
так как в таблице маршрутизации у него нет такой записи и я так подозреваю нету дефолт гетвея куда можно было бы пихнуть пакет с неизвестным(для шлюза провайдера) дестинейшеном

[bear]

в общем необходимо на шлюзе провайдера прописать что то типа

#conf term
(config)# ip route 192.168.5.0 255.255.255.0 172.16.1.1

[Faust]

Все верно...
Отзвонился провайдеру, надо сбацать маршрутизацию у них....
Теперь вот ещё дилемма появилась...наши шефы думали, что будет канал 2 уровня, 2 адреса одной подсети, поэтому и маршрутизация обошлась бы в 1 строчку=)
Ждем решения сильных мира сего.... Может дожмут и дадут-таки связь...

[bear]

Все верно...
Отзвонился провайдеру, надо сбацать маршрутизацию у них....
Теперь вот ещё дилемма появилась...наши шефы думали, что будет канал 2 уровня, 2 адреса одной подсети, поэтому и маршрутизация обошлась бы в 1 строчку=)
Ждем решения сильных мира сего.... Может дожмут и дадут-таки связь...

ну если своими силами то - поднимайте тунель, а так судя по схеме - 3лвл

[Faust]

Мда, не получается, будем просить добавлять маршруты...
В свете сего, помогите ещё с одной бедой=)
Так как не все пакеты уходят с 5 в 10 подсеть (есть несколько других), добавил маршрут:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.5.254 , где 192.168.5.254 - маршрутизатор с поднятым впн-туннелем...что-то пакеты не ходють ...

Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.0.0      172.16.1.2      255.255.255.252 UG    0      0        0 eth1
172.16.1.0      *               255.255.255.252 U     1      0        0 eth1
192.168.5.0     *               255.255.255.0   U     1      0        0 eth0
192.168.0.0     192.168.5.254   255.255.255.0   UG    0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth1
default         192.168.5.254   0.0.0.0         UG    0      0        0 eth0

[bear]

стоп, у тебя каша

для начала определись какие сети тебе нужно чтобы ходили?
ибо

route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.5.254 , где 192.168.5.254

это 192.168.0.0 с маской 255.255.255.0 оно же /24 это диапазон ип адресов с 192.168.0.1 по 192.168.0.254 маршрутизируются на адрес 192.168.5.254
что ты вообще хочеш, более подробно

[bear]

в общем както так



Во вложении карта сети для эмуля - Pocket Tracer которую я нарисовал, оный можно кочьнуть тут: http://depositfiles.com/ru/files/97426e20e

[Faust]

стоп, у тебя каша

для начала определись какие сети тебе нужно чтобы ходили?
ибо
это 192.168.0.0 с маской 255.255.255.0 оно же /24 это диапазон ип адресов с 192.168.0.1 по 192.168.0.254 маршрутизируются на адрес 192.168.5.254
что ты вообще хочеш, более подробно

Именно так. 192.168.0.0/24 переправлять на маршрутизатор 192.168.5.254, однако пинга нет...
Такое ощущение, что где-то есть какое-то правило не пропускать пакеты, кроме 192.168.5.x ..... файервол не ставил, не настраивал... Есть только squid и dansguardian. Однако, они вряд ли могут блокировать, так ведь?

[bear]

а с какого маржоваго будет ходить, что либо из 192.168.0.0/ 24 на 192.168.5.254?
он не видит этот адрес(5.254), так как я уже написал что у тебя диапазон с 192.168.0.1 по 192.168.0.254
поднимай на рутере интерфейс из 192.168.0.0/24 сети и кидай все пакеты дефолтом для клиентов из сети 192.168.0.0/24 на этот интерфейс
и будет тебе щасте! (С)

[Faust]

а с какого маржоваго будет ходить, что либо из 192.168.0.0/ 24 на 192.168.5.254?
он не видит этот адрес(5.254), так как я уже написал что у тебя диапазон с 192.168.0.1 по 192.168.0.254
поднимай на рутере интерфейс из 192.168.0.0/24 сети и кидай все пакеты дефолтом для клиентов из сети 192.168.0.0/24 на этот интерфейс
и будет тебе щасте! (С)

Ммм...
192.168.5.0/24 -моя сеть
За роутером (192.168.5.254) через ВПН есть 192.168.0.0/24
Чтобы с 192.168.5.x машин (у которых шлюз 192.168.5.2) пакеты, предназначенные для 192.168.0.0/24 перекинуть на 192.168.5.254 надо:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.5.254, я правильно понимаю?

[bear]

Ммм...
192.168.5.0/24 -моя сеть
За роутером (192.168.5.254) через ВПН есть 192.168.0.0/24
Чтобы с 192.168.5.x машин (у которых шлюз 192.168.5.2) пакеты, предназначенные для 192.168.0.0/24 перекинуть на 192.168.5.254 надо:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.5.254, я правильно понимаю?

вот теперь стала более понятна топология
на рутере 192.168.105.254 нужно прописать следующее
route add -net 192.168.0.0 netmask 255.255.255.0 gw следующий_хоп_знающий_об_сети_192.168.0.0
на рутере 192.168.5.2
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.5.254
вообще у тебя на клиентах если стоит дефолт на 192.168.5.254 то на третем лвле ходить пакеты должны, если у тебя там дефолта нет, то на клиентах также нада указать где находится сеть 192.168.0.0
в общем опять же нужен трейс, с клиентской машины до любого узла 192.168.0.хх

[Faust]

вот теперь стала более понятна топология
на рутере 192.168.105.254 нужно прописать следующее
route add -net 192.168.0.0 netmask 255.255.255.0 gw следующий_хоп_знающий_об_сети_192.168.0.0
а не самого себя
вообще у тебя на клиентах если стоит дефолт на 192.168.5.254 то при выполненом условии строчкой выше - должно работать

Я на него и кидаю
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.5.254 А на 192.168.5.254 поднят IPSec до сети 192.168.0.0/24 Сейчас у локальных машин шлюз 192.168.5.254 и проблем нет, а вот меняя его на 192.168.5.2 (убунту), надо с убунты пересылать обратно на роутер...
Вот думаю, может, не убирать шлюз с локальных машин и оставить 192.168.5.254 и уже с него на убунту скидывать все, что предназначается для 192.168.10.0/24...

Добавил архитектуру...

[bear]

нарисовал схему как должны быть прописаны роуты
на этой схеме пингается хост в сети 192.168.0.0 с хоста в сети 192.168.10.0
также с 192.168.5.0 в 192.168.0.0, 192.168.5.0 в 192.168.10.0
причем у хостов в сети 192.168.5.0 дефолтом указан убунту 192.168.5.2

в общем заходи на маршрутизаторы, смотри, разбирайся в роутах, там все элементарно

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