Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Gremlin92


  • Вопрос задан

    22 дек. 2021

проброс порта осуществляется wan>>>lan не наоборот

Правильно пишет, т.к. адрес 192.168.0.0 не является подсетью этого роутера

25 окт. 2022, в 21:46

1500 руб./за проект

25 окт. 2022, в 21:30

10000 руб./за проект

25 окт. 2022, в 21:27

3000 руб./за проект

Минуточку внимания

 network, tplink, tp-link, сетевое оборудование

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Покажи скриншот настроек на которые ругается

Kolins (22.12.21 13:41:15)

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Живет у меня 10-й год TP-Link tl-wr841nd v8.1 с последней (14-го года) прошивкой. Но, вчера, после грозы, у меня пропал интернет. Пропал он у всех абонентов Билайна, что мне подтвердил робот, назвав дату окончания работ. Также в админке роутера я наблюдал нули в качестве динамически выдаваемого мне ip, хотя индикатор коннекта LAN горел, да все горело как обычно. Я ждал.

Сегодня к обеду я обратил внимание, что робот билайна перестал кормить меня сроками окончания работ и начал предлагать чего-нибудь купить. А интернета у меня так и не появилось. Я начал волноваться и звонить. Добравшись через особенно умную девочку до техника я выяснил, что по моему адресу уже все починено и работает. Но интернета у меня так и не было, а нули в ip’шнике роутера – были. После чего мы с ним выяснили: что интернет таки есть, если провод воткнуть в ПК, а также меня все же видно в билайновской сети, если подключаться через роутер. Более того, ip’шник мне DHCP сервер выдает и отправляет, но мой роутер этого не понимает и каждые 2 минуты рвет сессию. Техник заверил меня, что видит моих соседей по дому, и у них такой проблемы нет.

Мне посоветовали hard reset TP-Link’а. Он не помог. Я также пробовал downgrade прошивки и обратно – не помогло.
Моя версия была в том, что под шум ремонтных работ билайн еще что-то проапдейтил и сломал совместимость с моим роутером. Но доказать это невозможно – т.к. штатная прошивка диагностировать толком ничего не дает. И я решил, что настало время попробовать OpenWRT.

# ifstatus vpn
{
        "up": false,
        "pending": true,
        "available": true,
        "autostart": true,
        "proto": "l2tp",
        "data": {

        }
}

и через logread видно

Wed Sep  9 06:40:30 2015 daemon.notice netifd: Interface 'vpn' is setting up now
Wed Sep  9 06:40:30 2015 daemon.notice netifd: vpn (5636): Could not resolve server address
Wed Sep  9 06:40:36 2015 daemon.debug xl2tpd[875]: No such tunnel 'l2tp-vpn'
Wed Sep  9 06:40:36 2015 daemon.notice netifd: vpn (5706): 01 No such tunnel 'l2tp-vpn'
Wed Sep  9 06:40:36 2015 daemon.debug xl2tpd[875]: No such tunnel 'l2tp-vpn'
Wed Sep  9 06:40:36 2015 daemon.notice netifd: vpn (5706): 01 No such tunnel 'l2tp-vpn'
Wed Sep  9 06:40:36 2015 daemon.notice netifd: Interface 'vpn' is now down

Я сделал ping tp.internet.beeline.ru с ПК, и прописал его ip’шник напрямую. Через это получил в логах то же самое, но без Could not resolve server address. А в статусе еще хуже:

# ifstatus vpn
{
        "up": false,
        "pending": false,
        "available": false,
        "autostart": true,
        "proto": "l2tp",
        "data": {

        }
}

А после ifup vpn даже

# ifstatus vpn
{
        "up": false,
        "pending": false,
        "available": false,
        "autostart": true,
        "proto": "l2tp",
        "data": {

        },
        "errors": [
                {
                        "subsystem": "interface",
                        "code": "NO_DEVICE"
                }
        ]
}

Собственно в чем вопрос: что я делаю не так с OpenWRT (куда копать?) или у меня действительно так экзотически избирательно сдох TP-Link на уровне железа? Как в этом убедиться?

Пишите нам!
Архитектурная мастерская.
Продвижение сайтов от optimism.ru

Page generation time: 0.0833s (PHP: 62% – SQL: 38%) – SQL queries: 39 – GZIP disabled – Debug off

Пишите нам!
Архитектурная мастерская.
Продвижение сайтов от optimism.ru

Page generation time: 0.0624s (PHP: 67% – SQL: 33%) – SQL queries: 39 – GZIP disabled – Debug off

Доброго времени суток, уважаемые читатели Хабра!

Не так давно я написал свою первую статью на Хабр. В моей статье была одна неприятная шероховатость, которую моментально обнаружили, понимающие в сетевом администрировании, пользователи. Шероховатость заключается в том, что я указал неверные IP адреса в лабораторной работе. Сделал это я умышленно, так как посчитал что неопытному пользователю будет легче понять тему VLAN на более простом примере IP, но, как было, совершенно справедливо, замечено пользователями, нельзя выкладывать материал с ключевой ошибкой.

В самой статье я не стал править эту ошибку, так как убрав её будет бессмысленна вся наша дискуссия в 2 дня, но решил исправить её в отдельной статье с указание проблем и пояснением всей темы.

Для начала, стоит сказать о том, что такое IP адрес.

Максимальным возможным числом в любом октете будет 255 (так как в двоичной системе это 8 единиц), а минимальным – .

Далее давайте разберёмся с тем, что называется классом IP (именно в этом моменте в лабораторной работе была неточность).

Класс А: 1.0.0.0 — 126.0.0.0, маска 255.0.0.0
Класс В: 128.0.0.0 — 191.255.0.0, маска 255.255.0.0
Класс С: 192.0.0.0 — 223.255.255.0, маска 255.255.255.0
Класс D: 224.0.0.0 — 239.255.255.255, маска 255.255.255.255
Класс Е: 240.0.0.0 — 247.255.255.255, маска 255.255.255.255

Теперь о «цвете» IP. IP бывают белые и серые (или публичные и частные). Публичным IP адресом называется IP адрес, который используется для выхода в Интернет. Адреса, используемые в локальных сетях, относят к частным. Частные IP не маршрутизируются в Интернете.

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

Допустим, Вы молодой сетевой инженер и хотите дать доступ к своему серверу всем пользователям Интернета. Для этого Вам нужно получить публичный IP адрес. Чтобы его получить Вы обращаетесь к своему интернет провайдеру, и он выдаёт Вам публичный IP адрес, но из рукава он его взять не может, поэтому он обращается к локальному Интернет регистратору (LIR – Local Internet Registry), который выдаёт пачку IP адресов Вашему провайдеру, а провайдер из этой пачки выдаёт Вам один адрес. Локальный Интернет регистратор не может выдать пачку адресов из неоткуда, поэтому он обращается к региональному Интернет регистратору (RIR – Regional Internet Registry). В свою очередь региональный Интернет регистратор обращается к международной некоммерческой организации IANA (Internet Assigned Numbers Authority). Контролирует действие организации IANA компания ICANN (Internet Corporation for Assigned Names and Numbers). Такой сложный процесс необходим для того, чтобы не было путаницы в публичных IP адресах.

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Поскольку мы занимаемся созданием локальных вычислительных сетей (LAN — Local Area Network), мы будем пользоваться именно частными IP адресами. Для работы с ними необходимо понимать какие адреса частные, а какие нет. В таблице ниже приведены частные IP адреса, которыми мы и будем пользоваться при построении сетей.

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Из вышесказанного делаем вывод, что пользоваться при создании локальной сеть следует адресами из диапазона в таблице. При использовании любых других адресов сетей, как например, 20.*.*.* или 30.*.*.* (для примера взял именно эти адреса, так как они использовались в лабе), будут большие проблемы с настройкой реальной сети.

У всех IP адресов есть две части сеть и узел.
Сеть – это та часть IP, которая не меняется во всей сети и все адреса устройств начинаются именно с номера сети.
Узел – это изменяющаяся часть IP. Каждое устройство имеет свой уникальный адрес в сети, он называется узлом.

Маску принято записывать двумя способами: префиксным и десятичным. Например, маска частной подсети A выглядит в десятичной записи как 255.0.0.0, но не всегда удобно пользоваться десятичной записью при составлении схемы сети. Легче записать маску как префикс, то есть /8.

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

Таблица масок подсети

Код ошибки 26106 подсеть ip адреса отличается от подсети ip адреса lan

Высчитаем сколько устройств (в IP адресах — узлов) может быть в сети, где у одного компьютера адрес 172.16.13.98 /24.

172.16.13.0 – адрес сети
172.16.13.1 – адрес первого устройства в сети
172.16.13.254 – адрес последнего устройства в сети
172.16.13.255 – широковещательный IP адрес
172.16.14.0 – адрес следующей сети

Итого 254 устройства в сети

Теперь вычислим сколько устройств может быть в сети, где у одного компьютера адрес 172.16.13.98 /16.

172.16.0.0 – адрес сети
172.16.0.1 – адрес первого устройства в сети
172.16.255.254 – адрес последнего устройства в сети
172.16.255.255 – широковещательный IP адрес
172.17.0.0 – адрес следующей сети

Итого 65534 устройства в сети

В первом случае у нас получилось 254 устройства, во втором 65534, а мы заменили только номер маски.

Посмотреть различные варианты работы с масками вы можете в любом калькуляторе IP. Я рекомендую этот.

До того, как была придумана технология масок подсетей (VLSM – Variable Langhe Subnet Mask), использовались классовые сети, о которых мы говорили ранее.

Теперь стоит сказать о таких IP адресах, которые задействованы под определённые нужды.

Адрес 127.0.0.0 – 127.255.255.255 (loopback – петля на себя). Данная сеть нужна для диагностики.
169.254.0.0 – 169.254.255.255 (APIPA – Automatic Private IP Addressing). Механизм «придумывания» IP адреса. Служба APIPA генерирует IP адреса для начала работы с сетью.

Теперь, когда я объяснил тему IP, становиться ясно почему сеть, представленная в лабе, не будет работать без проблем. Этого стоит избежать, поэтому исправьте ошибки исходя из информации в этой статье.

Ссылка на лабу

Чуточку ликбеза. Навеяно предшествующими копипастами разной чепухи на данную тему. Уж простите, носинг персонал.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
232 = 210*210*210*22 = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

Но может быть маска

Сначала N единиц, потом 32-N нулей. Несложно догадаться, что такая форма записи является избыточной. Вполне достаточно числа N, называемого длиной маски. Так и делают: пишут 192.168.11.10/21 вместо 192.168.11.10 255.255.248.0. Обе формы несут один и тот же смысл, но первая заметно удобнее.

11000000.10101000.00001011.00001010
11111111.11111111.11111000.00000000
----------------------------------------------
11000000.10101000.00001000.00000000 = 192.168.8.0

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

Адрес 192.168.8.0, со всеми обнуленными битами на позициях, соответствующих нулям в маске, называется адресом подсети. Его (обычно) нельзя использовать в качестве адреса для интерфейса того или иного хоста. Если же эти биты наоборот, установить в единицы, то получится адрес 192.168.15.255. Этот адрес называется направленным бродкастом (широковещательным) для данной сети. Смысл его по нынешним временам весьма невелик: когда-то было поверье, что все хосты в подсети должны на него откликаться, но это было давно и неправда. Тем не менее этот адрес также нельзя (обычно) использовать в качестве адреса хоста. Итого два адреса в каждой подсети — на помойку. Все остальные адреса в диапазоне от 192.168.8.1 до 192.168.15.254 включительно являются полноправными адресами хостов внутри подсети 192.168.8.0/21, их можно использовать для назначения на компьютерах.

Таким образом, та часть адреса, которой соответствуют единицы в маске, является адресом (идентификатором) подсети. Ее еще часто называют словом префикс. А часть, которой соответствуют нули в маске, — идентификатором хоста внутри подсети. Адрес подсети в виде 192.168.8.0/21 или 192.168.8.0 255.255.248.0 можно встретить довольно часто. Именно префиксами оперируют маршрутизаторы, прокладывая маршруты передачи трафика по сети. Про местонахождение хостов внутри подсетей знает только шлюз по умолчанию данной подсети (посредством той или иной технологии канального уровня), но не транзитные маршрутизаторы. А вот адрес хоста в отрыве от подсети не употребляется совсем.

Обстоятельство третье. Количество хостов в подсети определяется как 232-N-2, где N — длина маски. Чем длиннее маска, тем меньше в ней хостов.

Из данного обстоятельства в частности следует, что максимальной длиной маски для подсети с хостами является N=30. Именно сети /30 чаще всего используются для адресации на point-to-point-линках между маршрутизаторами.

И хотя большинство современных маршрутизаторов отлично работают и с масками /31, используя адрес подсети (нуль в однобитовой хоствой части) и бродкаст (единица) в качестве адресов интерфейсов, администраторы и сетевые инженеры часто попросту боятся такого подхода, предпочитая руководствоваться принципом «мало ли что».

А вот маска /32 используется достаточно часто. Во-первых, для всяких служебных надобностей при адресации т. н. loopback-интерфейсов, во-вторых, от криворукости: /32 — это подсеть, состоящая из одного хоста, то есть никакая и не сеть, в сущности. Чем чаще администратор сети оперирует не с группами хостов, а с индивидуальными машинами, тем менее сеть масштабируема, тем больше в ней соплей, бардака и никому непонятных правил. Исключением, пожалуй, является написание файрвольных правил для серверов, где специфичность — хорошее дело. А вот с пользователями лучше обращаться не индивидуально, а скопом, целыми подсетями, иначе сеть быстро станет неуправляемой.

Прежде чем посылать IP-пакет, компьютер определяет, попадает ли адрес назначения в «свою» подсеть. Если попадает, то шлет пакет «напрямую», если же нет — отсылает его шлюзу по умолчанию (маршрутизатору). Как правило, хотя это вовсе необязательно, шлюзу по умолчанию назначают первый адрес хоста в подсети: в нашем случае 192.168.8.1 — для красоты.

Обстоятельство четвертое. Из сказанного в частности следует, что маршрутизатор (шлюз и маршрутизатор — это одно и то же) с адресом интерфейса 192.168.8.1 ничего не знает о трафике, передаваемом между, например, хостами 192.168.8.5 и 192.168.8.7. Очень частой ошибкой начинающих администраторов является желание заблокировать или как-то еще контролировать с помощью шлюза трафик между хостами в рамках одной подсети. Чтобы трафик проходил через маршрутизатор, адресат и отправитель должны находиться в разных подсетях.

Таким образом в сети (даже самого маленького предприятия) обычно должно быть несколько IP-подсетей (2+) и маршрутизатор (точнее файрвол, но в данном контексте можно считать эти слова синонимами), маршрутизирующий и контролирующий трафик между подсетями.

Следующий шаг — разбиение подсетей на более мелкие подсети. Полюбившуюся нам сеть 192.168.8.0/21 можно разбить на 2 подсети /22, четыре подсети /23, восемь /24 и т. д. Общее правило, как не сложно догадаться, такое: K=2X-Y, где K — количество подсетей с длиной маски Y, умещающихся в подсеть с длиной маски X.

Обстоятельство пятое. Как и любому приличному IT-шнику, администратору сети, если только он получает зарплату не за красивые глаза, положено знать наизусть степени двойки от 0 до 16.

Процесс объединения мелких префиксов (с длинной маской, в которых мало хостов) в крупные (с короткой маской, в которых много хостов) называется агрегацией или суммаризацией (вот не суммированием!). Это очень важный процесс, позволяющий минимизировать количество информации, необходимой маршрутизатору для поиска пути передачи в сети. Так, скажем, провайдеры выдают клиентам тысячи маленьких блоков типа /29, но весь интернет даже не знает об их существовании. Вместо этого за каждым провайдером закрепляются крупные префиксы типа /19 и крупнее. Это позволяет на порядки сократить количество записей в глобальной таблице интернет-маршрутизации.

Обстоятельство шестое. Чем больше длина маски, тем меньше в подсети может быть хостов, и тем большую долю занимает «съедение» адресов на адреса подсети, направленного бродкаста и шлюза по умолчанию. В частности в подсети с маской /29 (232-29 = 8 комбинаций) останется всего 5 доступных для реального использования адресов (62,5%). Теперь представьте, что вы провайдер, выдающий корпоративным клиентам тысячи блоков /29. Таким образом, грамотное разбиение IP-пространства на подсети (составление адресного плана) — это целая маленькая наука, включающая поиск компромиссов между разными сложными факторами.

При наличии достаточно большого диапазона адресов, как правило из блоков для частного использования 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16, конечно, удобно использовать маски, совпадающие по длине с границами октетов: /8, /16, /24 или, соответственно, 255.0.0.0, 255.255.0.0 и 255.255.255.0. При их использовании можно облегчить работу мозгу и калькулятору, избавившись от необходимости работать с двоичной системой и битами. Это правильный подход, но не стоит забывать, что злоупотребление расслабухой редко доводит до добра.

И последнее. Пресловутые классы адресов. Дорогие товарищи, забудьте это слово вообще! Совсем. Вот уже скоро 20 лет (!), как нет никаких классов. Ровно с тех пор, как стало понятно, что длина префикса может быть любой, а если раздавать адреса блоками по /8, то никакого интернета не получится.

Иногда «матерые специалисты» любят блеснуть словами «сеть класса такого-то» по отношению к подсети с той или иной длиной маски. Скажем, часто можно услышать слово «сеть класса C» про что-нибудь вроде 10.1.2.0/24. Класс сети (когда он был) не имел никакого отношения к длине маски и определялся совсем другими факторами (комбинациями битов в адресе). В свою очередь классовая адресация обязывала иметь маски только предписанной для данного класса длины. Поэтому указанная подсеть 10.1.2.0/24 никогда не принадлежала и не будет принадлежать к классу C.

