Hacker News Digest

Проект "How Did I Get Here" от Hack Club демонстрирует путь, который пакеты данных проходят от вашего устройства до сервера. С помощью самописного трейсера ktr, работающего по протоколу ICMP с использованием поля TTL, проект в реальном времени отслеживает каждый узел маршрута. Интересно, что сайт работает даже без JavaScript — сервер последовательно отправляет обновленную HTML-разметку, создавая иллюзию плавной загрузки трейсера.

Важно отметить, что показанный маршрут является "обратным" — от сервера к вашему устройству, а не наоборот, что может незначительно отличаться от реального пути из-за асимметрии маршрутизации. Каждый "сеть" в маршруте на самом деле представляет собой автономную систему (AS) — коллекцию маршрутизаторов, принадлежащую одной компании. Статья вскрывает, что интернет — это не свободная сеть, а скорее совокупность корпоративных сетей, связанных финансовыми соглашениями и бюрократическими процедурами.

• Обсуждение охватывает различные аспекты traceroute и его ограничений, включая то, что AS-путь может быть нестабилен, а фактические точки пиринга могут сильно различаться.
• Участники обсуждают, что traceroute может не отображать обратный путь, особенно если сеть использует асимметричное маршрутизирование.
• Обсуждается, что веб-сайт может не работать из-за блокировки ICMP или из-за того, что маршрутизаторы не отвечают на ICMP запросы.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.

XDP (eXpress Data Path) — самый быстрый фреймворк для обработки пакетов в Linux, но изначально работал только для входящего трафика. Компания Loophole Labs обнаружила лазейку, позволяющую использовать XDP для исходящего трафика, exploiting уязвимость в том, как ядро Linux определяет направление пакета. Их решение обеспечивает в 10 раз лучшую производительность, чем текущие альтернативы, работает с существующими Docker/Kubernetes контейнерами и не требует модификаций ядра.

При обработке трафика со скоростью сотни гигабит в секунду во время миграции контейнеров и ВМ, XDP достигает скорости линии связи (line-rate), в то время как Traffic Control (TC) ограничен всего 21Gbps на исходящем трафике. Это критически важно для их инфраструктуры, где каждая CPU-единица имеет значение. Решение позволяет обрабатывать пакеты на максимальной скорости сетевого интерфейса, будь то 20Gbps или 200Gbps, без каких-либо изменений в существующей инфраструктуре.

• XDP для egress – авторы используют виртуальные интерфейсы veth, чтобы заставить XDP обрабатывать исходящий трафик, что позволяет достичь 10-кратного прироста пропускной способности по сравнению с iptables/TC, при этом оставаясь совместимым с контейнерами и Kubernetes.
• производительность и совместимость – тесты показывают, что при использовании XDP для обработки исходящих пакетов достигается 20-ти кратное увеличение пропускной способности по сравнению с iptables/TC, при этом не требуется никаких изменений в контейнере или оркестраторе.
• почему не DPDK? – авторы отмечают, что DPDK требует специального драйвера и не может быть использован в контейнерах без привилегий, в то время как XDP работает в любом месте, где работает Linux kernel, и не требует специального оборудования.
• будущее: TC и eBPF – вместо того, чтобы продолжать использовать устаревший TC, сообщество может перейти на eBPF, что позволит в будущем использовать более продвинутые функции, такие как socket фильтры, которые могут быть реализованы в пространстве имен.

• Wi-Fi 7 и 6 ГГц-диапазон вызывают споры: пользователи жалуются на нестабильность, а производители обещают «скоро будет прошивка» — но обновлений нет уже полгода.
• В реальности большинство клиентов не поддерживают 6 ГГц, а маршрутизаторы не отдают спектра, если не включить 160-МГц.
• Пользователи жалуются, что производители забыли про QoS и политику приоритета трафика: при одновременной загрузке игра начинает лагать, а Zoom-звонки рвутся.
• Кто-то заметил, что вендоры вместо того, чтобы дать более широкий канал, используют его для внутренней передачи между точками доступа, что выглядит как попытка сэкономить на оборудовании.
• Несколько участников обсуждения поделились, что их провайдеры предлагают им 8-16-ГГц-спектра, но они не могут его использовать из-за отсутствия поддержки на стороне клиента.

Опубликована подробная диаграмма стека сети Linux, созданная Hrvoje Horvat из Ericsson Nikola Tesla. Диаграмма охватывает все уровни сетевого стека: виртуализацию и контейнеры, сокеты, TCP/UDP и нижние уровни с GRO, RPS, RFS и GSO, планировщик сети, NetFilter, управление трафиком, драйверы устройств и функции, ускоренные сетевой картой. Каждый раздел содержит советы по оптимизации и статистику.

Диаграмма доступна в формате PDF (5.4 МБ) и является частью книги "Operativni sustavi i računalne mreže - Linux u primjeni". На момент публикации материал получил 515 просмотров и 380 загрузок. Работа распространяется под лицензией Creative Commons Attribution 4.0 International, что позволяет свободно использовать и распространять диаграмму при обязательном указании автора.

