[Sysadmins] DHCPcd and BEELINE

[Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, ALT.

Один компьютер, в с двумя ОС. Windows XP pro и ARK server.

Подключается к проводному билайну (ех. корбина). Сетевой адрес получаю
по DHCP. Вот таблица маршрутизации в Windows:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
     85.21.72.80  255.255.255.240        10.50.4.1     10.50.4.171        1
     78.107.52.0    255.255.255.0        10.50.4.1     10.50.4.171        1
        10.0.0.0        255.0.0.0        10.50.4.1     10.50.4.171        1
    233.32.240.0    255.255.255.0      10.50.4.171     10.50.4.171        1
       10.50.4.0    255.255.255.0      10.50.4.171     10.50.4.171        20

          0.0.0.0          0.0.0.0        10.50.4.1     10.50.4.171       20
      85.21.78.93  255.255.255.255        10.50.4.1     10.50.4.171       1
      85.21.79.38  255.255.255.255        10.50.4.1     10.50.4.171       1
     85.21.79.170  255.255.255.255        10.50.4.1     10.50.4.171       1
     194.67.1.203  255.255.255.255        10.50.4.1     10.50.4.171       1
     195.14.50.16  255.255.255.255        10.50.4.1     10.50.4.171       1
   217.118.84.167  255.255.255.255        10.50.4.1     10.50.4.171       1
   217.118.84.249  255.255.255.255        10.50.4.1     10.50.4.171       1

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

1) Почему таблица маршрутизации в юниксе и Windows отличаются. И кто в
этом виноват.

2) Как посмотреть, что выдает DHCP сервер провайдера.

3)  Как  заставить  юникс вообще не добавлять маршрутов, в том числе и
шлюз  по  умолчанию? Ман читал. Ключ "G" заставляет не получать только
шлюз по умолчанию.

PS: Проверял на локальной сети.
Если этот  интерфейс  воткнуть  в  локальную  сеть  шлюз  по  умолчанию
получает  и  windows  и  юникс.  Если добавить "-G", то юникс маршруты
получает, а шлюз по умолчанию нет.

-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

Re: [Sysadmins] DHCPcd and BEELINE

[Mikhail Efremov]

On Mon, 21 Dec 2009 22:53:22 +0300 MisHel64 wrote:
> 2) Как посмотреть, что выдает DHCP сервер провайдера.

dhcpcd -T <интерфейс>, а еще лучше с помощью dhcpdump.

> 3)  Как  заставить  юникс вообще не добавлять маршрутов, в том числе и
> шлюз  по  умолчанию? Ман читал. Ключ "G" заставляет не получать только
> шлюз по умолчанию.

Не устанавливать полученные маршруты видимо никак.
Можно попробовать с помощью --nooption не запрашивать маршруты у
сервера.

-- 
WBR, Mikhail Efremov

Re: [Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, Mikhail.

Вы писали 22 декабря 2009 г., 17:14:24:

> On Mon, 21 Dec 2009 22:53:22 +0300 MisHel64 wrote:
>> 2) Как посмотреть, что выдает DHCP сервер провайдера.

> dhcpcd -T <интерфейс>, а еще лучше с помощью dhcpdump.

Попробовал....  информаци  на  экран выдпно в половину меньше, чем без
того ключа.

>> 3)  Как  заставить  юникс вообще не добавлять маршрутов, в том числе и
>> шлюз  по  умолчанию? Ман читал. Ключ "G" заставляет не получать только
>> шлюз по умолчанию.

> Не устанавливать полученные маршруты видимо никак.
> Можно попробовать с помощью --nooption не запрашивать маршруты у
> сервера.

перепробовал все значения от 1 до 200 и 249,запарился......
Но или не присваивается, и ругается на неправильный номер,
Или не ругается, и присваивает адрес и прописывает маршруты.
Шлюзом по умолчанию, становится не хочет ни при каких условиях...

-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

Re: [Sysadmins] DHCPcd and BEELINE

[Mikhail Efremov]