Но обо всем этом лучше и не вспоминать. Единственное, что нужно знать — что существуют разные глобальные конвенции, собранные под одной крышей в RFC3330, о специальных значениях тех или иных блоков адресов. Так, например, упомянутые блоки 10/8, 172.16/12 и 192.168/16 (да, можно и так записывать префиксы, полностью откидывая хостовую часть) определены как диапазоны для частного использования, запрещенные к маршрутизации в интернете. Каждый может использовать их в частных целях по своему усмотрению. Блок 224.0.0.0/4 зарезервирован для мультикаста и т. д. Но все это лишь конвенции, призванные облегчить административное взаимодействие. И хотя лично я крайне не рекомендую вам их нарушать (за исключением надежно изолированных лабораторных тестов), технически никто не запрещает использовать любые адреса для любых целей, покуда вы не стыкуетесь с внешним миром.

Gentoo – как поймать бандитов.

КБ отдел решил забрать у меня машину, потому что «с неё осуществляется нападие на их ЦОД». В подтверждение они продемонстрировали запросы по адресам

https://fx8.io

https://mirrors.aliyun.com

которые едут с моего компьютера в час ночи, по локальному времени. Последний оказался gentoo-репозиторием по умолчанию в системе, но это ладно. Сменил его на яндекс.

В системе установлено 3.5 пакета (иксы, дрова, пайчарм, фаерфокс), все из генту-репозитория.

Впорос следующий – как найти процесс, пуляющий такие интересные запросы?

Я пока придумал только
netstat -ptuc >> /var/log/network_activity

Но что делать дальше я пока не придумал.

Не резолвит имя сервера.

При попытке подключится к самописному простому эхо-серверу с самописного клиента – getaddrinfo() возвращает ошибку «Temporary failure in name resolution».

Сервер запускается без проблем, порт слушает (проверял с помощью netstat -tulp). Примечание: клиент запускаю из одного терминала, сервер ждёт в другом.

Я совсем зелёный и чувствую, что не до конца понимаю, как это работает. Может ли кто-нибудь объяснить, в чём тут может быть дело? И должно ли оно вообще так работать как я хочу?

 c, network, server

RedOS.Печать по сети.

Есть два компьютера с Redos 7.3. Настраиваю по сети печать. После добавления принтера на втором компьютере пробную страницу печатает и встает. В CUPS пишет что приостановлено пользователем. Находил инфу что это из-за политики ошибок он тормозится. Ставил настройки перезапускать при ошибке. Все равно встает пока не запустишь вручную восстановить печать. Куда копать?

systemd-networkd не хочет поднимать интерфейс

# networkctl
IDX LINK   TYPE     OPERATIONAL SETUP    
  1 lo     loopback carrier     unmanaged
  2 enp1s5 ether    off         unmanaged

Естественно айпи адрес не получен. Система была склонирована из виртуальной машины с помощью clonezilla на реальное железо, практически дефолтная ubuntu 20.04, правда обновлена с 18.04. Если я сделаю ifconfig enp1s5 up; dhclient enp1s5, то интернет работает, но получается все равно unmanaged:

# networkctl
IDX LINK   TYPE     OPERATIONAL SETUP    
  1 lo     loopback carrier     unmanaged
  2 enp1s5 ether    routable    unmanaged

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

#journalctl -u systemd-networkd
-- Reboot --
Jan 31 09:27:21 kiosk1 systemd[1]: Starting Network Service...
Jan 31 09:27:21 kiosk1 systemd-networkd[281]: Enumeration completed
Jan 31 09:27:21 kiosk1 systemd[1]: Started Network Service.
Jan 31 09:31:47 kiosk1 systemd-networkd[281]: enp1s5: Link UP
Jan 31 09:31:47 kiosk1 systemd-networkd[281]: enp1s5: Gained carrier
Jan 31 09:31:48 kiosk1 systemd-networkd[281]: enp1s5: Gained IPv6LL

Три последних строчки относятся к ручному поднятию интерфейса.

 clonezilla, network, systemd, systemd-networkd, ubuntu

Задать внешний ip адрес, Debian 11

Добрый вечер, целый день пытаюсь побороть вот такую задачку:

Имеется сервер (Debian 11) и несколько дополнительных ip. Подключил их таким образом:

auto lo
iface lo inet loopback
    dns-nameservers 213.186.xx.xx

auto ens3
iface ens3 inet dhcp
    accept_ra 0
    mtu 1500

auto ens3:0
iface ens3:0 inet static
    address 2.2.2.2
    netmask 255.255.255.255

auto ens3:1
iface ens3:1 inet static
    address 3.3.3.3
    netmask 255.255.255.255

# control-alias ens3
iface ens3 inet6 static
    address 2000:4000:400:3000::3000/56
#    post-up route add -A inet6 default gw 2000:4000:400:3000::1 || true
#    pre-down route del -A inet6 default gw 2000:4000:400:3000::1 || true