• Диаграмма показывает, как пакет проходит через iptables и Netfilter, что вызвало обсуждение о сложности и важности визуализации в Linux.
• Участники обсуждали, что такие диаграммы редко охватывают контейнеры и виртуализацию, и что отсутствие обновлений может сделать их устаревшими.
• Были вопросы о доступности этих диаграм на разных языках и о том, где можно найти больше информации о книге, из которой они были взяты.
• Также обсуждались вопросы о том, как эти диаграммы могут быть использованы в образовательных целях и о том, что делает их такими полезными для понимания сложных систем.
• В конце, обсуждалось, что такие диаграммы могут быть трудны для чтения в формате PDF и что было бы полезно иметь SVG версию.

• Участники обсуждали, что главное — это не советы, а способность студента адаптировать их под себя и не забывать, что университет — это не только оценки, но и социальный капитал, который важнее.
• Подчеркнута важность самодисциплины и тайм-менеджмента, а также то, что не все советы одинаково полезны для всех.
• Участники также обсудили, что важно не только учиться, но и строить отношения и сетевые связи, потому что это может быть даже важнее, чем оценки.
• Также было отмечено, что важно не только учиться, но и развивать навыки, которые будут полезны в будущем, такие как умение учиться самостоятельно и решать проблемы.
• В конце обсуждение завершилось тем, что важно помнить, что университет — это не только оценки, но и опыт, который ты получаешь там.

К сожалению, в предоставленном фрагменте отсутствует основное содержание статьи о PoE (Power over Ethernet). Видны только навигационные элементы и ссылки на различные сайты сети AspenCore, включая EDN, но сам текст статьи с технической информацией не представлен.

Для создания точного и содержательного пересказа мне необходимо непосредственно содержимое статьи, где бы обсуждались основы PoE, стандарты (такие как IEEE 802.3af, at, bt), классы мощности, ограничения по длине кабеля, применение и современные тенденции в этой технологии.

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

• Обсуждение охватывает как технические, так и практические аспекты PoE: от стандартов и безопасности до выбора оборудования и его применения в домашних условиях.
• Участники обсуждают, что PoE позволяет упростить инфраструктуру, но при этом требует внимания к мощности устройств и стандартам, чтобы избежать проблем с совместимостью и безопасностью.
• Также поднимаются вопросы о том, что стандарты PoE могут быть не всегда очевидны для конечных пользователей, и что важно выбирать оборудование, которое соответствует стандарту и не перегревается.
• Обсуждаются также вопросы безопасности, включая риск повреждения устройств при неправильном использовании PoE, и необходимость в использовании стандартов, которые обеспечивают безопасность и надежность.