On Tue, 22 Dec 2009 17:58:48 +0300 MisHel64 wrote:
> >> 2) Как посмотреть, что выдает DHCP сервер провайдера.
> 
> > dhcpcd -T <интерфейс>, а еще лучше с помощью dhcpdump.
> 
> Попробовал....  информаци  на  экран выдпно в половину меньше, чем без
> того ключа.

Он выводит все, что получил от сервера в виде
new_имя_опции=значение
Можно увидеть что именно там приезжает?

> >> 3)  Как  заставить  юникс вообще не добавлять маршрутов, в том
> >> числе и шлюз  по  умолчанию? Ман читал. Ключ "G" заставляет не
> >> получать только шлюз по умолчанию.
> 
> > Не устанавливать полученные маршруты видимо никак.
> > Можно попробовать с помощью --nooption не запрашивать маршруты у
> > сервера.
> 
> перепробовал все значения от 1 до 200 и 249,запарился......
> Но или не присваивается, и ругается на неправильный номер,
> Или не ругается, и присваивает адрес и прописывает маршруты.

Интерес представляют скорее всего опции 33 и 121 (или 249, которую, как
я понял, использует вместо 121 весь из себя особенный MS. Кстати,
возможно маршруты не устанавливаются "как в Windows" потому что не
запрашивается эта опция).

> Шлюзом по умолчанию, становится не хочет ни при каких условиях...

Что-то я не пойму. Кто не хочет становиться шлюзом по умолчанию? Или
речь о том, что не устанавливается маршрут по умолчанию? Тогда я опять
не понял: ведь именно этого хотелось добиться с помощью опции -G?


-- 
WBR, Mikhail Efremov

Re: [Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, Mikhail.

Вы писали 22 декабря 2009 г., 19:06:34:

>> >> 2) Как посмотреть, что выдает DHCP сервер провайдера.
>> 
>> > dhcpcd -T <интерфейс>, а еще лучше с помощью dhcpdump.
>> 
>> Попробовал....  информаци  на  экран выдпно в половину меньше, чем без
>> того ключа.

> Он выводит все, что получил от сервера в виде
> new_имя_опции=значение

Нет, таких записей не выдает на экран. Может не там смотрю.

> Можно увидеть что именно там приезжает?

В  файл  ответы  затолкать  не получилось, пробую в ручную переписать.
hardware address = МОЙ_МАК
DUID= 14 16ричных цифр через двоеточие
broadcast for a lease
sending DHCP_DISCOVER with xid 0x14d0f17a, next in 3.36 second
offered 10.50.4.122 from 83.102.172.52
executing `/lib/dhcpcd/dhcpcd-run-hooks', reasin TEST

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

>> >> 3)  Как  заставить  юникс вообще не добавлять маршрутов, в том
>> >> числе и шлюз  по  умолчанию? Ман читал. Ключ "G" заставляет не
>> >> получать только шлюз по умолчанию.

>> > Можно попробовать с помощью --nooption не запрашивать маршруты у
>>
>> перепробовал все значения от 1 до 200 и 249,запарился......
>> Но или не присваивается, и ругается на неправильный номер,
>> Или не ругается, и присваивает адрес и прописывает маршруты.

> Интерес представляют скорее всего опции 33 и 121 (или 249, которую, как
> я понял, использует вместо 121 весь из себя особенный MS. Кстати,
> возможно маршруты не устанавливаются "как в Windows" потому что не
> запрашивается эта опция).

>> Шлюзом по умолчанию, становится не хочет ни при каких условиях...

> Что-то я не пойму. Кто не хочет становиться шлюзом по умолчанию? Или
> речь о том, что не устанавливается маршрут по умолчанию? Тогда я опять
> не понял: ведь именно этого хотелось добиться с помощью опции -G?

Да,  я про маршрут по умолчанию.  Прошу прощения, за мою терминологию.
В первоначальной задаче была именно цель не устанавливать этот маршрут
через  этот  интерфейс.  Но так получилось, что бы выяснить правильные
маршруты   для   этого   интерфейса,  необходимо  на  время  выяснения
установить  этот  маршрут.  Получить от провайдера подобную информацию
не  представляется возможным.  Или специалист просто не понимает о чем
речь, или сразу признается, что такой информации у него нет и получить
ее он не может.

Возвращаясь  к нашим баранам..... не важно указан ли ключ "G" или нет,
автоматически  маршрут  по умолчанию, при поднятии этого интерфейса не
прописывается. В Windows прописывается.


-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

Re: [Sysadmins] DHCPcd and BEELINE

[Mikhail Efremov]

On Wed, 23 Dec 2009 15:34:41 +0300 MisHel64 wrote:
> > Он выводит все, что получил от сервера в виде
> > new_имя_опции=значение
> 
> Нет, таких записей не выдает на экран. Может не там смотрю.
> 
> > Можно увидеть что именно там приезжает?
> 
> В  файл  ответы  затолкать  не получилось, пробую в ручную переписать.
> hardware address = МОЙ_МАК
> DUID= 14 16ричных цифр через двоеточие
> broadcast for a lease
> sending DHCP_DISCOVER with xid 0x14d0f17a, next in 3.36 second
> offered 10.50.4.122 from 83.102.172.52
> executing `/lib/dhcpcd/dhcpcd-run-hooks', reasin TEST
> 
> От  вывода  без  использования  ключей  отличается  только отсутствием
> информации об добавляемых маршрутов,