У сервера исходящие соединения происходят с адреса 1.1.1.1, который является дефолтным и задается через dhcp.
А мне нужно сделать, чтобы исходящий трафик шел с адреса 2.2.2.2.
Закомментил строки для ipv6, чтобы не мешало.

Что я уже пробовал:
Во-первых, подключал новые адреса другим способом, но, как я понял, это без разницы

    post-up /sbin/ifconfig ens3:0 2.2.2.2 netmask 255.255.255.255 broadcast 2.2.2.2
    pre-down /sbin/ifconfig ens3:0 down
    post-up /sbin/ifconfig ens3:1 3.3.3.3 netmask 255.255.255.255 broadcast 3.3.3.3
    pre-down /sbin/ifconfig ens3:1 down

Пробовал изменить маршрут таким способом:

 post-up ip route replace default via 1.1.1.1 src 2.2.2.2

Маршруты сейчас выглядят таким образом
$ sudo route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         1.1.1.1         0.0.0.0         UG    0      0        0 ens3
1.1.1.1         0.0.0.0         255.255.255.255 UH    0      0        0 ens3
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-e3f27b8fa113

 ifconfig, ip, network

M.2 WIFI модуль под libre kernel

Посоветуйте недорогой Wireless Network Adapter на чипе m.2 со свободным драйвером.

Нашёл несколько atheros (QCNFA222, QCNFA335, AR9485 QCNFA125) с поддержкой ath9k и Realtek (RTL8852AE, RTL8822CE), но заведутся ли они на libre kernel?

 libre, m2, network, wireless

Как смаршутизироать трафик от nginx?

 network, nginx proxy

putun

Kali Linux не видит wifi адаптер

Здравствуйте,приобрел недавно вайфай адаптер «Wi-Fi USB-адаптер ALFA Network AWUS036AC»,на чипсете Realtek RTL8812AU, захотел им воспользоваться, но в Кали, набирая в терминал ifconfig/iwconfig мой адаптер не отображался , но в списке USB устройств он присутсвует( при наборе команды lsusb теринал выводит:
«Bus 002 Device 003: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter» ).Пробовал установить драйвера командой «sudo apt install realtek-rtl88xxau-dkms»,но безуспешно, все равно Кали его не видит как адаптер, видит его только как USB-устройство. Пользуюсь VMware, но в VirtualBox была та же проблема.Видел эта проблема есть и у других пользователей,но решение тех людей кажется не помогает мне

 linux, network, usb, wi-fi, драйверы

SSH на слабом соединении

Часто приходится админить штуковинцы, сидящие где-то на унылом GPRS, с огромным пингом и потерями под 50%. Оно в целом работает, но имеет сильно выраженная печаль, а именно: при хоть сколько-то активном использовании интернетов (когда в консоль выводится больше пары строк) сессия зависает и с 70% вероятностью больше не восстанавливается. Соответственно, мне становится грустненько.
Поведение одинаковое на разных штуковинцах, немного разнится лишь количество строк, после вывода которого всё портится.
SSH работает через OpenVPN по юди-пай. Подробности никому не интересны, причины, как и всегда, лишь в нас самих.
Что делать и что делать, и что вообще в таких случаях нормальные люди делают?

 network, ssh, потери

ping высокий, когда ноут «поспит»

Добрый вечер) Arch Linux x86_64 5.15.8-arch1-1.

Проблема: ping высокий (wi-fi), когда ноут «поспит». Т.е. работать в сети невозможно: 60+ ms. Перезагрузка РОУТЕРА решает проблему, перезагрузка ноутбука, включение-выключение сетевого адаптера и т.д. – нет. И ping 30-40 ms уже.

Железо для сети в ноуте такое:

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)

Что сделать, дабы оставить роутер в покое?

 arch, net, network, ping

kea dhcp: статическая привязка адресов

Необходимо сделать статическую привязку dhcp-клиентов к IP адресу:

  1. клиент подключается и получает IP адрес

  2. в какой-то момент клиент отключается

  3. клиент опять полнимается и dhcp сервер должен выдпть такой же адрес, что и на первом шаге

Можно завести статические записи в kea конфиге, но для этого нужно заранее знать MAC-адреса или client-id всех клиентов. Но можно ли добиться того, чтобы сервер при первом выделении IP клиенту автоматически заводил бы на него статическую запись? Можно ли это сделать стандартными средствами Kea или нужно создать свою hook-библиотеку?

Настройка сети на сервере (Ubuntu 21.10)

Подскажите пожалуйста как настроить сеть на сервере. На сервере установлен xrdp, подключаюсь удаленно к рабочему столу с помощью RDP-клиента. Сетевые настройки не редактируются (в окошке Edit Connections все настройки выделены серым цветом и их нельзя редактировать).

