vop

Ну есть еще и другие юниксы, в которых нетучки iproute2. Поэтому знать про них не мешает. Что бы стопора не получилось у линуксоида, когда его попросят помочь во фре :)

Они, как бы, оба правильные - первый iproute2, второй - классической утилитой. Просто в "правильном" руководстве надо так и написать - можно так, а можно эдак. :) А то потом появляются гениальные спецы, которые до срачки начинают доказывать глупости. :)

Я отказался от opennhrp в свое время, так-как он хотел в то время патченого ядра, а мне надо было делать на дистрибутивных. Сейчас не знаю. У меня есть небольшая, порядка 30 узлов. Поэтому у меня два узла выполняют роль хабов. При этом там ведется база в виде списка, которая просто при обновлении рассылается по нодам, где лежат скрипты, обновляющие ip ne список. Обновления рассылаются моими программными средствами, в которые встроены инструменты отслеживания обновления. Но это вообще не принципиально, можно обычным curl'ом дергать регулярно - трафик мизерный. Ну и да, маску бы поставить. А качестве ключа я использую network виртуальной сети - так не надо "запоминать" его значение, и оно выставляется "автоматически" (у меня скрипт сам "выдергивает" его). ipv6 вообще выставляются просто по isatap. Там достаточно lladdr. Если у вас сеть небольшая, то NHRP может подождать до лучших времен.

Вы имеете ввиду, что в линуксе RBR? :) Можно еще раскидать рулесы по namespace'м, в каждом из которых по 256 правил и таблиц. :)

По ссылке то пишем так: ip route add 192.168.7.0/24 via 192.168.1.1 то сяк: route add -net 192.168.7.0 netmask 255.255.255.0 gw 192.168.1.1 При этом первый обозван временным статик-роутом, второй - постоянным... А хотел сказать, что такие "руководства" хреновые.

Что-то в одном месте мешанина route with ip route :)

Надо... Но, все же, с железом возиться не надо. :) Присоединяюсь к рекомендации. Если PHP мешает, надо от него избавиться.:) :) :)

Я прекрасно понимаю, что реальных результатов вряд ли получится. Очень похожую тему когда-то я поднимал на киоске по поводу протоколов терминальных платежных сетей, когда каждая из них фигачила свои собственные API которые выполняли одни и те же функции, и были совсем не совместимы друг с другом. При этом, у каждого - куча технологических недочетов. Максимум, что появилось, несколько сетей взяли за основу протокол осмп, но обязательно, что-то впихнули свое... Не, ну мне, как скромному разработчику от этого хорошо - под каждую платежную систему лепим отдельный плагин, зарабатываем дополнительную денежку. Хотя, немного обидно тратить время на создание очередного велосипеда. Есть принципиальное отличие. Сертифицированный биллинг - это разработка продукта, который, к тому же, требует заметных затрат. У меня речь идет о согласовании протокола. Как альтер-пример - RFC. Сели, договорились, как будут работать, и вперед. А многие даже и не догадываются, что RFC являются стандартами исключительно формально. Но все, по мере возможности, их придерживаются. Унифицированный API к профайлу клиента не только, и даже не столько даст возможность независимым программерам делать какие-то свои "странички абонента", сколько даст возможность встраивать плагины доступа к такой информации со стороны отдельного софта... Например, для "домашней бухгалтерии". Ну да ладно, будет желание и вдохновение, один фиг к этому придем.   Открытые API полезны не столько для "своего оригинального приложения", сколько для встраивания API в интегральные решения и продукты.

Вы привели пример просмотра фильмов - т.е. выполнение однотипной задачи для объектов разных производителей (говоря образно). Для просмотра каждого отдельного фильма сейчас не надо устанавливать отдельной программы (как бывало в прежние времена), и в большинстве случаев не надо вообще устанавливать отдельный софт. Просмотр состояния своей провайдерской подписки - задача не менее однотипная для разных операторов - интернета, кабельного тв, телефона, да и коммунального предприятия. Это все однотипные задачи. Но каждый пытается решать их самостоятельно, отдавая клиенту свой проприетарный пользовательский интерфейс. И да, я нигде не писал, что одним HTTP стали решаться все задачи. Я написал, что была по сути, предотвращена проблема заваливания компьютера софтом, так-как огромное количество задач перешло в область http. Ну и последнее. В настоящее время почти каждый клик в сети приводит к рекомендации поставить свою аппликуху на телефон (которую я, кстати, программой и не называл, ибо не об этом пишу :) ) Поэтому уже сейчас огромное количество предлагаемых аппликух людьми уже игнорируются. Под лозунгом - да нахрен мне еще одна? Поэтому еще раз обозначу главный тезис - потихоньку наступает время создания унифицированного и - подчеркну - открытого API клиентского интерфейса.

Проблема завала телефона аппликухами очень похожа на проблему роста количества софта для PC в 90-х годах. Проблема состоит в том, что на каждый чих писалась своя собственная программа, ибо других подходов не было. И через некоторое время на компьютере просто "заканчивалось место". Я даже не вспоминаю о проблема "обновления софта", точнее, этой огромной кучи софта. Для PC проблема решилась появлением http. Подавляющая часть задач была перенесена на серверную сторону, а у клиента отпала необходимость что-то устанавливать дополнительное у себя на компьютере. Интересно, когда подобного рода решение появится для смартфонов, и в сети исчезнут все эти призывы установить app на каждой странице? PS Для нужд провайдинга в свое время появлялись разного рода "балансеры" (программы, показывающие состояние лицевого счета у разных ваших провайдеров). К сожалению, тема особо развития не получила, балансеры отличались всего-лишь показом остатка на счету + пару параметров, других информационных или управляющих функций там не появлялось. Очень жаль. Вместо того, что бы производителям софта договориться и прийти к унифицированному "стыку" по данным абонента, каждый пытается самостоятельно делать свой продукт, считая это неким "конкурентным преимуществом".

Я думаю, любой, не сильно стандартный тоннель покатит. Я для поездок из любой дыры использую ppp over ssh :)

Для авторизации по сертификатам используется самостоятельная пара сертификатов.

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

Пугаете тоже... :)

Ого! Чётт я даже не подумал то таком сексе. :)