Просто в консоли введите команду
dhcpcd -T <интерфейс>.
Не надо добавлять ключ -T в options интерфейса, я так понял, что вы
делаете именно это и показываете вывод уже ifup.
С этим ключом dhcpcd не устанавливает никакой конфигурации, просто
выводит на экран информацию, полученную от сервера.
Затем сравните вывод с
dhcpcd -T --nooption=33,121,249 <интерфейс>

> > Что-то я не пойму. Кто не хочет становиться шлюзом по умолчанию? Или
> > речь о том, что не устанавливается маршрут по умолчанию? Тогда я
> > опять не понял: ведь именно этого хотелось добиться с помощью опции
> > -G?
> 
> Да,  я про маршрут по умолчанию.  Прошу прощения, за мою терминологию.
> В первоначальной задаче была именно цель не устанавливать этот маршрут
> через  этот  интерфейс.  Но так получилось, что бы выяснить правильные
> маршруты   для   этого   интерфейса,  необходимо  на  время  выяснения
> установить  этот  маршрут.  Получить от провайдера подобную информацию
> не  представляется возможным.  Или специалист просто не понимает о чем
> речь, или сразу признается, что такой информации у него нет и получить
> ее он не может.
> 
> Возвращаясь  к нашим баранам..... не важно указан ли ключ "G" или нет,
> автоматически  маршрут  по умолчанию, при поднятии этого интерфейса не
> прописывается. В Windows прописывается.

Это так изначально было или может виноват ключ -T, как я предположил
выше?
В любом случае, покажите вывод команд, приведенных выше.

-- 
WBR, Mikhail Efremov