При вводе в консоле «ip link show»:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:1d:8d:d3 brd ff:ff:ff:ff:ff:ff
altname enp0s3
3: ens6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:5d:e5:fc brd ff:ff:ff:ff:ff:ff
altname enp0s6

При вводе «nmcli device status»:
DEVICE TYPE STATE CONNECTION
ens3 ethernet не настроенно –
ens6 ethernet не настроенно –
lo loopback не настроенно –

 network, ubuntu, интернет, сервер

А как рядовой лоровец защищается от квантовой угрозы?

На рюззгом пока не так много материала, ну плюс минус можно выхлопы РКЦ пока глянуть.

tl;dr есть квантовые сети – нужно оборудование(итоговая стоимость +/- сетевая карта 10g) и прямая оптика до точки назначения, зато подменить ключ можно только опровергнув базовые понятия квантовой механики. Как альтернатива – ассиметричная криптография на базе т.н. «постквантовых» алгоритмов, тут типа тот же RSA только построенный на альтернативных математических задачах.

 dpi, network, pcap, квантовый компьютер, криптография

Што за зверь zerotier

Ну что девчата и зайчата новый год уже почти а мне вот неймется под шафе дай только че нить новое попробовать. Вот щас сижу смотрю ролики и читаю доки про зеротаер. Выглядит как убермега штука и впн нафиг не нужен с таким удобным инструментом. Вопрос только вот в чем. Раз это такой крутой инструмент почему его до сих пор не опакетили даже в дебиане? Почему установка через какой то хрен пойми скрипт с сайта? Хотя в плеймаркете и аппсторе приложение есть но все же. Есть какие то сомнения по поводу благонадежности создателей или че то еще? Кто пользует че как по перформансу? Ютубчик 1080 потянет? Дискас.

Шок кстати даже тега нету. Ну ка создайте.

 network, p2p, децентрализация, новый год

Отваливается первый клиент wireguard если подключается второй

Всех с наступающим!

Я рискнул проапгрейдить ROS до 7.1. Вроде все норм. Поднял wireguard сервер, создал два пира – один rpi4 (bullseye), второй десктопный дебиан (bullseye). Ключи и адреса у пиров разные, приватный ключ сервера и интерфейс естественно один и тот же. Проблема – если подключен первый пир, я подключаю второй пир – сначала он не подключается. Точнее в интерфейсе я получаю такое

wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.70.72.3/24 scope global wg0
       valid_lft forever preferred_lft forever

Маршруты добавляются правильные, но пингануть я ничего не могу, потому что шлюз (в моем случае 10.70.72.1 то бишь роутер с wireguard сервером) недоступен. Пару раз вручную перезапустив подключение через wg-quick второй пир поднимается, но тут же падает первый пир. Почему – не понятно. Такое ощущение, что за одним натом может быть только 1 пир, хотя нигде упоминания этого ограничения я не встретил. Как настроить, чтобы работало одновременно несколько пиров? Любую инфу дам, скажите только какую надо.

[Interface]
Address = 10.70.72.2/24
PrivateKey = client1_priv

[Peer]
PublicKey = server_pub
AllowedIPs = 10.70.72.0/24,192.168.1.0/24
Endpoint = public_ip:13231
PersistentKeepalive = 25
[Interface]
Address = 10.70.72.3/24
PrivateKey = client2_priv

[Peer]
PublicKey = server_pub
AllowedIPs = 10.70.72.0/24,192.168.1.0/24
Endpoint = public_ip:13231
PersistentKeepalive = 25
interface/wireguard/print detail 
Flags: X - disabled; R - running 
 0  R name="wireguard1" mtu=1420 listen-port=13231 private-key="server_priv" 
      public-key="server_pub"


 1   ;;; client1
     interface=wireguard1 public-key="client1_pub" endpoint-address=10.70.72.2 endpoint-port=0 
     current-endpoint-address=10.70.72.2 current-endpoint-port=0 allowed-address=10.70.72.0/24,192.168.1.0/24 persistent-keepalive=25s rx=7.7MiB 
     tx=130.3MiB last-handshake=1h51m31s 

 2   ;;; client2
     interface=wireguard1 public-key="client2_pub" endpoint-address=10.70.72.3 endpoint-port=0 
     current-endpoint-address=10.70.72.3 current-endpoint-port=5694 allowed-address=10.70.72.0/24,192.168.1.0/24 persistent-keepalive=25s 
     rx=2421.1KiB tx=45.8MiB last-handshake=2m47s