p, "p. 1" - "p. 2" - "p. 3" - "p. 4" - "p. 5" - "p. 6" - "p. 7" - "p. 8" - "p. 9" - "p. 10" - "p. 11" - "p. 12" - "p. 13" - "p. 14" - "p. 15" - "p. 16" - "p. 17" - "p. 18" - "p. 19" - "p. 20" - "p. 21" - "p. 22" - "p. 23" - "p. 24" - "p. 25" - "p. 26" - "p. 27" - "p. 28" - "p. 29" - "p. 30" - "p. 31" - "p. 32" - "p. 33" - "p. 34" - "p. 35" - "p. 36" - "p. 37" - "p. 38" - "p. 39" - "p. 40" - "p. 41" - "p. 42" - "p. 43" - "p. 44" - "p. 45" - "p. 46" - "p. 47" - "p. 48" - "p. 49" - "p. 50" - "p. 51" - "p. 52" - "p. 53" - "p. 54" - "p. 55" - "p. 56" - "p. 57" - "p. 58" - "p. 59" - "p. 60" - "p. 61" - "p. 62" - "p. 63" - "p. 64" - "p. 65" - "p. 66" - "p. 67" - "p. 68" - "p. 69" - "p. 70" - "p. 71" - "p. 72" - "p. 73" - "p. 74" - "p. 75" - "p. 76" - "p. 77" - "p. 78" - "p. 79" - "p. 80" - "p. 81" - "p. 82" - "p. 83" - "p. 84" - "p. 85" - "p. 86" - "p. 87" - "p. 88" - "p. 89" - "p. 90" - "p. 91" - "p. 92" - "p. 93" - "p. 94" - "p. 95" - "p. 96" - "p. 97" - "p. 98" - "p. 99" - "p. 100" - "p. 101" - "p. 102" - "p. 103" - "p. 104" - "p. 105" - "p. 106" - "p. 107" - "p. 108" - "p. 109" - "p. 110" - "p. 111" - "p. 112" - "p. 113" - "p. 114" - "p. 115" - "p. 116" - "p. 117" - "p. 118" - "p. 119" - "p. 120" - "p. 121" - "p. 122" - "p. 123" - "p. 124" - "p. 125" - "p. 126" - "p. 127" - "p. 128" - "p. 129" - "p. 130" - "p. 131" - "p. 132" - "p. 133" - "p. 134" - "p. 135" - "p. 136" - "p. 137" - "p. 138" - "p. 139" - "p. 140" - "p. 141" - "p. 142" - "p. 143" - "p. 144" - "p. 145" - "p. 146" - "p. 147" - "p. 148" - "p. 149" - "p. 150" - "p. 151" - "p. 152" - "p. 153" - "p. 154" - "p. 155" - "p. 156" - "p. 157" - "p. 158" - "p. 159" - "p. 160" - "p. 161" - "p. 162" - "p. 163" - "p. 164" - "p. 165" - "p. 166" - "p. 167" - "p. 168" - "p. 169" - "p. 170" - "p. 171" - "p. 172" - "p. 173" - "p. 174" - "p. 175" - "p. 176" - "p. 177" - "p. 178" - "p. 179" - "p. 180" - "p. 181" - "p. 182" - "p. 183" - "p. 184" - "p. 185" - "p. 186" - "p. 187" - "p. 188" - "p. 189" - "p. 190" - "p. 191" - "p. 192" - "p. 193" - "p. 194" - "p. 195" - "p. 196" - "p. 197" - "p. 198" - "p. 199" - "p. 200" - "p. 201" - "p. 202" - "p. 203" - "p. 204" - "p. 205" - "p. 206" - "p. 207" - "p. 208" - "p. 209" - "p. 210" - "p. 211" - "p. 212" - "p. 213" - "p. 214" - "p. 215" - "p. 216" - "p. 217" - "p. 218" - "p. 219" - "p. 220" - "p. 221" - "p. 222" - "p. 223" - "p. 224" - "p. 225" - "p. 226" - "p. 227" - "p. 228" - "p. 229" - "p. 230" - "p. 231" - "p. 232" - "p. 233" - "p. 234" - "p. 235" - "p. 236" - "p. 237" - "p. 238" - "p. 239" - "p. 240" - "p. 241" - "p. 242" - "p. 243" - "p. 244" - "p. 245" - "p. 246" - "p. 247" - "p. 248" - "p. 249" - "p. 250" - "p. 251" - "p. 252" - "p. 253" - "p. 254" - "p. 255" - "p. 256" - "p. 257" - "p. 258" - "p. 259" - "p. 260" - "p. 261" - "p. 262" - "p. 263" - "p. 264" - "p. 265" - "p. 266" - "p. 267" - "p. 268" - "p. 269" - "p. 270" - "p. 271" - "p. 272" - "p. 273" - "p. 274" - "p. 275" - "p. 276" - "p. 277" - "p. 278" - "p. 279" - "p. 280" - "p. 281" - "p. 282" - "p. 283" - "p. 284" - "p. 285" - "p. 286" - "p. 287" - "p. 288" - "p. 289" - "p. 290" - "p. 291" - "p. 292" - "p. 293" - "p. 294" - "p. 295" - "p. 296" - "p. 297" - "p. 298" - "p. 299" - "p. 300" - "p. 301" - "p. 302" - "p. 303" - "p. 304" - "p. 305" - "p. 306" - "p. 307" - "p. 308" - "p. 309" - "p. 310" - "p. 311" - "p. 312" - "p. 313" - "p. 314" - "p. 315" - "p. 316" - "p. 317" - "p. 318" - "p. 319" - "p. 320" - "p. 321" - "p. 322" - "p. 323" - "p. 324" - "p. 325" - "p. 326" - "p. 327" - "p. 328" - "p. 329" - "p. 330" - "p. 331" - "p. 332" - "p. 333" - "p. 334" - "p. 335" - "p. 336" - "p. 337" - "p. 338" - "p. 339" - "p. 340" - "p. 341" - "p. 342" - "p. 343" - "p. 344" - "p. 345" - "p. 346" - "p. 347" - "p. 348" - "p. 349" - "p. 350" - "p. 351" - "p. 352" - "p. 353" - "p. 354" - "p. 355" - "p. 356" - "p. 357" - "p. 358" - "p. 359" - "p. 360" - "p. 361" - "p. 362" - "p. 363" - "p. 364" - "p. 365" - "p. 366" - "p. 367" - "p. 368" - "p. 369" - "p. 370" - "p. 371" - "p. 372" - "p. 373" - "p. 374" - "p. 375" - "p. 376" - "p. 377" - "p. 378" - "p. 379" - "p. 380" - "p. 381" - "p. 382" - "p. 383" - "p. 384" - "p. 385" - "p. 386" - "p. 387" - "p. 388" - "p. 389" - "p. 390" - "p. 391" - "p. 392" - "p. 393" - "p. 394" - "p. 395" - "p. 396" - "p. 397" - "p. 398" - "p. 399" - "p. 400" - "p. 401" - "p. 402" - "p. 403" - "p. 404" - "p. 405" - "p. 406" - "p. 407" - "p. 408" - "p. 409" - "p. 410" - "p. 411" - "p. 412" - "p. 413" - "p. 414" - "p. 415" - "p. 416" - "p. 417" - "p. 418" - "p. 419" - "p. 420" - "p. 421" - "p. 422" - "p. 423" - "p. 424" - "p. 425" - "p. 426" - "p. 427" - "p. 428" - "p. 429" - "p. 430" - "p. 431" - "p. 432" - "p. 433" - "p. 434" - "p. 435" - "p. 436" - "p. 437" - "p. 438" - "p. 439" - "p. 440" - "p. 441" - "p. 442" - "p. 443" - "p. 444" - "p. 445" - "p. 446" - "p. 447" - "p. 448" - "p. 449" - "p. 450" - "p. 451" - "p. 452" - "p. 453" - "p. 454" - "p. 455" - "p. 456" - "p. 457" - "p. 458" - "p. 459" - "p. 460" - "p. 461" - "p. 462" - "p. 463" - "p. 464" - "p. 465" - "p. 466" - "p. 467" - "p. 468" - "p. 469" - "p. 470" - "p. 471" - "p. 472" - "p. 473" - "p. 474" - "p. 475" - "p. 476" - "p. 477" - "p. 478" - "p. 479" - "p. 480" - "p. 481" - "p. 482" - "p. 483" - "p. 484" - "p. 485" - "p. 486" - "p. 487" - "p. 488" - "p. 489" - "p. 490" - "p. 491" - "p. 492" - "p. 493" - "p. 494" - "p. 495" - "p. 496" - "p. 497" - "p. 498" - "p. 499" - "p. 500" - "p. 501" - "p. 502" - "p. 503" - "p. 504" - "p. 505" - "p. 506" - "p. 507" - "p. 508" - "p. 509" - "p. 510" - "p. 511" - "p. 512" - "p. 513" - "p. 514" - "p. 515" - "p. 516" - "p. 517" - "p. 518" - "p. 519" - "p. 520" - "p. 521" - "p. 522" - "p. 523" - "p. 524" - "p. 525" - "p. 526" - "p. 527" - "p. 528" - "p. 529" - "p. 530" - "p. 531" - "p. 532" - "p. 533" - "p. 534" - "p. 535" - "p. 536" - "p. 537" - "p. 538" - "p. 539" - "p. 540" - "p. 541" - "p. 542" - "p. 543" - "p. 544" - "p. 545" - "p. 546" - "p. 547" - "p. 548" - "p. 549" - "p. 550" - "p. 551" - "p. 552" - "p. 553" - "p. 554" - "p. 555" - "p. 556" - "p. 557" - "p. 558" - "p. 559" - "p. 560" - "p. 561" - "p. 562" - "p. 563" - "p. 564" - "p. 565" - "p. 566" - "p. 567" - "p. 568" - "p. 569" - "p. 570" - "p. 571" - "p. 572" - "p. 573" - "p. 574" - "p. 575" - "p. 576" - "p. 577" - "p. 578" - "p. 579" - "p. 580" - "p. 581" - "p. 582" - "p. 583" - "p. 584" - "p. 585"