Re: [Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, Mikhail.

Вы писали 23 декабря 2009 г., 16:53:01:

ФАЙЛ options из каталога интерфейса
TYPE=eth
MODULE=8139too
DISABLED=no
ONBOOT=yes
BOOTPROTO=dhcp,ipv4ll
CONFIG_IPV4=yes
CONFIG_IPV6=no
CONFIG_IPX=no
CONFIG_QOS=no
CONFIG_FW=no
DHCP_HOSTNAME=hsrv.m64.local
DHCP_ARGS=

> Просто в консоли введите команду
> dhcpcd -T <интерфейс>.

interface=e_bil
metric=0
pid=7635
reason=TEST
skip_hooks=lookup-hostname
new_broadcast_address=10.50.4.255
new_classless_static_routes='233.32.240.0/24 10.50.4.122 10.0.0.0/8 10.50.4.1 78.107.52.0/24 10.50.4.1 85.21.72.80/28 10.50.4.1'
new_dhcp_lease_time=604800
new_dhcp_message_type=2
new_dhcp_rebinding_time=529200
new_dhcp_renewal_time=302400
new_dhcp_server_identifier=83.102.172.52
new_domain_name_servers='213.234.192.8 85.21.192.3'
new_ip_address=10.50.4.122
new_network_number=10.50.4.0
new_routers=10.50.4.1
new_static_routes='85.21.78.93 10.50.4.1 85.21.79.170 10.50.4.1 85.21.79.38 10.50.4.1 194.67.1.203 10.50.4.1 195.14.50.16 10.50.4.1 217.118.84.167 10.50.4.1 217.118.84.249 10.50.4.1'
new_subnet_cidr=24
new_subnet_mask=255.255.255.0

> dhcpcd -T --nooption=33,121,249 <интерфейс>
interface=e_bil
metric=0
pid=8580
reason=TEST
skip_hooks=lookup-hostname
new_broadcast_address=10.50.4.255
new_classless_static_routes='233.32.240.0/24 10.50.4.122 10.0.0.0/8 10.50.4.1 78.107.52.0/24 10.50.4.1 85.21.72.80/28 10.50.4.1'
new_dhcp_lease_time=604800
new_dhcp_message_type=2
new_dhcp_rebinding_time=529200
new_dhcp_renewal_time=302400
new_dhcp_server_identifier=83.102.172.52
new_domain_name_servers='213.234.192.8 85.21.192.3'
new_ip_address=10.50.4.122
new_network_number=10.50.4.0
new_routers=10.50.4.1
new_subnet_cidr=24
new_subnet_mask=255.255.255.0

> Затем сравните вывод с

разница вот в этом:
new_static_routes='85.21.78.93 10.50.4.1 85.21.79.170 10.50.4.1 85.21.79.38 10.50.4.1 194.67.1.203 10.50.4.1 195.14.50.16 10.50.4.1 217.118.84.167 10.50.4.1 217.118.84.249 10.50.4.1'

>> Возвращаясь  к нашим баранам..... не важно указан ли ключ "G" или нет,
>> автоматически  маршрут  по умолчанию, при поднятии этого интерфейса не
>> прописывается. В Windows прописывается.

> Это так изначально было или может виноват ключ -T, как я предположил
> выше?

Таблица маршрутизации:

89.XXX.XXX.XXX  0.0.0.0         255.255.255.255 UH    0      0        0 ppp10
172.22.1.0      0.0.0.0         255.255.255.0   U     0      0        0 e_lan
172.22.0.0      0.0.0.0         255.255.255.0   U     0      0        0 e_mod
172.22.255.0    0.0.0.0         255.255.255.0   U     0      0        0 e_vir
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp10

и поднимаю интерфейс, получаю таблицу маршрутизации:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
89.XXX.XXX.XXX  0.0.0.0         255.255.255.255 UH    0      0        0 ppp10
85.21.72.80     10.50.4.1       255.255.255.240 UG    0      0        0 e_bil
233.32.240.0    10.50.4.122     255.255.255.0   UG    0      0        0 e_bil
172.22.1.0      0.0.0.0         255.255.255.0   U     0      0        0 e_lan
172.22.0.0      0.0.0.0         255.255.255.0   U     0      0        0 e_mod
10.50.4.0       0.0.0.0         255.255.255.0   U     0      0        0 e_bil
78.107.52.0     10.50.4.1       255.255.255.0   UG    0      0        0 e_bil
172.22.255.0    0.0.0.0         255.255.255.0   U     0      0        0 e_vir
10.0.0.0        10.50.4.1       255.0.0.0       UG    0      0        0 e_bil
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp10

добавляю в ФАЙЛ options из каталога интерфейса
DHCP_ARGS="-G -O 33,121,249"
получаю точно такую же таблицу маршрутизации.

Получается,     DHCPcd     игнорирует    команду    не    использовать
121   атрибут  (classless_static_routes),  и  не не хочет использовать  атрибуты
routers и static_routes.

На счет routers и static_routes вопрос:


1) DHCPcd просто не хочет их использовать;
2) DHCPcd не обязанн их использовать;
3)  Эти атрибуты описаны криво, по этому DHCPcd не понимает, в отличии
от  windows, что ему сказали. Отсюда и проблема в разных маршрутах под
этими двумя OS.

> В любом случае, покажите вывод команд, приведенных выше.

На всякий случай, я все правильно делаю?

-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

Re: [Sysadmins] DHCPcd and BEELINE

[Mikhail Efremov]

On Wed, 23 Dec 2009 19:40:38 +0300 MisHel64 wrote:
> > Просто в консоли введите команду
> > dhcpcd -T <интерфейс>.
> разница вот в этом:
> new_static_routes='85.21.78.93 10.50.4.1 85.21.79.170 10.50.4.1
> 85.21.79.38 10.50.4.1 194.67.1.203 10.50.4.1 195.14.50.16 10.50.4.1
> 217.118.84.167 10.50.4.1 217.118.84.249 10.50.4.1'

Странно, classless_static_routes тоже не должно быть. У меня dhcpcd
исправно не получает те опции, которые не запрашивались.
А если указать только 121:
dhcpcd -T --nooption=121 <интерфейс>
все равно classless_static_routes присутствуют?

> добавляю в ФАЙЛ options из каталога интерфейса
> DHCP_ARGS="-G -O 33,121,249"

Лучше DHCP_ARGS="-G -O 33 -O 121 -O 249", т.е каждую опцию отдельно,
иначе etcnet может заменить запятые на пробелы и строка опций будет не
правильной.

> Получается,     DHCPcd     игнорирует    команду    не    использовать
> 121   атрибут  (classless_static_routes),  и  не не хочет
> использовать  атрибуты routers и static_routes.
> 
> На счет routers и static_routes вопрос:
> 
> 
> 1) DHCPcd просто не хочет их использовать;
> 2) DHCPcd не обязанн их использовать;
> 3)  Эти атрибуты описаны криво, по этому DHCPcd не понимает, в отличии

Маршрут по умолчанию уже есть, поэтому dhcpcd не будет его
устанавливать. Можно сначала его удалить в ifup-pre, например.
А вот со static_routes действительно похоже проблема. Подозреваю,
dhcpcd не понимает, что у них префикс 32. Почитаю код и RFC, тогда
скажу больше.

> > В любом случае, покажите вывод команд, приведенных выше.
> 
> На всякий случай, я все правильно делаю?

Насколько я могу судить - да. Вот только мне не понятно почему -O 121
не срабатывает.

-- 
WBR, Mikhail Efremov

