Вопросы Теги

Linux: Как я вынуждаю определенный сетевой интерфейс использоваться?

Попробуйте добавить несколько операторов return, где вы хотите прекратить выполнение, например, 

const errorStatusCodeAndResponseMeetupLoggedInUser = (req, res, error) => {     
    //Updaing the same in firebase
    if (req.user["meetup"] !== "warning") {
        /*here*/return FirebaseHelper.updateDataInDb("users", req.user.email, {"meetup": "warning"})
        .then(() => {
            res.status(error.response.status)
            req.user["meetup"] = "warning"
            /* here: */return res.send(error.response.data.problem)
        })
        .catch(error => { 
            /* here */ return ErrorWithDatabse(req,res,error) 
        })
    } else {
        res.status(error.response.status)
        /* here */return res.send(error.response.data.problem)
    }
}

То же самое для этого 

const ErrorWithDatabse = (req, res, error) => {
    res.status(500)
    /*here*/return res.send("Probalem Storing Value in Database")
}
18
задан 2 revs 23 May 2017 в 11:59
поделиться

3 ответа

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

существует sysctl, названный сетью ipv4.conf.all.rp_filter, которая может быть установлена на 0 отключить исходную проверку: 

    rp_filter - INTEGER
         2 - do source validation by reversed path, as specified in RFC1812
             Recommended option for single homed hosts and stub network
             routers. Could cause troubles for complicated (not loop free)
             networks running a slow unreliable protocol (sort of RIP),
             or using static routes.

         1 - (DEFAULT) Weaker form of RP filtering: drop all the packets
             that look as sourced at a directly connected interface, but
             were input from another interface.

         0 - No source validation.

Это может также быть установлено на на интерфейсное основание с помощью/proc/sys/net/ipv4/conf / <interface>/rp_filter.

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

Широковещательные сообщения все еще проблематичны по причинам, которые я не понимаю, но я наконец удовлетворен этой проблемой, и я надеюсь, что она помогает другим.

3
ответ дан 30 November 2019 в 09:30
поделиться

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

мне лично нравится идея создать модуль ядра рычага сетевого стека, который позволит мне делать это. Таким образом, я имею полный контроль над многоадресной передачей и цельнолитым движением кадров и прибытием из пространства пользователя. Необходимо было бы использовать что-то как сокеты netlink для отправления/получения данных в и от драйвера и приложения пространства пользователя, но это работает очень хорошо и очень быстро.

Вы также добираетесь для сцепления на любой уровень стека этого пути... Ethernet или IP. Таким образом имея полный контроль над тем, что Вы отправляете/получаете.

Вот пример статья , которая говорит о сцеплении в стопку netfilter.
Примечание: эта статья сцепляется в стек IP, и это также старо. Я знаю, что API изменились, но много этой статьи все еще применяется практически и теоретически. Если бы Вы хотели сцепиться на образующий мост слой, то Вы использовали бы подобный механизм, но указали бы 

BR_LOCAL_IN instead of NF_IP_LOCAL_IN

Примечание: Это очень похоже на открытие неструктурированного сокета в интерфейсе. Необходимо будет создать кадры сами.

2
ответ дан 30 November 2019 в 09:30
поделиться

Что касается моего общего вопроса, кажется, существует несколько способов сделать это:

  • сложный путь, который включает изменения в таблице маршрутизации и сотрудничество от каждого процесса. Это - способ, которым я описал выше. Одно преимущество это имеет его, это работает от пространства пользователя. Я поместил некоторые дополнительные примечания по нему и ответил на мои конкретные вопросы ниже.

  • Запись пользовательская модель ядра, которая игнорирует таблицу маршрутизации полностью, если SO_BINDTODEVICE установлен. Клиентский процесс все еще требуется, чтобы звонить setsockopt(SOL_SOCKET, SO_BINDTODEVICE, dev), как бы то ни было. Эта опция определенно не для слабонервных.

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

Опции 1 и 2 требуют, чтобы процессы подписались для работы, поскольку мы хотели бы их к. Это может быть частично облегчено путем создания динамической библиотеки, которая угоняет сокет (), звонят, чтобы создать сокет и затем сразу связать его с устройством прежде, чем возвратить дескриптор. Это описано более подробно здесь .

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

  1. SO_BINDTODEVICE действительно делает то, что это говорит, по крайней мере, для UDP.

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

  3. Для получения широковещательных сообщений в определенном интерфейсе свяжите с устройством сначала с помощью SO_BINDTODEVICE и затем свяжите с широковещательным адресом с обычным, связывают () вызов. Привязка устройства должна быть сделана перед чем-либо еще. Затем сокет получит только широковещательные сообщения, которые прибывают в тот интерфейс.

я протестировал его первым созданием сокета. Затем я связал его с определенным интерфейсом с помощью setsockopt(SOL_SOCKET, SO_BINDTODEVICE, dev). Наконец, я связал его с широковещательным адресом. От другого компьютера я отправил широковещательную передачу, которая будет получена через несвязанный интерфейс. Ограниченный устройством сокет не получил эту широковещательную передачу, которая имеет смысл. Удалите эти setsockopt(SOL_SOCKET, SO_BINDTODEVICE, dev), вызов и широковещательная передача будут получены.

нужно также упомянуть, что можно использовать setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) здесь также. Обратите внимание что семантика SO_REUSEADDR изменение с широковещательными адресами. А именно, законно иметь два сокета, связанные с широковещательным адресом и тем же портом на той же машине, если они оба имеют SO_REUSEADDR набор.

ОБНОВЛЕНИЕ: SO_BINDTODEVICE с широковещательными сообщениями, кажется, чреват опасностью, а именно, приемом широковещательных кадров. Я наблюдал широковещательные кадры, полученные относительно одного интерфейса, но исчезал на другом одновременно. Кажется, что они произведены локальной таблицей маршрутизации, но неуязвимы для правил политики IP. Однако я не на 100% уверен в этом и только упоминаю это как точку расследования, если Вы хотите продолжить его. Все это для высказывания: используйте на Ваш собственный риск. В интересах времени я открыл неструктурированный сокет в интерфейсе и проанализировал Ethernet и заголовки IP сам.

4
ответ дан 30 November 2019 в 09:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: