[РЕШЕНО] Beeline/IPoE: IP-static - разрыв соединения

Приветствую всех.
Оператор моб. связи Beeline предоставляет сдвоенный пакет услуг "моб. связь и домашний интернет". Цена показалась привлекательной. Подключился.
С сетью имеются варианты: L2tp или IPoE
Выбрал IPoE + статический IP - все работает без проблем по dhcp.
При активации интернет-соединения для выхода из локальной сети "наружу" используется единоразовая авторизация на сайте Билайна, далее следует регистрация и привязка компа по mac-адресу и все, поехали.

Проблема начинается когда пытаюсь, используя параметры выдаваемые провом через dhcp, запустить сеть используя статическую конфигурацию, т.е. не используя (в моем случае) dhcpcd. Да, в обоих случаях все делаю через netctl, в кач-ве шаблонов используя примеры из netctl/examples/internet-{dhcp, static, custom}
Теперь собственно конфиги:
/etc/netctl/beeline-dhcp
Description='A basic dhcp ethernet connection'
Interface=eth0
Connection=ethernet
IP=dhcp
#Address=('')
#Gateway='83.102.255.56'
DNS=('85.21.192.5' '213.234.192.7')
DHCPClient=dhcpcd
#DHCPReleaseOnStop=no
и получаю следующее ('lo' опускаю) :
~$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:1d:7d:d0:d8:b9 brd ff:ff:ff:ff:ff:ff
    altname enp4s0
    inet 89.179.127.228/29 brd 89.179.127.231 scope global dynamic noprefixroute eth0
       valid_lft 526sec preferred_lft 451sec
    inet6 fe80::21d:7dff:fed0:d8b9/64 scope link
       valid_lft forever preferred_lft forever

~$ ip route
default via 89.179.127.225 dev eth0 proto dhcp src 89.179.127.228 metric 1002
89.179.127.224/29 dev eth0 proto dhcp scope link src 89.179.127.228 metric 1002

Конфиг для статики, /etc/netctl/beeline-static
Description='A basic static ethernet connection'
Interface=eth0
Connection=ethernet
IP=static
#Address=('89.179.127.228/29')
#Routes=('89.179.127.231')
#Gateway='89.179.127.225'
IPCustom=('addr add dev eth0 89.179.127.228/29 brd +' 'route add default via 89.179.127.225')
DNS=('85.21.192.5' '213.234.192.7')
Пробовал еще такую конфигурацию (без IPCustom)
Interface=eth0
Connection=ethernet
IP=static
Address=('89.179.127.228/29')
Routes=('89.179.127.231')
Gateway='89.179.127.225'
DNS=('85.21.192.5' '213.234.192.7')
В итоге, что так, что эдак - те же яйца только в профиль, а именно: если сначала запустить конфиг beeline-dhcp (netctl start beeline-dhcp - тут проблем нет, все работает), затем остановить и сразу после него стартануть beeline-static - сеть поднимается, но через несколько минут отваливается. Сам service не крашится, нет. Выхлопы ip addr и ip route тоже не меняются относительно полученных при работающем соединении, но соединение рвется. Если стартовать netctl start beeline-static, так сказать, с нуля, то соединение не устанавливается, при этом ip addr выдает то же, что и при работающем соединении, но по ip route пусто. netctl status beeline-static выдает FAIL прт "невозможности назначить default route для 89.179.127.228/29" (как-то так, если что, могу привести точный выхлоп)

Что в данном случае при работающем 'beeline-static' имею по ip addr & ip route:
~$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1d:7d:d0:d8:b9 brd ff:ff:ff:ff:ff:ff
altname enp4s0
inet 89.179.127.228/29 brd 89.179.127.231 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::21d:7dff:fed0:d8b9/64 scope link
   valid_lft forever preferred_lft forever

~$ ip route
default via 89.179.127.225 dev eth0
89.179.127.224/29 dev eth0 proto kernel scope link src 89.179.127.228
89.179.127.231 dev eth0 scope link
Что пока вижу: в первом случае (beeline-dhcp) eth0 идет с 'metric 1002', в случае beeline-static - нет.

Еще, на всякий случай, конфиг dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
#hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent

# vendorclassid is set to blank to avoid sending the default of
# dhcpcd-<version>:<os>:<machine>:<platform>
vendorclassid dhcpcd:linux

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Request a hostname from the network
option host_name

# Most distributions have NTP support.
#option ntp_servers

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
#slaac private
#noipv4ll

Вопрос: как собственно получить стабильное соединение, используя статическую конфигурацию и при этом не прибегая к dhcp? Ведь в том и другом случае я получаю все тот-же IP-static.
Пока несколько плаваю в вопросе, давно уже не занимался подобными задачами, многое пришлось поднимать заново...
Буду благодарен за помощь.
Да, еще: с техподдержкой билайна разговаривать безполезно, там мало того, что из десяти лишь один хоть что-то может сказать по делу и не известно на кого выведет, так и сам дозвон тот еще квест.
Сколько лет, сколько зим!! Рад видеть. :)
Тепрь по сути.
bobart
Проблема начинается когда пытаюсь, используя параметры выдаваемые провом через dhcp, запустить сеть используя статическую конфигурацию,
статический адрес для прова означает, что он резервирует этот адрес за тобой. Для тебя, как клиента, это означает, что ты продолжаешь пользоваться dhcp, но сервер будет для тебя всегда выдавать один и тот же ip-шник. Если, конечно, провом не указано что-то другое. Поэтому все твои телодвижения со статиткой - трата времени и потенциальные проблемы в будущем..