Re: [Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, Mikhail.

Вы писали 23 декабря 2009 г., 21:27:22:

>> > Просто в консоли введите команду
>> > dhcpcd -T <интерфейс>.
>> разница вот в этом:
>> new_static_routes='85.21.78.93 10.50.4.1 85.21.79.170 10.50.4.1
>> 85.21.79.38 10.50.4.1 194.67.1.203 10.50.4.1 195.14.50.16 10.50.4.1
>> 217.118.84.167 10.50.4.1 217.118.84.249 10.50.4.1'

> Странно, classless_static_routes тоже не должно быть. У меня dhcpcd
> исправно не получает те опции, которые не запрашивались.
> А если указать только 121:
> dhcpcd -T --nooption=121 <интерфейс>
> все равно classless_static_routes присутствуют?

да.

>> добавляю в ФАЙЛ options из каталога интерфейса
>> DHCP_ARGS="-G -O 33,121,249"

> Лучше DHCP_ARGS="-G -O 33 -O 121 -O 249", т.е каждую опцию отдельно,
> иначе etcnet может заменить запятые на пробелы и строка опций будет не
> правильной.

Да. Он именно так и делает. Исправил, но ничего не поменялось.

> Маршрут по умолчанию уже есть, поэтому dhcpcd не будет его
> устанавливать. Можно сначала его удалить в ifup-pre, например.
> А вот со static_routes действительно похоже проблема. Подозреваю,
> dhcpcd не понимает, что у них префикс 32. Почитаю код и RFC, тогда
> скажу больше.

Спасибо,  буду  ждать, и потом пинать службу поддержки, если окажется,
что это их вина.

>> > В любом случае, покажите вывод команд, приведенных выше.
>> 
>> На всякий случай, я все правильно делаю?

> Насколько я могу судить - да. Вот только мне не понятно почему -O 121
> не срабатывает.

Наверно стоит багу в багзиле поправить.

-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

Re: [Sysadmins] DHCPcd and BEELINE

[Mikhail Efremov]

On Wed, 23 Dec 2009 21:37:11 +0300 MisHel64 wrote:
> > Маршрут по умолчанию уже есть, поэтому dhcpcd не будет его
> > устанавливать. Можно сначала его удалить в ifup-pre, например.
> > А вот со static_routes действительно похоже проблема. Подозреваю,
> > dhcpcd не понимает, что у них префикс 32. Почитаю код и RFC, тогда
> > скажу больше.
> 
> Спасибо,  буду  ждать, и потом пинать службу поддержки, если окажется,
> что это их вина.

Чтение RFC принесло просветление:
   If the DHCP server returns both a Classless Static Routes option and
   a Router option, the DHCP client MUST ignore the Router option.

   Similarly, if the DHCP server returns both a Classless Static Routes
   option and a Static Routes option, the DHCP client MUST ignore the
   Static Routes option.
(подробнее см. RFC3442).
Т.е. все маршруты, прописанные в static_routes и routers должны быть
прописаны и в classless_static_routes, т.к. в случае, когда сервер
использует эту опцию, все остальные маршруты игнорируются клиентом.
Так что dhcpcd ведет себя полностью в соответствии со стандартом.
Но боюсь все попытки убедить в этом вашего провайдера разобьются о
железобетонное "в Windows все работает".

> > Насколько я могу судить - да. Вот только мне не понятно почему -O
> > 121 не срабатывает.
> 
> Наверно стоит багу в багзиле поправить.

Остается неясность с использованием опции, даже если указано -O, так
что багу пока не закрываю.

-- 
WBR, Mikhail Efremov

Re: [Sysadmins] DHCPcd and BEELINE

[Maks Re]

у меня тоже корбина.

# cat /etc/net/ifaces/brwan/options
TYPE=bri
HOST=wan
DISABLED=no
NM_CONTROLLED=no
BOOTPROTO=dhcp
DHCP_HOSTNAME=srv-gw-2
DHCP_ARGS="-G "

интернет поднимаю через ppp1 (именно он у меня меняет дефолтный
маршрут)
т.к. наличие поднятого brwan (корбина) не означает присутствие
интернета, то у меня дефолтный  маршрут смотрит на другой рутер в
локалке (адсл) когда нет ppp

Re: [Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, Maks.

Вы писали 23 декабря 2009 г., 16:44:09:

> у меня тоже корбина.

> # cat /etc/net/ifaces/brwan/options
> TYPE=bri

Этот  интерфейс  у меня ни при каких танцах с бубном получать что либо
от  хренлана  по  DHCP  не  захотел.   Да и сами bri интерфейсы мне не
нужны, я смысла в них не увидел. По этому снес.

> NM_CONTROLLED=no

Вот эту опцию в первый раз вижу. Чуть по подробней, и где почитать.

> DHCP_ARGS="-G "

Упс. На до то же пробел попробовать поставить. Может начнет работать.
У тебя маршруты добавляются после поднятия этого интерфейса?

> интернет поднимаю через ppp1 (именно он у меня меняет дефолтный
> маршрут)

У  меня  если  не  прописывать  маршруты  в  ручную, то маршрут на DNS
серверы  пролегает  через  другого  провайдера.  По этому ресолвинг ни
одного  локального  ресурса  билайна  не проходит, в том числе не могу
получить  и  адрес  VPN  сервера.  А  что прописывать в ручную, только
сейчас начал разбираться.

> т.к. наличие поднятого brwan (корбина)

точнее ее локалки, я правильно понял?

> не означает присутствие интернета,

> то у меня дефолтный  маршрут смотрит на другой рутер в
> локалке (адсл) когда нет ppp

Если  не  жалко,  поделись  маршрутами на локальные ресурсы корбины, и
файлами  настройки  для PPP1. У меня еще руки не дошли до этого. Лучше
на емайл, если не сложно.


-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

Re: [Sysadmins] DHCPcd and BEELINE

[Maks Re]

> > # cat /etc/net/ifaces/brwan/options
> > TYPE=bri
> 
> Этот  интерфейс  у меня ни при каких танцах с бубном получать что либо
> от  хренлана  по  DHCP  не  захотел.   Да и сами bri интерфейсы мне не
> нужны, я смысла в них не увидел. По этому снес.
это к вопросу дела не имеет, т.е. все равно это бридж или интерфейс.


> > NM_CONTROLLED=no
> 
> Вот эту опцию в первый раз вижу. Чуть по подробней, и где почитать.
оторвать NetworkManager

> 
> > DHCP_ARGS="-G "
> 
> Упс. На до то же пробел попробовать поставить. Может начнет работать.

# ps axf |grep dhcp
25980 pts/1    S+     0:00          \_ grep dhcp
 9843 ?        Ss     0:03 /usr/sbin/dhcpd
14584 ?        Ss     0:01 /sbin/dhcpcd -G -h srv-gw-2 -d -t 30 brwan


> У тебя маршруты добавляются после поднятия этого интерфейса?
то что присылают от корбины, прописываются.
можно добавить свои - в 
# cat /etc/net/ifaces/brwan/ipv4route
# vpn.spb.corbina.net
...
83.102.254.244/32 via 10.23.0.1
...


> 
> > интернет поднимаю через ppp1 (именно он у меня меняет дефолтный
> > маршрут)
> 
> У  меня  если  не  прописывать  маршруты  в  ручную, то маршрут на DNS
> серверы  пролегает  через  другого  провайдера.  По этому ресолвинг ни
> одного  локального  ресурса  билайна  не проходит, в том числе не могу
> получить  и  адрес  VPN  сервера.  А  что прописывать в ручную, только
> сейчас начал разбираться.
да, это геммор. сам до конца не понят как быть в подобной ситуации,
когда ДНС - это 85.21.192.4, а доступ к нему возможен только в
определенных ситуациях... то доступен из локалки корбины, то нет... то
только когда pptp поднят... вообщем пока забил.

 
> > т.к. наличие поднятого brwan (корбина)
> 
> точнее ее локалки, я правильно понял?
ага

> 
> > не означает присутствие интернета,
> 
> > то у меня дефолтный  маршрут смотрит на другой рутер в
> > локалке (адсл) когда нет ppp
> 
> Если  не  жалко,  поделись  маршрутами на локальные ресурсы корбины, и
> файлами  настройки  для PPP1. У меня еще руки не дошли до этого. Лучше
> на емайл, если не сложно.
я иcпользую только маршруты к впн серверам. ибо в момент поднятия pptp
днс то потухнет то погаснет..., а свой днс может не отрезолвить
# cat /etc/net/ifaces/ppp1/options
TYPE=ppp
PPPTYPE=pptp
#PPTP_SERVER=vpn.spb.corbina.net
PPTP_SERVER=83.102.254.244
REQUIRES=brwan
PPTP_EXTRA_OPTIONS=" --nobuffer --loglevel=0 "
ONBOOT=yes

# cat /etc/net/ifaces/ppp1/pppoptions
nodeflate
nobsdcomp
mtu 1360
usepeerdns
user USER
password SUPERPASS
nomppe
defaultroute
persist

Re: [Sysadmins] DHCPcd and BEELINE

[Mikhail Efremov]

On Wed, 23 Dec 2009 19:05:51 +0300 Maks Re wrote:
> > У  меня  если  не  прописывать  маршруты  в  ручную, то маршрут на
> > DNS серверы  пролегает  через  другого  провайдера.  По этому
> > ресолвинг ни одного  локального  ресурса  билайна  не проходит, в
> > том числе не могу получить  и  адрес  VPN  сервера.  А  что
> > прописывать в ручную, только сейчас начал разбираться.
> да, это геммор. сам до конца не понят как быть в подобной ситуации,
> когда ДНС - это 85.21.192.4, а доступ к нему возможен только в
> определенных ситуациях... то доступен из локалки корбины, то нет... то
> только когда pptp поднят... вообщем пока забил.

С помощью openresolv вполне можно разрулить, думаю. Он для того и
придуман.

-- 
WBR, Mikhail Efremov

Re: [Sysadmins] DHCPcd and BEELINE

[MisHel64]

Здравствуйте, Mikhail.

Вы писали 23 декабря 2009 г., 19:49:43:

>> да, это геммор. сам до конца не понят как быть в подобной ситуации,
>> когда ДНС - это 85.21.192.4, а доступ к нему возможен только в
>> определенных ситуациях... то доступен из локалки корбины, то нет... то
>> только когда pptp поднят... вообщем пока забил.

> С помощью openresolv вполне можно разрулить, думаю. Он для того и
> придуман.

Тут  в  другом  проблема.

Если  обращаться к DNS серверам билайна, через локальную сеть билайна,
то  ответ будет правильным. Но такое обращение не возможно, потому что
нет маршрута на эти сервера через эту сеть.

Если  через  другого провайдера, обращаться к DNS серверам билайна, то
ответ будет не правильным.

Если  использовать другие DNS сервера, то имя не будет преобразовано в
ип вообще.

То   есть,   без   доработки  напильником  таблицы  маршрутизации  DNS
преобразование  имен,  собственных  ресурсов  билайна в ип не работает
вообще, и никогда.


-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru

[Sysadmins] BEELINE (ex corbina)

[MisHel64]

Здравствуйте, Maks.

Вы писали 23 декабря 2009 г., 19:05:51:

> # ps axf |grep dhcp
> 14584 ?        Ss     0:01 /sbin/dhcpcd -G -h srv-gw-2 -d -t 30 brwan

Да, у меня так же выглядит почти.

>> У тебя маршруты добавляются после поднятия этого интерфейса?
> то что присылают от корбины, прописываются.

То есть та же самая ситуация, что и у меня.  -G говорит не прописывать
маршрут   по   умолчанию,   остальные   полученные  по  DHCP  маршруты
прописывать  разрешает.   Хм.   Меня  пытаются убедит, что должно быть
иначе, о чем написано в мане.

> # cat /etc/net/ifaces/brwan/ipv4route
> # vpn.spb.corbina.net
> ...
> 83.102.254.244/32 via 10.23.0.1
> ...

>> У  меня  если  не  прописывать  маршруты  в  ручную, то маршрут на DNS
>> серверы  пролегает  через  другого  провайдера.  По этому ресолвинг ни
>> одного  локального  ресурса  билайна  не проходит, в том числе не могу
>> получить  и  адрес  VPN  сервера.  А  что прописывать в ручную, только
>> сейчас начал разбираться.

> да, это геммор. сам до конца не понят как быть в подобной ситуации,
> когда ДНС - это 85.21.192.4, а доступ к нему возможен только в
> определенных ситуациях... то доступен из локалки корбины, то нет... то
> только когда pptp поднят... вообщем пока забил.

Ситуация  действительно странная. Спецы из билайна исправлять ситуацию
отказываются,  мотивируя  это тем, что под Windows все работает. А там
это  действительно  работает,  по  тому  что  прописывается маршрут по
умолчанию на их шлюз.

Те же спецы от билайна посоветовали добавить вот такие маршруты:
  10.0.0.0        255.0.0.0       10.50.48.1
  85.21.0.0      255.255.0.0       10.50.48.1
212.234.0.0      255.255.0.0       10.50.48.1
 195.14.0.0      255.255.0.0       10.50.48.1
 78.107.0.0      255.255.0.0       10.50.48.1
 78.102.0.0      255.255.0.0       10.50.48.1
 83.102.0.0      255.255.0.0       10.50.48.1

У  меня  стойкое  подозрение,  что  минимум  4  из  этих  маршрутов не
правильные. Я не про "10.50.48.1".

> я иcпользую только маршруты к впн серверам. ибо в момент поднятия pptp
> днс то потухнет то погаснет..., а свой днс может не отрезолвить
> # cat /etc/net/ifaces/ppp1/options

Спасибо за конфиг.

-- 
С уважением,
 MisHel64                          mailto:MisHel64@Bk.Ru