• Wireshark позволяет использовать Android-устройства для удаленного захвата трафика в реальном времени через Bluetooth и интернет, а также iOS-устройства для интернет-захвата.
• Существуют методы интеграции Wireshark с Linux и Windows, хотя пользователи ищут более простые или эффективные решения, чем текущие.
• Wireshark может взаимодействовать с удаленными системами, например, путем перенаправления вывода tcpdump через FIFO (именованный канал), что позволяет анализировать трафик удаленно, даже в сложных средах, таких как Docker.
• Некоторые пользователи считают, что Wireshark устарел по сравнению с современными потребностями, отмечая его ограничения в расширяемости, программируемости и поддержке новых функций, особенно по сравнению с альтернативами вроде Microsoft Network Monitor.
• Wireshark остается ключевым инструментом для многих, но его функциональность может быть расширена или дополнена с помощью других инструментов и методов, таких как интеграция с ETW или использование дополнительных скриптов и утилит.

Крупные компании и хостинг-провайдеры активно внедряют MPTCP (Multipath TCP) для повышения отказоустойчивости и производительности. Например, Google и Meta используют его для распределения трафика между сотовыми сетями и Wi-Fi.

MPTCP позволяет одному соединению использовать несколько сетевых интерфейсов одновременно — например, 5G и Wi-Fi — повышая надёжность: если один путь недоступен, трафик автоматически переключается на другой.

В отличие от обычного TCP, MPTCP также поддерживает многопоточность на уровне ядра Linux, что ускоряет передачу данных. Однако для работы MPTOS требуется поддержка на обоих концах соединения, что пока ограничивает его применение.

• MPTCP и SCTP обсуждаются как способы объединения нескольких каналов, но оба сталкиваются с проблемами: MPTCP требует специфической поддержки в ядре и приложениях, а SCTP не поддерживается большинством маршрутизаторов и имеет проблемы с NAT.
• Пользователи отмечают, что MPTCP теперь имеет улучшенный API и может быть полезен для агрегации полосы пропускания и отказоустойчивости, но его использование ограничено тем, что он не может обрабатывать мобильность (handover) без сохранения старых адресов.
• SCTP, хоть и был предложен как альтернатива, но его поддержка в ядре Linux и в коммерческих устройствах оставляет желать лучшего, и он не может пройти через большинство NAT устройств.
• Вопрос о том, почему SCTP не стал широко используемым, обсуждается в контексте его сложности в прохождении через NAT и отсутствия поддержки в потребительских устройствах.

Почему Wi-Fi в домашних условиях часто работает плохо? Потому что маркетинг и потребительская психология заставляют производителей и провайдеров выставлять по умолчанию широкие каналы 80 МГц вместо 20/40 МГц, что приводит к перегрузке эфира и соседским помехам. А ведь профессионалы знают, что узкие каналы дают больше свободных частот и лучше масштабируют сеть. Но продавать «широкий» канал как «фичу» выгоднее.

