Рекомендованные сообщения

Судя по логам моего роутера, аренда обновляется каждые 4-7 дней. l2tp туннель, опять же, судя по логам, не падает. Но меня смущает большое кол-во попыток renew (всегда 13-14 раз). Причем похоже, что DHCPACK доходит до udhcpc в самый последний момент, когда время аренды заканчивается. Надо видимо будет запустить в фоне tcpdump.

 

Вот это поворот. tcpdump показал, что dhcp запросы таки идут через l2tp туннель. ВОПРОС! Почему все-таки маршрут до DHCP сервера отдается в устаревшей опции 33, а не 121, или 249?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поймите, сделать все и всем разом не получится, иначе бы давно сделали :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Понятно. Списибо за ответ.

 

Подготовительный период с маленьким временем аренды, но без IPoE все-таки будет у всех, или после обката в нескольких районах впоследующем будете перенастраивать сети сразу с добавлением поддержки IPoE, как тут или в соседних темах некоторые уже предлагали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Авторизация всего 1 раз? Круто! Полечу на праздники бабушку свою переводить на IPoE =)

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

Так?

Тады ой! Забираю все свои слова обратно о целесообразности не трогать L2TP и не нарушать то, что в Корбине годами эксплуатировалось... :thanx:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Авторизация всего 1 раз? Круто! Полечу на праздники бабушку свою переводить на IPoE =)

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

Так?

Тады ой! Забираю все свои слова обратно о целесообразности не трогать L2TP и не нарушать то, что в Корбине годами эксплуатировалось... :thanx:

Бабушка из Чехова? ;)

 

Сам "протоколы поймать" не поймает. Однако, к примеру, если с тем же smartbox настроить ipoe и НЕ выключать l2tp на роутере (роутер будет безуспешно пытаться его поднять) интернет через него работать будет (по ipoe). Для других роутеров хорошо бы перевести в "dynamic ip" (у всех по разному называется) с vpn/ppp/l2tp в настройках

Изменено пользователем nlpet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Bee Maya, @nlpet, роутер должен запросить веб авторизацию и в итоге заработать, но впн настроенная на роутере так и будет не успешно отправлять попытки авторизации к vpn-серверу.

Так что лучше просто роутер переключить в режим dynamic ip.

Изменено пользователем SuperDimka

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Bee Maya, @nlpet, роутер должен запросить веб авторизацию и в итоге заработать, но впн настроенная на роутере так и будет не успешно отправлять попытки авторизации к vpn-серверу.

Так что лучше просто роутер переключить в режим dinamic ip.

умоляю, dYnamic IP :rolleyes:

 

Мы проверяли роутеры, как успешно они в таком режиме работают. Всякие кинетики и смартбоксы работают нормально. А вот некоторые другие пока пытаются поднять vpn не могут работать "по ipoe" ;) так что да, им сначала надо сменить на роутере тип соединения

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@nlpet, ага, из Чехова.

У нее нет роута, один только нетбук Асус на двоих с дедом. Ну им только коммунальные услуги оплатить или там Президенту написать или в Одноклассниках пообщаться или деду в шахматы он-лайн поиграть и всё =)

Я про свой роутер Archer C7 v2 (руссифицированный) интересуюсь, который в сети Билайн ЦАО Москвы работает и раздает интернет на 5 устройств, включая настольный HP i5/win7 + 2 Планшетных + 2 Apple6 и принтер по Bluetooth. У него Динамический IP есть и кажется Статический тоже, наряду с L2TP и PPoE... Точно не знаю. Можно посмотреть только через кабель, на доступ по Wi-Fi установлен запрет, в целях рекомендованной TP-Link безопасности. Вот.

 

@SuperDimka, окей, понято, заметано! =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@nlpet, ага, из Чехова.

У нее нет роута, один только нетбук Асус на двоих с дедом. Ну им только коммунальные услуги оплатить или там Президенту написать или в Одноклассниках пообщаться или деду в шахматы он-лайн поиграть и всё =)

