Jump to content

IgaX

Forum Members
  • Posts

    950
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by IgaX

  1. вложенная матрешка зашифрована со всеми потрохами, при должном шифровании - сигнатуры, если и будут применены, смогут давать очень большой процент ложных срабатываний (а поток еще ведь и собрать надо). все что видно: транспортный L4 и зашифрованный до мозга костей payload со всеми вложенными .. и флаг им в руки и барабан на шею =) .. ну вот как по приложению - если только наугад по номеру порта, а его вот поменять и .. усе .. ушел под воду.
  2. не, при секьюрном хэндшейке на лету они, скорее всего, могут ток, например, DN/CN публичного ключа (сертификата) хоста заматчить и дать RST в трубу. при остальных правильных требованиях к шифрованию - не выйдет точечно, ток все подряд, а тут и словят =) *** т.е. под потенциальным ударом только фронт-энд сервиса в плане удобства доступности, на уровне движа ничего им не светит.
  3. Можно ведь и грамотно все сделать. Там OVPN в принципе ничего так, особенно если фьюжн PSK с TLS. Если особо не вдаваться в подробности, то CA разные, клиент генерирует private, при желании паролирует и хранит как зеницу ока, а не светит в паблике как если это норма (тут уже начинаешь сомневаться за будущее вообще), на основе него (private) - CSR, который отправляется туда, где его подпишет нужный CA и вернется клиенту в виде CRT .. и эти транзакции via TLS не ниже 1.2 в рамках тех же ЛК (что для сертификатов в принципе - лишнее, но на всякий). Как бы задача сервиса сделать все так, чтобы все это было понятно, удобно и ненапряжно (желательно на полном автомате, чтобы минимизировать/исключить косяки со стороны хомо сапиенсов), а по вектору "Mellon", например, открывать возможность поднятия отдельного p2p instance на заданном порту. А с базовыми контроллерами всегда начиналось заворачиванием в зазеркалье по диапазону ip, которые светились. А потом в их блогах читать какие они победоносные =) При грамотной схеме им только пыль глотать.
  4. Видел недавно один VPN раздающий приватный ключ бонусом к сертификатам. Добавил в Wireshark под SSL в RSA keys list для 0.0.0.0 к 1194-му для начала для протокола data .. Portable ругнулся в аут сначала, видимо, что не было индексного для ключей .. но потом все норм завелось и добавляется .. м.б. валидный. Дальше не смотрел. Наверное, в этом есть тайный смысл. Все такое подозрительное. https://wiki.wireshark.org/OpenVPN
  5. Встроенный DLNA - норм (или Вы ему "что-то" зажимаете?). А сэлф будет? А смарт на телике - это панацея? Там все от стокового плеера зависит. IGMP Proxy - это, кхм, ближе к другому слою, но миф забавный. Minidlna .. все украдено до нас. force_sort_criteria
  6. Если считать, что провайдер ТВ видит mac приставки, а не mac интерфейса, в который заходит, например, его провод, то пока никак.
  7. вот Вы как-то все свое гнете, думая, что простой switch Вам поможет грамотно завернуть мультикаст по разным портам и разным подпискам, а не получить полномасштабный multicast-flood на всех портах switch-а. в общем, вот (вроде все просто): https://help.keenetic.net/hc/ru/articles/213967709-Настройка-одновременного-доступа-в-Интернет-и-к-услуге-IPTV-через-двух-разных-провайдеров выделять downstream в отдельный "сегмент" - на вкус и цвет если igmp snooping нормально пашет (вроде не жаловались в крайнее время). так что, вперед, к победе.
  8. будет, например, 2 порта на WAN (один из которых только для IPTV), будут 3 порта выделены под STB (и как бы все равно надо IGMP Snooping ключ на старт) .. и места под 5-6 LAN-клиентов все равно не хватит .. поэтому .. либо умного на приставки, либо попроще для LAN, которые не влезли .. а там уже дальше думать
  9. ох уж эти интеллигентные провайдеры: колл-центры, рвущиеся сессии, гигабиты, а про фтп-трафик шейпинг/полисинг на донышке
  10. Остальные чатлане, честно отключившие SMBv1 на клиентах и ожидающие поддержку всестороннего шифрования от SMBv3.1.1 по 445/TCP в рамках Embedded SMB/CIFS (от Tuxera? full specs), чтобы секьюрно гонять трафик в 0.0.0.0/0, наверное, уже смирились.
  11. IPv6 не проблема, всегда можно inet6num запросить. Те же яйца только в профиль.
  12. это, видимо, как пульт для усилка, но в dca-стиле .. чтобы на выходе мощу поднять перед передачей на следующий узел .. ламповые еще ценятся в плане сглаживания помех и прочего мусора .. там .. плохо группу слышно, поднял gain и заодно слышишь группу через дорогу если без изоляции и смотря где "звукосниматель" .. ну т.е. если в лесу и надо передачу от клиента поднять на дистанции, то норм по идее. подбирать методом тыка или цеплять под карбюратор, заводить и смотреть в таком стиле:
  13. В браузере зайдите на http://my.keenetic.net/#web.tc -> тапаем/кликаем радиобатон "parse" -> в поле ниже можно вставлять команды CLI, которые можно скопировать, например, отсюда (следуя при этом инструкциям), не забывайте нажимать Send! после строчки с командой. Помните про DNS на клиентах (можно отдавать принудительно по DHCP - есть выше). Проще пока никак. Всегда можно сбросить все кнопкой Reset и начать с последнего сохранения startup-config. Режима с хардкором пока нет, но я не удивлюсь. P.S. Просто роутер слишком крут для того, чтобы это можно было делать удобно в админке, это его и спасает
  14. на первый взгляд, желание @posydon для ВК можно было бы организовать так (при условии, что VPN через PPTP0 настроен для выхода в инет через админку, проверен, что работает по тем же приоритетам) .. если в лоб за один заход по логике через cli или #web.tc: 1) снимаем с PPTP0 установку маршрута по-умолчанию от приоритета global (оставляя интерфейс поднятым): interface PPTP0 no ip global 2) добавляем маршруты для ВК (например, агрегированные от ripe по mnt-* при помощи) через PPTP0 при его (VPN) доступности(?): ip route 87.240.128.0/18 PPTP0 auto ip route 93.186.224.0/20 PPTP0 auto ip route 95.142.192.0/20 PPTP0 auto ip route 95.213.0.0/17 PPTP0 auto ip route 185.32.248.0/22 PPTP0 auto В итоге: все идет на маршрут по-умолчанию на интерфейс с наивысшим global (например, Ваш ISP) кроме трафика, который попадает в список выше (это идет через PPTP0) .. чтобы это заработало нужно в т.ч. проверить, что клиенты получают адреса для указанных CIDR при обращении к DNS, которые на них настроены .. после первой настройки п.1, п.2 и проверки своих клиентов на предмет адекватных DNS - кэши DNS на клиентах очень желательно почистить. Если все заработало, то сохранить конфиг: system configuration save Если схема рабочая, то п.2 по аналогии для остальной "запрещенки". Как еще проще, чтобы всем было удобно - пока не знаю.
  15. если крупный, то надо учитывать еще поведение балансировщика, а то вдруг скинет на (например): https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AS28709&type=aut-num я бы по mnt еще смотрел (например, если б султан сказал заблочить, то в т.ч. таким путем пошел): https://apps.db.ripe.net/search/query.html?searchtext=VKONTAKTE-NET-MNT&inverse=mnt-by;mnt-domains;mnt-routes&types=inetnum&rflag=true&source=RIPE#resultsAnchor и на тот случай если проще будет в т.ч. по географии завернуть: https://stat.ripe.net/RU#database_country-asns.resource=RU&database_country-resource-list.resource=RU&routing_country-routing-stats.comparison=no&routing_country-routing-stats.resource=ru&routing_country-routing-stats.zoom_end=1495178100000&routing_country-routing-stats.zoom_start=1494854400000&tabId=database
  16. .. чтобы пляску с dns на клиентах свести к минимуму просто настройте: "Домашняя сеть" -> "Сегменты" -> "Home" -> "Сервер DHCP" .. чтобы DNS 1 и DNS 2 были, например: 8.8.8.8, 8.8.4.4 .. после чего переподключите клиентов и почистите на них кэши dns (либо перезагрузите), чтобы со стороны клиентов заработали запросы к этим "справочным" (в свойствах подключения можно перепроверить) .. vpn это как портал в терминах игр .. неважно где выход из портала - справочная гугла должна будет выдать адекватный ответ для локации в которой Вы вышли
  17. ip tcp adjust-mss pmtu - это у Вас есть на interface PPTP0 .. хотите проверим WoT и WoW на предмет черной дыры по пути между галактиками? Там несложно, чутка реестр поправить, если Вы готовы конечно, зато может решить очень много проблем любого софта (иногда кривого, хотя и галактики тоже пнуть немного не помешает). ну .. как сказать .. по аналогии: если без VPN, то Вы узнаёте в "своей справочной" (DNS Вашего ISP или какой настроен) нужные IP, если с VPN - в "нашей" (если в настройках придут еще ее координаты и если она в приоритете) - это Вам KB Кинетика изучать и хэлпдеск мучить. главное тут одно: клиент все это дело кэширует, поэтому каждый раз, когда меняете подключение, - не забывайте на клиенте чистить эти кэши (на всякий случай, а то клиент запомнит сопоставление имени и определенного ip на некоторое время, а если по нему (разрешаемому из кэша - ip) из другого подключения не достучаться? правильно, другие dns вполне подскажут другие ip) .. вникаете постепенно? если кратко,то запрашивайте справочную dns гугла, им фиолетово и они вообще плохо бред переносят, либо есть тема с dnscrypt на форуме (если случай совсем тяжелый) .. easy-2-use app как вариант. Это нормально для кэширующих серверов. Но проблема в том, что они могут быть чьи угодно, все это может перехватываться .. в общем .. справочные могут быть неадекватны. Чтобы получить почти трушный ответ нужно в N заходов, например: nslookup -querytype=soa google.com. узнали: Не заслуживающий доверия ответ: google.com primary name server = ns4.google.com ню, ns4.google.com похож на правду, проверим с другой стороны: nslookup -querytype=soa google.com. ns4.google.com. совсем другое дело (за форж такого обычно появляется ковенант на орбите и в паре с мастер-чифом выжигают планету под корень): ╤хЁтхЁ: ns4.google.com Address: 216.239.38.10 google.com primary name server = ns2.google.com responsible mail addr = dns-admin.google.com serial = 156397181 refresh = 900 (15 mins) retry = 900 (15 mins) expire = 1800 (30 mins) default TTL = 60 (1 min) google.com nameserver = ns2.google.com google.com nameserver = ns1.google.com google.com nameserver = ns3.google.com google.com nameserver = ns4.google.com ns2.google.com internet address = 216.239.34.10 ns1.google.com internet address = 216.239.32.10 ns3.google.com internet address = 216.239.36.10 ns4.google.com internet address = 216.239.38.10 все вроде правильно, поэтому можно спокойно: nslookup google.com. ns4.google.com. или nslookup google.com. 216.239.38.10 .. все данные есть, чтобы более-менее считать достоверными результаты. *** Вам надо найти KB по настройке маршрутов. Понять как выцепить нужные IP. Как их оформить в краткие записи.
  18. тогда пока посмотрите для начала, например, команду nslookup .. скажем, вывод в консоли (командной строке винды): nslookup google.com. (лучше всегда ставить точку в конце) .. там Вам интересна, например, эта часть (которую Вы чаще всего получаете от DNS, который Вы у себя настроили и запрашиваете): Не заслуживающий доверия ответ: ╚ь : google.com Addresses: 2a00:1450:400f:808::200e 87.245.198.23 87.245.198.24 87.245.198.22 87.245.198.27 87.245.198.20 87.245.198.26 87.245.198.21 87.245.198.25 .. это список ip, которые Вам нужно будет привести в удобную запись, чтобы на нее повесить отдельный маршрут через интерфейс с VPN .. .. для этого удобнее воспользоваться, например, туда скопировать из консоли список ip, вывод "CIDR", жмяк - "аггр." .. .. т.е. Вы понимаете, что хотите .. надо узнать на какие ip нужно заворачивать трафик отдельно для VPN .. способов много .. Вы пока прикиньте, а я посмотрю Ваш конфиг =)
  19. какая ось? а то есть одно предположение, возможно, Ваш случай.
  20. Лучше начните с этого - через Ваш VPN частично не открываются сайты/не работают сервисы или полностью не пашет. Потом нужно сделать примерно так. Удобно в любом случае не выйдет, но чтобы хоть как-то жить - это вполне =)
  21. в общем, если обычный ethernet, то bottleneck: остается если ток поддержка Jumbo на свитче и сетевой, либо через "другой" интерфейс с клиента. посмотреть можно так на винде: netsh int ipv4 show int netsh int ipv6 show int покрасить в нужные цифры всегда можно через консоль под админом: netsh interface ipv4 set subinterface "Имя интерфейса" mtu=Значение store=persistent netsh interface ipv6 set subinterface Или_индекс_интерфейса mtu=Значение store=persistent только ими обычно в сторону уменьшения чужие косяки правят =) *** просто пинг с клиента застревает в первом горлышке до обертки и разбивки.
  22. а mtu какой на интерфейсе, к которому комп подключается?
  23. Не, конечно, если глянуть интернеты, то может появиться мысль, что еще пол поколения и пользователь будет напичкан булшитом по самые гланды, а нормальные/продвинутые вообще перестанут транслировать знание в сеть, но .. опять же, почему бы не сделать удобные расширения (пусть и по моделям, как для IntelliQoS, вроде) на странице обновления компонентов .. даже в качестве мотивации - более дорогому железу - больше полезных плюшек на стоке и с удобством, а то реально выходит, что сток по нижней границе всего модельного ряда идет, а котел с ПО практически общий. Да и пользователь на данный момент не настолько глуп, чтобы не осилить инструкцию, например, согласно этой статье (а что ей мешает быть на странице настройки компонента под тем же "спойлером"?). А то упоминают про аналог NAS, про SMBv1 молчат, а юзер потом в депрессии, особенно, когда со всех сторон ему подсказывают, что это клиенты у него *овно .. психика рушится итп. .. неправильно так, вовсе ни к чему так маркетологам об юзера ноги вытирать =)
  24. Все равно сток с SMBv1 - это несерьезно, особенно режет слух, когда начинают скоростями мериться и эта мантра: все норм, окей, офигенно итд. - сразу всех видно Кстати, даже неполный список преимуществ по версиям предполагает насколько обычные пользователи могли бы быть благодарнее (речь идет про "не opkg").
×
×
  • Create New...