Кроме того, популярные онлайн-тесты скорости, которые пользователи любят запускать, сами по себе создают конкуренцию за эфирное время и ухудшают качество связи для всех устройств в сети. Это показывает, что «скорость» как метрика качества Wi-Fi вредоносна сама по себе.

• Wi-Fi оптимизирована под скорость, а не под надежность, что приводит к перегрузке каналов и влияет на задержки и потери пакетов, что особенно критично в плотно населенных местах.
• Пользователи часто не осознают, что их сети могут быть перегружены из-за соседей, и что это может быть причиной проблем, которые они приписывают провайдеру или оборудованию.
• Провайдеры и производители оборудования продолжают продвигать "скорость" как единственную метрику качества сети, потому что это легко продавать, даже если это не отражает реальную производительность сети.
• В действительности, наилучшая производительность Wi-Fi достигается при использовании Ethernet кабеля для стационарных устройств, оставляя Wi-Fi для мобильных устройств, где это действительно необходимо.

VALORANT изначально требовал серверы с частотой 128 тиков для минимизации преимущества атакующего и обеспечения честного геймплея, где защитники успевают реагировать. Это означало обработку кадра каждые 7,8125 мс, но изначально сервер тратил 50 мс на кадр, что делало задачу масштабирования неподъёмной из-за высоких затрат на CPU.

Команда разбила проблему на категории: репликация, сеть, анимация, движение и другие, внедрив систему ValSubsystemTelemetry для точного измерения времени выполнения кода. Используя внутреннюю аналитическую платформу Riot, инженеры визуализировали данные и последовательно оптимизировали код, железо и настройки ОС, достигнув цели в 2,34 мс на кадр и обеспечив бесплатные 128-тиковые серверы для всех игроков.

• Обсуждается высокая частота обновления (128 тиков/секунда) серверов Valorant в сравнении с другими играми (Factorio 60, Minecraft 20, CS:GO 64, Fortnite 30).
• Поднимается вопрос архитектурных решений и оптимизаций для достижения низкой задержки (<35 мс), включая выбор процессоров Intel Xeon и отключение анимации в фазе покупки.
• Критикуется система "sub-tick" в CS2 как менее эффективная по сравнению с классическим высоким тикрейтом, а также современный matchmaking, не учитывающий пинг.
• Упоминается, что для некоторых жанров (например, Runescape) достаточно низкого тикрейта (0.6 в секунду), и это определяет геймплей.
• Обсуждаются технические сложности реализации высокопроизводительных серверов на языках с GC (Erlang, Elixir) и предпочтение C++ для симуляции игры.

Создатель популярного сервиса test-ipv6.com, работающего с 2010 года, объявил о его закрытии в декабре 2025 года. Проект, предоставлявший бесплатные инструменты для тестирования IPv6-соединений, долгое время поддерживался за счёт личных ресурсов автора — без какого-либо дохода. Решение связано с желанием перераспределить усилия в пользу семьи.

Исходный код большей части проекта уже открыт на GitHub, однако компоненты, связанные с геолокацией и идентификацией провайдеров, не могут быть опубликованы из-за договорных ограничений. Владелец допускает передачу домена авторитетной интернет-организации, но призывает операторов зеркал и провайдеров подготовиться к прекращению работы сервиса и обновить свои процессы.

• Благодарность создателю сайта test-ipv6.com за многолетнюю полезную службу в отладке IPv6
• Обсуждение технических проблем с IPv6: плохая маршрутизация, потеря пакетов, сложность настройки и неполная поддержка провайдерами
• Предложения по сохранению сайта: передача другому лицу (например, ben из IPinfo) или организации, поиск спонсорства
• Замечание, что развертывание IPv6 в новых проектах стало необходимостью, несмотря на сохраняющиеся проблемы
• Освещение практических и финансовых трудностей поддержки публичного сервиса, включая атаки и стоимость запросов геолокации

До двух миллионов сетевых устройств Cisco уязвимы для активно эксплуатируемой уязвимости нулевого дня CVE-2025-20352. Ошибка переполнения стека в компоненте обработки SNMP позволяет удалённо вызывать отказ в обслуживании или выполнять произвольный код с правами root. Для атаки требуется знать read-only community string — часто стандартный или широко известный внутри организации пароль.

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

• Проблемы безопасности и стабильности SNMP: уязвимости, ошибки, приводящие к сбоям, и сложность безопасной настройки.
• Необходимость отключения или изоляции SNMP (особенно версий v1/v2c) для защиты, особенно для малых сетей, в то время как крупные операторы зависят от него для мониторинга.
• Риски использования SNMP для lateral movement внутри сети, даже если он не доступен из интернета, из-за широко распространённых небезопасных конфигураций.
• Критика Cisco и других вендоров за большое количество уязвимостей и общее снижение качества инженерной работы.
• Скептицизм относительно реального масштаба угрозы из-за низкой активности сканирования SNMP и предположения, что инцидент может быть honeypot.