Ну да, в таком случае раз на шнурке авторизоваться и все, vpn поднимать не надо. Пока не сменится мак (ну или тег, по какой то причине) будет сразу прилетать по dhcp внешний

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой же у нас шлюз по умолчанию при использовании L2TP? Разве это адрес dhcp relay?

Локальный ip он получает не через L2TP. :)

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

Если он потом пытается продлить ip, полученный через WAN через другой интерфейс... (В данном случае через РРР) это интересная логика)) но для таких есть option 33

И это даже не "интересная логика", а интересная практика, реалии таковы, понимаете?

...Вот это поворот. tcpdump показал, что dhcp запросы таки идут через l2tp туннель....

Тут же подтверждение моим словам. А на главный вопрос, учитывающий мое недавнее предложение:

Подготовительный период с маленьким временем аренды, но без IPoE все-таки будет у всех, или после обката в нескольких районах впоследующем будете перенастраивать сети сразу с добавлением поддержки IPoE, как тут или в соседних темах некоторые уже предлагали?

так никто и не ответил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

и не ответят) это внутренние планы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот это поворот. tcpdump показал, что dhcp запросы таки идут через l2tp туннель.

 

Тааак.. похоже проблема все-таки не в openwrt и не в udhcpc. Внимательно смотрим, какой Server-ID нам возвращает DHCP сервер:

 

 

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:22:05.132597 00:15:6d:c7:96:5d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
   10.218.25.54.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:6d:c7:96:5d, length 300, xid 0x55c94f24, secs 18003, Flags [none] (0x0000)
         Client-IP 10.218.25.54
         Client-Ethernet-Address 00:15:6d:c7:96:5d
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Request
           MSZ Option 57, length 2: 576
           Parameter-Request Option 55, length 9: 
             Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
             Domain-Name, BR, Static-Route, NTP
             Classless-Static-Route-Microsoft
           Vendor-Class Option 60, length 12: "udhcp 1.22.1"
15:22:05.139531 1c:bd:b9:ec:7e:00 > 00:15:6d:c7:96:5d, ethertype IPv4 (0x0800), length 528: (tos 0xc0, ttl 57, id 49176, offset 0, flags [DF], proto UDP (17), length 514)
   10.4.190.156.67 > 10.218.25.54.68: [udp sum ok] BOOTP/DHCP, Reply, length 486, hops 1, xid 0x55c94f24, Flags [none] (0x0000)
         Client-IP 10.218.25.54
         Your-IP 10.218.25.54
         Gateway-IP 10.4.190.156
         Client-Ethernet-Address 00:15:6d:c7:96:5d
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: ACK
           Server-ID Option 54, length 4: 78.107.63.104
           Lease-Time Option 51, length 4: 350467
           Subnet-Mask Option 1, length 4: 255.255.248.0
           Default-Gateway Option 3, length 4: 10.218.24.1
           Domain-Name-Server Option 6, length 8: 85.21.192.3,213.234.192.8
           Domain-Name Option 15, length 7: "beeline"
           BR Option 28, length 4: 255.255.255.255
           Static-Route Option 33, length 24: (85.21.88.130:10.218.24.1),(194.67.1.115:10.218.24.1),(85.21.78.93:10.218.24.1)
           Classless-Static-Route-Microsoft Option 249, length 145: (83.102.146.96/27:10.218.24.1),(10.0.0.0/8:10.218.24.1),(78.107.23.0/24:10.218.24.1),(85.21.90.0/24:10.218.24.1),(85.21.79.0/24:10.218.24.1),(217.118.84.249/32:10.218.24
.1),(78.107.196.0/22:10.218.24.1),(217.118.84.213/32:10.218.24.1),(78.107.235.4/30:10.218.24.1),(85.21.138.208/28:10.218.24.1),(195.14.50.0/27:10.218.24.1),(78.107.52.0/26:10.218.24.1),(78.107.51.0/28:10.218.24.1),(83.102.231.32/28:10.218
.24.1),(85.21.108.16/28:10.218.24.1),(85.21.72.80/28:10.218.24.1),(233.33.210.0/24:10.218.25.54)

 

 