Update. Хендшейки с обоих клиентов постоянно обновляются, с этим проблем нет. Маршруты тоже правильные и одинаковые на обоих пирах

default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.24 metric 202 
10.70.72.0/24 dev wg0 proto kernel scope link src 10.70.72.3 
192.168.1.0/24 dev wg0 scope link 
192.168.2.0/24 dev eth0 proto dhcp scope link src 192.168.2.24 metric 202

 mikrotik, nat, network, wireguard

Ubuntu 20.04 настройка домашней сети

Приветствую всех. Имею железку с 2мя сетевыми, установил на нее Ubuntu 20.04
Для многих вопрос будет простым , но я уже более суток не могу найти ответа и настроить сеть. Либо инструкции не соответствуют, либо я что то делаю не правильно.
Есть пк 2 сетевых. В первую подключен провайдер во вторую wifi роутер (проводом).
Пк, стоит Ubuntu server 20.04. сеть есть. Он получает ip от провайдера через первый порт ( но нужно подтвердить mac через браузер) и через второй порт настроен статический ip 192.168.0.1 – роутер и компьютеры за ним все друг друга видят, по ssh подключается.

Как направить трафик из домашней сети (lan2) в сеть провайдера (lan1) ?
Проброс портов не требуется. Прошу помощи и сильно не осуждайте. Пк с Ubuntu будет иметь белый ip, и к ней будет доступ из вне.

 lan, nat, network, ubuntu, шлюз

Не пробрасывается порт из lan в wan

 network, tplink, tp-link, сетевое оборудование

X-server отрабатывает долго

Не подскажите, плиз, если по ssh с удаленной workstation открытие X-ов (например браузер) на сервере очень долгий в чем может быть трабла, канал связи или видеокарта? По внутренней сети все отрабатывается быстро.

Заранее спасибо за ответ.

 linux, network, redhat, ssh, xserver

Есть ли в Москве/МО провайдеры с услугой ограничения доступа в Интернет(ака Родительский контроль) на уровне провайдера?

Привет.
Что имеется ввиду: обычно у провайдеров есть такая услуга, как «Родительский контроль». Там можно настраивать вайтлисты/блоклисты в личном кабинете, после чего провайдер обрубит доступ к этим сайтам для вашей сети. Есть ли такой провайдер, чтобы у пользователя не было доступа к редактированию вайтлистов/блоклистов и тд в лк? Ну то есть конфигурация происходит только на уровне провайдера (путем передачи ему тех самых блоклистов), сам пользоваетль ничего менять не может.

 network, провайдер, роутер, сети, фаервол

gnutls: peer’s certificate is NOT trusted

weechat отказывается подключаться к freenode, требующему в последнее время TLS. Вот как оно выглядит в цвете. И вот как в тексте:

| irc: connecting to server chat.freenode.net/6697 (SSL)...
| gnutls: connected using 2048-bit Diffie-Hellman shared secret exchange
| gnutls: receiving 3 certificates
|  - certificate[1] info:
|    - subject `CN=sunshine.freenode.net', issuer `C=US,O=Let's Encrypt,CN=R3', RSA key 2048
| bits, signed using RSA-SHA256, activated `2021-11-03 23:29:03 UTC', expires `2022-02-01
| 23:29:02 UTC', SHA-1 fingerprint `465d91f6e8a3cb14874e6d87085c153300c0c76a'
|  - certificate[2] info:
|    - subject `C=US,O=Let's Encrypt,CN=R3', issuer `C=US,O=Internet Security Research
| Group,CN=ISRG Root X1', RSA key 2048 bits, signed using RSA-SHA256, activated `2020-09-04
| 00:00:00 UTC', expires `2025-09-15 16:00:00 UTC', SHA-1 fingerprint
| `a053375bfe84e8b748782c7cee15827a6af5a405'
|  - certificate[3] info:
|    - subject `C=US,O=Internet Security Research Group,CN=ISRG Root X1', issuer `O=Digital
| Signature Trust Co.,CN=DST Root CA X3', RSA key 4096 bits, signed using RSA-SHA256,
| activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 UTC', SHA-1 fingerprint
| `933c6ddee95c9c41a40f9f50493d82be03ad87bf'
| gnutls: peer's certificate is NOT trusted
| irc: TLS handshake failed
| irc: error: Error in the certificate.

Между прочим, буду очень признателен за ссылки на талмуды по теме «Мокренькие сертификаты TLS и Дао сертификации для нубов очень занятых людей за пять минут без СМС и регистрации»

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

 gnutls, network, weechat

Читайте также:  Игровой сервер не может запустить игру код ошибки 0х20007 hunt showdown

Добавить комментарий

Ваш адрес email не будет опубликован.