Интернет-экспланты (IX) остаются важной частью сетевой инфраструктуры, работая как гигантские Ethernet-коммутаторы, которые обрабатывают трафик на уровне MAC-адресов. Однако многие сети подключаются к ним с небезопасными настройками по умолчанию, предназначенными для домашних или офисных сред, что приводит к утечке информации или уязвимостям.

Сервис bgp.tools отслеживает такие проблемы, собирая широковещательный и multicast-трафик с портов IX. Среди частых находок — протоколы идентификации устройств, такие как LLDP, CDP и MNDP, которые раскрывают детали конфигурации, имена устройств, IP-адреса и версии ПО, что может быть использовано злоумышленниками. Например, пакеты Mikrotik MNDP показывают точные данные о железе и софте, включая IPv4/IPv6-адреса.

• Обсуждаются примеры грубых ошибок в настройке сетей, включая замену управляемого коммутатора на неуправляемый для подавления STP BPDU.
• Участники объясняют концепцию точки обмена интернет-трафиком (IX) как специализированной LAN-сети для прямого соединения маршрутизаторов крупных провайдеров и обмена маршрутами через BGP.
• Поднимается вопрос о целесообразности использования протоколов вроде LLDP и STP на публичных сегментах сети IX, так как они могут представлять дополнительный риск.
• Отмечается распространенная проблема излишнего усложнения сетевых конфигураций и копирования непроверенных решений.
• Обсуждаются инциденты утечки служебного трафика или данных из-за ошибок конфигурации, приведших к мосту не предназначенных для этого сетей.

• Обнаружена крупная анонимная сеть с более чем 100 000 SIM-карт и 300 серверами, способная отправлять 30 млн SMS в минуту и потенциально нарушать работу экстренных служб.
• Участники обсуждают сомнительность связи сети с ООН, так как оборудование было найдено в радиусе 35 миль от штаб-квартиры ООН, что покрывает весь Нью-Йорк, и выражают скептицизм по поводу подачи информации властями.
• Высказываются предположения о реальных целях сети: от рассылки спама и создания аккаунтов для мошенничества до организации DoS-атак на вышки сотовой связи и координации преступной деятельности.
• Отмечается, что аренда помещений и покупка оборудования оставляют финансовый след, что ставит под вопрос полную анонимность операторов, а отсутствие арестов вызывает недоумение.
• Обсуждаются технические аспекты: возможность обнаружения таких сетей операторами связи, использование SIM-карт для звонков на 911 без абонентского плана и сложности поддержки физической инфраструктуры.

Многие ошибочно полагают, что TXT-записи в DNS ограничены 255 байтами, но на самом деле лимит определяется размером DNS-пакета. Для UDP это около 1232 байт, а при использовании TCP можно передавать до 64 КБ данных. Это демонстрируется через сервис Google Public DNS с JSON API, где большие изображения передаются в бинарном виде без кодирования Base64 для экономии места.

Такой подход позволяет обходить традиционные ограничения и может иметь последствия для безопасности, так как злоумышленники могут использовать DNS для туннелирования крупных payload прямо в браузер. Низкое значение TTL (10 секунд) предотвращает засорение кэшей, но теоретически его увеличение превратило бы DNS-резолверы в бесплатный распределённый CDN.

• Использование DNS в качестве транспортного механизма для передачи данных (изображений, HTML, видео) и обхода ограничений или платы за трафик.
• DNS-туннелирование (например, с помощью проекта Iodine) позволяет создавать каналы связи через порт 53, часто открытый в фаервллах.
• Техника может использоваться для эксфильтрации данных, обхода captive-порталов и межсетевых экранов, но современные системы защиты научились это детектировать и блокировать.
• Существуют технические ограничения (размер записи ~64KB), которые обходятся с помощью множественных TXT-записей или использования TCP.
• Обсуждение носит исследовательский и экспериментальный характер, мотивированный любопытством и желанием обойти ограничения.

Советы по установке Windows 98 в QEMU/UTM

• ACPI вместо PnP BIOS
  SeaBIOS ломает PnP-перечисление. Запускай установку с флагом setup /p j – Windows 98 SE сам перейдёт на ACPI и все устройства определятся корректно.

• Система
  Выбирай машину pc-i440fx, Q35 не нужен. CPU «pentium2» – оптимально для 9x/NT4.

• Ввод
  Отключи USB-контроллер, иначе зависает. Мышь/клавиатура только PS/2; курсор захватывается, но на iPad с внешней клавой не критично.

• Видео
  -vga cirrus – единственный ускоренный вариант с родными драйверами. Есть баги 16/8-бит, но терпимо. Rage 128 пока сыра.

• Сеть и файлы
  SLiRP-NAT + PCI-NE2000/PCNet/DC2114x = доступ в интернет и SMB-шары без танцев. ISA-NE2000 (300h, IRQ9) – только если очень надо.

• Звук

  • SB16: PCM работает, MIDI нет.
    SET BLASTER=A220 I5 D1 H5 P330 T5
  • AdLib (OPL2) можно добавить отдельно.