Ну и естественно:

 

$ ip route get 78.107.63.104
78.107.63.104 via 95.27.224.1 dev l2tp-vpn  src 95.27.231.72 
   cache

 

Хотя если бы в Server-ID был тот же айпишник, с которого пришел offer, проблем бы не было:

$ ip route get 10.4.190.156
10.4.190.156 via 10.218.24.1 dev eth0  src 10.218.25.54 
   cache

 

Вот кстати, пакетики, которые уходят в интерфейс l2tp:

 

 

tcpdump: listening on l2tp-vpn, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
15:13:33.831669 Out ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 59090, offset 0, flags [DF], proto UDP (17), length 328)
   95.27.231.72.68 > 78.107.63.104.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:6d:c7:96:5d, length 300, xid 0x55c94f24, secs 17491, Flags [none] (0x0000)
         Client-IP 10.218.25.54
         Client-Ethernet-Address 00:15:6d:c7:96:5d
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Request
           MSZ Option 57, length 2: 576
           Parameter-Request Option 55, length 9: 
             Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
             Domain-Name, BR, Static-Route, NTP
             Classless-Static-Route-Microsoft
           Vendor-Class Option 60, length 12: "udhcp 1.22.1"
15:18:06.931628 Out ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 59091, offset 0, flags [DF], proto UDP (17), length 328)
   95.27.231.72.68 > 78.107.63.104.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:6d:c7:96:5d, length 300, xid 0x55c94f24, secs 17764, Flags [none] (0x0000)
         Client-IP 10.218.25.54
         Client-Ethernet-Address 00:15:6d:c7:96:5d
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Request
           MSZ Option 57, length 2: 576
           Parameter-Request Option 55, length 9: 
             Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
             Domain-Name, BR, Static-Route, NTP
             Classless-Static-Route-Microsoft
           Vendor-Class Option 60, length 12: "udhcp 1.22.1"
15:20:23.031640 Out ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 59092, offset 0, flags [DF], proto UDP (17), length 328)
   95.27.231.72.68 > 78.107.63.104.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:6d:c7:96:5d, length 300, xid 0x55c94f24, secs 17901, Flags [none] (0x0000)
         Client-IP 10.218.25.54
         Client-Ethernet-Address 00:15:6d:c7:96:5d
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Request
           MSZ Option 57, length 2: 576
           Parameter-Request Option 55, length 9: 
             Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
             Domain-Name, BR, Static-Route, NTP
             Classless-Static-Route-Microsoft
           Vendor-Class Option 60, length 12: "udhcp 1.22.1"
15:21:31.099931 Out ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 59093, offset 0, flags [DF], proto UDP (17), length 328)
   95.27.231.72.68 > 78.107.63.104.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:6d:c7:96:5d, length 300, xid 0x55c94f24, secs 17969, Flags [none] (0x0000)
         Client-IP 10.218.25.54
         Client-Ethernet-Address 00:15:6d:c7:96:5d
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Request
           MSZ Option 57, length 2: 576
           Parameter-Request Option 55, length 9: 
             Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
             Domain-Name, BR, Static-Route, NTP
             Classless-Static-Route-Microsoft
           Vendor-Class Option 60, length 12: "udhcp 1.22.1"

 

 

Внимание, вопрос! Зачем же все так через жопу сделано?

 

Правда есть подозрение, что 10.4.190.156 - это адрес релея, а 78.107.63.104 - адрес реального DHCP сервера. Но релей разве не может/не должен переопределять option 54?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