Что касается самой проблемы, то тут, как мне кажется, в конфиге зря указан параметр Routes=. Т.е. указываешь только адрес, маршрут и ДНС. Остальное система сама вычислит. Но могу и ошибаться.
Я тоже. Взаимно:)
По сути. Думаю, ты прав: стат.ip резервируется и затем выдается провом по dhcp. Почему нельзя иначе - пока не понимаю. В тонкостях маршрутизации не силен (нет задач - нет знаний), но чую, что по dhcp там по ходу дела происходит толи перенаправление для замены дефолтного шлюза для eth0, толи еще что-то чего я не понимаю. Была бы адекватная техподдержка - трепал бы им нервы. А так... только так, на форум.
Один из относительно адекватных, что мне попался при решении проблем с первичным подключением (были, как без этого с билайном;) на мой вопрос будет ли работать без dhcp (пример - мои настройки для ip-static на Tiera - это мой второй актуальный провайдер), если в конфиге прописать статические адреса, ответил: "ну, думаю, должно".
Ну и ...началась моя канитель с попыткой подружить ежа с ужом.

PS. Касательно необязательности Routes= - да, на Тиере все работает без указания Routes: только Address, Gateway и DNS

В любом случае, спасибо.
[Решено] пока не ставлю, вдруг кто-то еще откликнется. Подожду.
bobart
Почему нельзя иначе - пока не понимаю.
у прова DHCP-сервер работает в любом случае. Он обслуживает других клиентов. Никто не будет ради каждого абонента поднимать отдельный сервер. Плюс для самого клиента, при таком подходе, меньше проблем - денюжку заплатил, получил статику, не заплатил - получай адреса из общего пула. Минимум телодвижений и для прова и для клиента. А кто хочет больше - у того и знаний по-больше. :)

Что касается Routes, насколько я понял, то это параметр высчитывается системой из 89.179.127.228/29. Поэтому и написал, что вводить его не надо. Тем более, что твое подключение, по сути, обычная локалка. Настроек и параметров минимум.

Сейчас в голову пришла мысля. У тебя для выхода в инет используется авторизация через браузер. Ты заходишь на страничку, авторизуешься и пров запоминает мак-адрес и дальше работает с тем клиентом, который этим мак-адресом "маякнет" из сети на этапе запроса настроек (dhcp). Так вот, может быть поскольку ты пытаешься подключиться статикой, то не происходит передачи мак-адреса (или оборудование прова не хочет его видеть). Поэтому в консоли ты видишь правильные настройки, а инета нет.
Кстати, ради интереса можешь пингануть шлюз (89.179.127.225) и затем кого-нибудь во внешке. Может поймешь где затык.
vadik
…пров запоминает мак-адрес и дальше работает с тем клиентом, который этим мак-адресом "маякнет" из сети на этапе запроса настроек (dhcp).
Да, как-то так. Я к тому и привел dhcpcd.conf в котором параметр "clientid" как раз об этом, насколько я понимаю. Вопрос можно было бы сузить до "как маякнуть прову, минуя dhcp?" - возможно, никак. Точнее сказать, не знаю.
Регулярно сигналить мак-адресом скорее всего требуется: при смене железа снова будет нужна авторизация для привязки к другому железу.

В общем, вопрос снимаю.
Мак так и так должен передаваться каждый раз. Просто оборудование прова может его не ждать в тот момент, когда ты его отправляешь.
И мне кажется, проще один раз роутер поставить и забыть.
Роутер в моем случае, как мне представляется, просто лишняя прокладка. Хотя да, "поставил и забыл".
Роутер, помимо удобства использования имеет еще одну важную функцию - защищает сетевую карту компа от внешних воздействий (постороннее напряжение, вода и т.д.). Не на 100% конечно, но лучше чем прямое включение. Особенно если роутер имеет отдельную микросхему для WAN-порта. Если микросхема общая для LAN/WAN, то с защитой от напряжения уже не все так однозначно. Плюс, при использовании роутера по умолчанию включен NAT, это значит что твой комп получает дополнительную защиту от взлома. Тем более, что статический IP помогает злоумышленникам тебя отслеживать.
Вот я нагнал жути... :)
vadik
Вот я нагнал жути… :)
Да..., можешь;)
По части защиты железа ты прав, наверное. А вдруг потоп... Дело такое, да.
Насчет спрятаться за NAT... Вот, честно, хз. Могут быть затыки с p2p. Разруливаются, конечно - только к чему дополнительный головняк...? Со статикой подобных проблем нет. Что до безопасности - iptables на что тогда? ;)
PS. Мне тут, чую, впору новую тему поднимать, отдельно. Что-то комп стал грузиться долго. Почитал соответствующий топик (где-то на форуме), там вроде так ни к чему и не пришли в итоге. Причем, симптомы схожие: затык на уровне запуска граф. окружения. Началось не так давно, кстати. Вот, пока не знаю куда тыкаться. Надо еще почитать на эту тему.
Это так, в качестве лирического отступления.)
 
Зарегистрироваться или войдите чтобы оставить сообщение.