• Пользователи делятся опытом запуска Windows 95/98 в эмуляторах: QEMU, VirtualBox, DOSBox, PCem, x86box, UTM.
• Проблемы: нет sb16 в virt-manager, AC97 работает нестабильно, Win9x в DOSBox «часто ломается», требуются драйверы для тач-ввода.
• Для MIDI достаточно встроенного Microsoft GS Wavetable Synth, но DOS-игры, требующие SB16-MIDI, всё равно могут не заработать.
• PCem/x86box дают высокую точность эмуляции старого «железа», но медленнее; QEMU ориентирован на современные ОС.
• Win98 не умеет останавливать CPU (нет HLT), поэтому в эмуляторе грузит хост на 100 %.

Tailguard — Docker-контейнер, связывающий Tailscale и WireGuard.

• Поднимается одной командой, не требует root.
• Перенаправляет трафик Tailscale → WireGuard и обратно.
• Подходит для «проброса» Tailscale в сети, где нативный клиент не ставится.

• TailGuard — это контейнер, который автоматически берёт конфиг WireGuard и объявляет подсети из туннеля как Tailscale-subnet-router; остальному tailnet они сразу доступны.
• Проект начинался с «пары строк», но пришлось добавить переподключение при смене IP, DNS-ротацию и лёгкий React-UI; всё упаковано в Go-сервис + контейнер.
• Решение работает и с fly.io: вместо camellia.conf на клиенте поднимают TailGuard-контейнер рядом с их WireGuard-шлюзом и получают приватную сеть fly внутри Tailscale.
• На Android единовременно можно только один VPN, поэтому TailGuard удобнее «двойных» подключений; на iOS/WG-официальном клиенте можно выборочно маршрутизировать.
• Альтернатива — готовые 5G-роутеры GL.iNet (IMEI-клон, встроенный Tailscale/WireGuard), но у автора был опыт с TP-Link Deco X50-5G и он его «не особо рекомендует».

Сводка Azure

• Инцидент: 06.09.25, 05:45 UTC – повреждены подводные кабели в Красном море; трафик Европа ↔ Азия идёт обходными путями, задержки выше нормы.
• Статус: команды перенаправляют нагрузку, ремонт займёт время; обновления ежедневно.
• Регионы: задержки возможны во всех европейских, азиатских и ближневосточных зонах; сервисы помечены «Information».
• Действие: следите за Azure Service Health в портале, настройте оповещения.

• 6 сентября 2025 г. около 05:45 UTC несколько подводных кабелей в Красном море оборвались, и трафик Европа ↔ Азия пошёл обходными путями с ростом задержки.
• Пока неясно, случайность это (рейд якорей) или умысел; официальных выводов нет.
• Кабели чинят: спецсудно крюком поднимает концы на борт, вырезает повреждённый участок и сваривает новый отрезок, после чего кабель опускают обратно.
• Процесс сложен: современные кабели натянуты без излишков, поэтому часто приходится предварительно разрезать их на дне.
• Подобные обрывы в Красном море и у Сингапура случаются регулярно — чаще всего виноваты якоря судов.

Краткое резюме: пределы точности NTP в Linux

• Цель – синхронизировать часы Linux-систем с погрешностью < 1 мкс (желательно < 10 мкс) для корректных распределённых трассировок.
• Результат – большинство узлов держатся в пределах ~500 нс; улучшить без точной инженерии сложно.

Основные ограничения

1. GPS не идеален

   • 3 GPS-приёмника на столе расходятся до ±200 нс; даже топовые модули дают ~5 нс джиттера.
   • Чтобы уложиться в 50 нс, нужны одинаковые длины антенных кабелей и пр.

2. Сеть

   • Любой «умный» коммутатор или маршрутизатор легко добавляет 200–300 нс систематической ошибки.
   • RTT в моей сети 20–30 мкс, поэтому цель < 1 RTT.

3. NIC и драйверы

   • Intel E810 – отлично, X710 – хорошо, Mellanox ConnectX-5 – сойдёт, ConnectX-3/4 – на грани, Realtek – не надо.
   • Разница в драйверах и аппаратных метках времени (timestamps) доходит до сотен наносекунд.

4. Системные задержки

   • Случайные «затыки» из-за SMBIOS/PM: 100–1000 мкс без предупреждения.
   • Дешёвые mini-PC показали 1300–2000 нс дрейфа, но два других – всего 20–50 нс. Серверное «железо» стабильнее.

Практические цифры

• Типовая синхронизация по локальному GPS-источнику через Chrony: ~500 нс.
• В лабораторных условиях Chrony демонстрирует < 100 нс, но это исключение.

Вывод
Без специализированного оборудования, калибровки кабелей и тщательного выбора NIC/драйверов 200 нс – реалистичный потолок для обычной сети.

• Участники считают, что автор путает цели и средства: ему нужна не абсолютная точность, а согласованность логов между машинами.
• Критика: в посте игнорируют PTP, аппаратное тайм-стемпинг, saw-tooth коррекцию GPS и другие ключевые приёмы.
• Несколько человек подтверждают, что Chrony + хорошие NIC дают суб-микросекунды без PTP, если задача не требует <200 нс.
• Уточняют, что GPS-модули нужно выводить в stationary mode и калибровать сутками для десятков наносекунд.
• Появляются примеры, где такая точность действительно нужна: синхронизация базовых станций, HFT, триангуляция радиосигналов.

port-kill — лёгкий монитор портов для macOS в строке меню.
Показывает занятые порты, позволяет одним кликом освободить нужный.