такой странный вопрос, а как относится это к ipoe? речь ведь даже не про конфигурацию в ipoe-ready сетях, судя по тому что вы прислали :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, у меня пока не ipoe-ready сеть. Если в сетях, подготовленных для ipoe эта проблема как-то решена, то прошу прощения за оффтоп.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем доброго времени суток!

 

Являюсь счастиливым или "счастливым" пользователем тестового IPoE в Чехове.

 

Во-первых, конечно спасибо, что теперь по-человечески можно пользоваться интернетом в Linux.

 

Во-вторых же, скорость интернета упала до пяти, максимуму шести мегабит в секунду.

 

Блин, мне это критически важно, так как на такой скорости не скачаешь быстро аудио-видео материал для работы. Чё делать, даже не знаю. Попробую завтра позвонить в тех-поддержку, послушаю, что там скажут мне. Отпишусь потом здесь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@5element,а при авторизации по L2TP какова скорость?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем доброго времени суток!

 

Являюсь счастиливым или "счастливым" пользователем тестового IPoE в Чехове.

 

Во-первых, конечно спасибо, что теперь по-человечески можно пользоваться интернетом в Linux.

 

Во-вторых же, скорость интернета упала до пяти, максимуму шести мегабит в секунду.

 

Блин, мне это критически важно, так как на такой скорости не скачаешь быстро аудио-видео материал для работы. Чё делать, даже не знаю. Попробую завтра позвонить в тех-поддержку, послушаю, что там скажут мне. Отпишусь потом здесь.

чем вы замеряете скорость и через что идет подключение к инету?

Изменено пользователем Blizzak-VRX

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Во-вторых же, скорость интернета упала до пяти, максимуму шести мегабит в секунду.

 

Блин, мне это критически важно, так как на такой скорости не скачаешь быстро аудио-видео материал для работы. Чё делать, даже не знаю. Попробую завтра позвонить в тех-поддержку, послушаю, что там скажут мне. Отпишусь потом здесь.

 

Дали бы логин хоть)))

 

П.С. а попробуйте ка сейчас...есть у меня подозрение... :D

Изменено пользователем nlpet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Офигеть в Чехове уже юзают, а в Москве еще нету.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Офигеть в Чехове уже юзают, а в Москве еще нету.

Вроде все логично, проводить пилот на Москве неразумно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

и не ответят) это внутренние планы.

Таким образом, первоначально переконфигурация сегмента и одновременный ввод в эксплуатацию ipoe вам почему-то казались бредом, а теперь это уже "внутренние планы" компании? :rolleyes:

...Правда есть подозрение, что 10.4.190.156 - это адрес релея, а 78.107.63.104 - адрес реального DHCP сервера...

Все верно 10.4.190.156 - это адрес релея где-то в районе Чертановской ;) , а 78.107.63.104 - адрес DHCP сервера, он может находиться где угодно и обслуживать множество релеев.

Исходя из представленных вами данных, можно сделать однозначный вывод о том, что DHCP renewing у вас не работает, а работает DHCP rebinding. Вот здесь этот процесс подробно описан. По прошествии времени таймера T1(половины времени лизы) ваш dhcp-клиент безуспешно пытается послать юникастом через туннель к серверу 78.107.63.104 запрос(renew) на продление аренды адреса, но не получает ответа. После того как истечет время Т2, а это 87,5% времени аренды запрос(rebind) отправляется уже бродкастом. Этот бродкаст подхватывает dhcp-relay, отправляет уже юникастом ваш запрос dhcp серверу получает DHCPACK и переправляет его вам. Именно поэтому вам кажется, что подтверждение аренды происходит в самом конце временного интервала. Так и есть на самом деле. Маршрут до релея, как здесь некоторые пишут, в этом случае не играет никакой роли. Бродкаст до релея дойдет в любом случае. А вот наличие или отсутствие маршрута до dhcp сервера в некоторых случаях может играть ключевую роль. Попробуйте вручную прописать маршрут до 78.107.63.104 через 10.4.190.156, изменится ли в этом случае время, затраченное на подтверждение аренды?

P.S. Кстати у вас не такой уж плохой вариант, некоторые роутеры вообще не обновляют аренду пока не разорвут соединение.

Да, у меня пока не ipoe-ready сеть. Если в сетях, подготовленных для ipoe эта проблема как-то решена, то прошу прощения за оффтоп.

Судя по маршрутам Zam_polit в сообщении #595 этой ветки, каких-то изменений относительно вашего вопроса в ipoe-ready сетях не произошло. По большому счету большинство маршрутов необходимо лишь для переходного периода, пока не будет работать ipoe.

Изменено пользователем noox

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Таким образом, первоначально переконфигурация сегмента и одновременный ввод в эксплуатацию ipoe вам почему-то казались бредом, а теперь это уже "внутренние планы" компании? :rolleyes:

 

"Внутренние планы" это теперь потому что обсуждать это оказалось более чем бесполезно. Одно дело интересоваться, а другое раздавать на форуме бесплатные консультации смотря на процесс "извне". Рассказать я (был) не против, спорить же даже не собираюсь. Без обид. :)

Изменено пользователем nlpet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Таким образом, первоначально переконфигурация сегмента и одновременный ввод в эксплуатацию ipoe вам почему-то казались бредом, а теперь это уже "внутренние планы" компании? :rolleyes:

"Внутренние планы" это теперь потому что обсуждать это оказалось более чем бесполезно. Уж извините

, одно дело интересоваться а другое раздавать на форуме бесплатные консультации смотря на процесс "извне". Без обид.

Обсуждать где? Здесь на форуме, так вы сами это затеяли. Результат - именно такой, каким он должен быть на форуме, 99,9% никчемной информации. "Одно дело интересоваться" - а разве кто-то кого-то где-то еще спрашивал? Появилась дискуссия здесь на форуме, я увидел - ответил. Без издевок, стараясь аргументировать свои высказывания, и естественно "извне", какие еще варианты? Бесплатные консультации могу и не давать, если кому-то от этого станет легче. Без обид.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По теме IPoE.

@nlpet, не уверен, что первостепенно, но подозреваю, что заодно VPN у Корбины был создан для биллинга, с целью удобства учета внешнего трафика на лимитированных тарифах. Например таких, как Скорость+ (100 Mbps с ограничением трафика) и подобных.

Т.е. нужен интернет, клик по ярлыку и ты в глобальной паутине. Не нужен, тоже самое и ты просто в локальной сети, где трафик не учитывается, но можно легко пользоваться локальными ресурсами. Например тем же форумом Домашний Билайн. Если мои рассуждения верны, то в связи с этим 2 вопроса к вам:

1. Допустим, Билайн решит ввести линейку лимитированных тарифов, как в этом случае проявит себя IPoE, если абоненту, например, внешний интернет не нужен для входа на данный форум?

2. Допустим, на второй квартире в Москве у меня проведен кабель от Билайн, за который оплачиваю по 30 руб/мес. Смогу ли я при IPoE подключиться к своему тарифу через данный кабель, точно таким же образом, как при VPN и без проблем пользоваться внешним интернетом?

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По теме IPoE.

@nlpet, не уверен, что первостепенно, но подозреваю, что заодно VPN у Корбины был создан для биллинга, с целью удобства учета внешнего трафика на лимитированных тарифах. Например таких, как Скорость+ (100 Mbps с ограничением трафика) и подобных.

Т.е. нужен интернет, клик по ярлыку и ты в глобальной паутине. Не нужен, тоже самое и ты просто в локальной сети, где трафик не учитывается, но можно легко пользоваться локальными ресурсами. Например тем же форумом Домашний Билайн. Если мои рассуждения верны, то в связи с этим 2 вопроса к вам:

1. Допустим, Билайн решит ввести линейку лимитированных тарифов, как в этом случае проявит себя IPoE, если абоненту, например, внешний интернет не нужен для входа на данный форум?

2. Допустим, на второй квартире в Москве у меня проведен кабель от Билайн, за который оплачиваю по 30 руб/мес. Смогу ли я при IPoE подключиться к своему тарифу через данный кабель, точно таким же образом, как при VPN и без проблем пользоваться внешним интернетом?

Спасибо.

1. Это продумано. Лимитированные тарифы благо и сейчас есть (и они тоже могут "мигрировать"). И локальные ресурсы (лк, сайт билайн..) учитываться в трафике не будут. Сейчас это реализовано маршрутами через "локальную сеть", в ipoe - отдельными правилами.

2. Сможете. Одно но, при переключении в новом месте старая сессия упадет и старая связка удалится. То есть когда приедете обратно надо будет реавторизоваться.

Изменено пользователем nlpet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2. Сможете. Одно но, при переключении в новом месте старая сессия упадет и старая связка удалится. То есть когда приедете обратно надо будет реавторизоваться.
В продолжение вопроса: в новом месте другой пользователь Билайна уже авторизован, как его разавторизовать, чтобы авторизоваться под собой? Понятно, что можно MAC сменить... но может есть "нормальный" способ? Страница авторизации будет доступна по какому-то специальному URL даже авторизованным? Изменено пользователем SlavAh

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2. Сможете. Одно но, при переключении в новом месте старая сессия упадет и старая связка удалится. То есть когда приедете обратно надо будет реавторизоваться.
В продолжение вопроса: в новом месте другой пользователь Билайна уже авторизован, как его разавторизовать, чтобы авторизоваться под собой? Понятно, что можно MAC сменить... но может есть "нормальный" способ? Страница авторизации будет доступна по какому-то специальному URL даже авторизованным?

Нет, никого "деавторизовывать" не надо. На одном порту может быть авторизовано несколько клиентов разом, с разными логинами. Соответственно каждому же будут предоставляться сервисы по его договору.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Исходя из представленных вами данных, можно сделать однозначный вывод о том, что DHCP renewing у вас не работает, а работает DHCP rebinding. Вот здесь этот процесс подробно описан. По прошествии времени таймера T1(половины времени лизы) ваш dhcp-клиент безуспешно пытается послать юникастом через туннель к серверу 78.107.63.104 запрос(renew) на продление аренды адреса, но не получает ответа. После того как истечет время Т2, а это 87,5% времени аренды запрос(rebind) отправляется уже бродкастом. Этот бродкаст подхватывает dhcp-relay, отправляет уже юникастом ваш запрос dhcp серверу получает DHCPACK и переправляет его вам. Именно поэтому вам кажется, что подтверждение аренды происходит в самом конце временного интервала. Так и есть на самом деле. Маршрут до релея, как здесь некоторые пишут, в этом случае не играет никакой роли. Бродкаст до релея дойдет в любом случае. А вот наличие или отсутствие маршрута до dhcp сервера в некоторых случаях может играть ключевую роль. Попробуйте вручную прописать маршрут до 78.107.63.104 через 10.4.190.156, изменится ли в этом случае время, затраченное на подтверждение аренды?

P.S. Кстати у вас не такой уж плохой вариант, некоторые роутеры вообще не обновляют аренду пока не разорвут соединение.

Да, я в курсе всего этого. ;)

 

Не выдавал и не выдается. Выдается маршрут к dhcp relay, по опции 33.

 

Если по option 33 DHCP сервер действительно отдает маршрут до релея, то этот маршрут совершенно бесполезен.

 

Если он потом пытается продлить ip, полученный через WAN через другой интерфейс... (В данном случае через РРР) это интересная логика)) но для таких есть option 33

 

А unicast может работать как-то еще? На каком интерфейсе есть маршрут, с такого пакет и уходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.