• Пользователи спорят, почему выбран диапазон портов 2000-6000 вместо привычных 8xxx.
• Многие делятся консольными скриптами (killport, whoseport) и альтернативами вроде Raycast-расширения.
• Критика: README перегружен, не объясняет «зачем» нужен монитор портов в трее.
• Подозрение, что проект сгенерирован ИИ: многословный текст, ASCII-дерево структуры, отсутствие скриншотов.
• Автор отвечает: «сделал для себя, бизнес-кейса нет».

LinkedIn поощряет посредственность

LinkedIn раздражает: из удобного резюме превратился в поток пустых постов ради «личного бренда». Лента забита переработанной, но бессмысленной «токсичной посредственностью» — советы вроде «чему мой развод научил B2B-продажам». Это не заметно, как токсичная позитивность, но суть та же: 150 слов о том, что «солнечные дни тёплые».

Площадка всё ещё полезна, но ценное тонет в шуме. Алгоритм вознаграждает лайки и комментарии, продлевая время на сайте и продавая премиум. Пользователи искренне хотят карьерного роста, но такие посты, скорее всего, не помогают.

Что делать? Помнить: LinkedIn — сайт Microsoft, зарабатывающий на вашем времени. Посты не строят карьеру; работа и её результаты — да. Пишите редко, но по делу. Если важно писать онлайн — заведите блог: меньше просмотров, но выше планка. Поддерживайте тех, кто не играет в эту игру. А если всё надоело — закройте ноутбук и выйдите на улицу.

• Критики называют LinkedIn «свалкой токсичной посредственности»: лента забита высоко-фальшивыми постами, фейковыми вакансиями и «вдохновляющими» байками.
• Пользователи жалуются на спам-рекрутеров, продавцов и «игры статуса», где важнее имидж, чем реальная экспертиза.
• Некоторые признают: если выбирать контакты и темы, можно найти полезные кейсы и даже миллионы долларов выручки, но это скорее исключение.
• Популярны «хаки» выживания: отключить ленту, отписаться от всех, писать только о реальных проектах или вообще перейти на личный сайт.
• Итог: LinkedIn — удобная база резюме и инструмент нетворкинга, но как соцсеть он превратился в «корпоративный клондайк» с низким качеством контента.

XR2000 — новый программистский квест в жанре научной фантастики.
Он объединяет бинарные протоколы, криптографию и развёрнутый сюжет, который пока охватывает лишь первую главу. Дальнейшее зависит от интереса участников.

Вдохновение дали:

• TIS-100 — псевдоассемблер в игровой форме.
• Space Traders — космическая торговля через REST API.
• Protohackers — челленджи по сетевым протоколам.

Старт:

nc clearsky.dev 29438

Приятного погружения!

• Участники делятся ссылкой на похожий Sci-Fi-контест 2006 года, где нужно писать собственную VM.
• Появился новый TCP-пазл на clearsky.dev:29438; при подключении требуется отправить 0-байт + «XR2K» для документации.
• Сервер перегружен HN, поэтому текст иногда не выводится или после команды ничего не происходит.
• Некоторые пробуют использовать LLM для упрощения игры.
• Один из игроков ждёт ответа «Colonel Arhci» по atlantiamail.

Как военный проект стал щитом приватности

На скрипучем поезде в тумане я пытаюсь зайти на сайт, но Wi-Fi блокирует его. Запускаю Tor Browser — страница открывается мгновенно.

Tor, или «тёмная сеть», ассоциируется с криминалом, но финансируется частично правительством США, а BBC и Facebook ведут в нём «зеркала» для обхода цензуры. Суть: трафик шифруется и прыгает по серверам мира, скрывая пользователя и обходя блокировки.

От криптовойн до Tor

90-е: хакеры-циферпанки вооружают гражданских военным шифрованием, предупреждая, что интернет может стать тоталитарным. Бизнес и Пентагон поддерживают: свободный поток данных = рыночная победа.

В исследовательской лаборатории ВМС США (NRL) инженеры ищут способ скрыть IP подлодок. Их решение — луковая маршрутизация — ложится в основу Tor.

Двойная игра государства

Сегодня одни ведомства финансируют Tor, другие требуют «задних дверей». Технологии, рождённые для шпионажа, стали инструментом сопротивления цензуре и массовой слежке.

• @neilv использовал Tor для скрытого мониторинга международной торговой площадки, выбирая выходные узлы под нужные регионы.
• @palsecam и @jmclnx рассказали, что запускать ретранслятор или bridge дёшево (VPS за $5) и безопасно, помогая обходить цензуру.
• Некоторые считают Tor «мертвым» или скомпрометированным; другие советуют прятаться в толпе, использовать VPN, residential-прокси или переходить на i2p.
• Книга «Tor: From the Dark Web to Your Browser» доступна бесплатно от MIT Press и получила положительные отзывы.
• Основные советы по безопасности: брать Tails на флешке, не ставить расширений в Tor Browser, не логиниться личными данными.

I have nothing but good things to say about ubiquiti. I run their cameras door bell and network switches at my house and have had nearly 100% uptime for years. Their ui constantly improves and it’s very well integrated into home assistant.Lotta haters out there but this is just a