Я про то, что есть мануальная форма маршрутизации. Иными словами если у вас есть какой-то сервер который находится за вашим натом и вы считаете, что к нему никак не пробиться извне потому что вы не настроили проброс портов. Вы ошибаетесь я пробьюсь к нему. Поскольку у вас есть внешний NAT...Одна история удивительнее другой, особенно про мануальную маршрутизацию и маршрутизацию по меткам (что это?).
... маршрутизация по меткам позволяет добросить пакет до вашего сервера.
Вы ошибаетесь я пробьюсь к нему.Во-первых, такие заявления (уровня "я пробьюсь") обычно переформулируются в более нейтральные после настойчивой просьбы продемонстрировать заявленное на практике. Во-вторых, оратор забыл уточнить смысл слова "пробьюсь". Что это значит? Пакет из интернета дойдет до сервера? Какой, какому порту предназначен инкапсулированный сегмент? Какой будет эффект? То, что оратор понимает, что NAT и фаерволл - разные вещи - это очень хорошо, жаль только аргументация небезупречна.
Как, подключиться к порту 4321 компьютера 192.168.1.10Это возможно в следующем случае. Клиент 192.168.1.10 устанавливает соединение с веб-сервером 2.2.2.2, используя порт 4321 со своей стороны (так получилось, совпадение). На натирующем устройстве с глобально маршрутизируемым адресом 1.1.1.1 создается трансляция вида (192.168.1.10,tcp,4321)->(1.1.1.1, tcp, 31337). Веб-сервер видит клиента с адресом 1.1.1.1, портом источника 31337, шлет ему данные (сегменты внутри пакетов), которые после натирования фактически направляются клиенту 192.168.1.10, tcp-порт 4321. Далее, если есть злоумышленник 3.3.3.3, которому очень надо послать tcp-сегмент (внутри Ip-пакета) клиенту 192.168.1.10 на порт 4321, то он указывает статический маршрут (см. Я про то, что есть мануальная форма маршрутизации) до 192.168.1.10/32 (длина префикса не важна, по моему мнению) через 1.1.1.1, и ему лишь остается угадать/подобрать, на какой tcp-порт слать сегмент, чтобы он правильно снатировался. Если 3.3.3.3 и 2.2.2.2 взаимодействуют (обмениваются информацией), он пошлет на 31337 порт. Если нет - то логичнее слать равномерно на все порты и надеяться на удачу.
Как пример сойдёт Wi-Fi сеть московского метрополитена
сойдётСмело.
Есть вопрос - как автоматизировать процесс администрирования сетью роутеров и написать что-то вроде биллинговой системы? Необходимо изменять список заблокированных IP, ограничивать скорость на порты и т.д. НА ВСЮ сетьВо-первых, рекомендую определиться с архитектурой сети, затем понять, какие именно параметры, как и на каких именно устройствах необходимо менять. Во-вторых, настраивать устройства можно через удаленную консоль (telnet/ssh, второе предпочтительнее с точки зрения безопасности), через SNMP (пользователь/community с write-доступом) и вероятно через API (Junos XML API, NETCONF), если производитель его предоставляет (см. документацию на устройства).
и написать что-то вроде биллинговой системы?Если планируется легализация (получение лицензий на ведение деятельности и прочая), то биллинг должен быть сертифицирован, поэтому логичнее будет изучить существующие варианты (существуют бесплатные сертифицированные биллинги, насколько мне известно). Если все-таки хотите писать самостоятельно, то собирайте netflow-/sflow- данные и анализируйте их (например, при помощи скрипта-обертки над flow-tools в качестве первого приближения). Если под "биллингом" вы подразумеваете страничку с реквизитами оплаты и кнопкой "купить немного интернета", то смотрите в сторону captive portal.
Нашёл информацию, что это можно делать через telnet. Является ли это надёжным универсальным средствомНадежным - нет (весь трафик, в т.ч. пароли, передается открытым текстом), универсальным - да. Надежным (при грамотной настройке) и универсальным (хотя, бывают исключения) является ssh.
Верно ли понимаю, что подход не меняется, если я хочу построить беспроводную сеть высокой нагруженности (от 1000 пользователей) на оборудовании ubiquiti?В случае использования оборудования от одного вендора имеет смысл обратить внимание на наличие у этого вендора подобных комплексных решений, в том числе решений для централизованного управления.
У меня небольшой опыт в этом, есть много вопросов - возможно вам будет удобно рассказать все подходы и подсказать литературу для чтения по почте?К сожалению, я ни разу не создавал беспроводную сеть такого масштаба, поэтому не считаю себя вправе давать советы (ведь отвечать за потенциальную неудачу все равно вам). Скажу лишь, что на вашем месте я бы попытался:
Дата-центр(Leaseweb) где располагается наш сервер утверждает что у них нету ни каких проблем с сетью, в тоже время наш американский партнер тоже говорит о том, что у него нету ни каких проблем.Странно ожидать чего-либо другого.
Буду очень признателен, если подскажите мне инструменты для анализа соединения и выявления проблем.Одним из факторов, ускоряющих обнаружение проблем и установление их причин, является детальный мониторинг. В данном случае - мониторинг RTT между хостами, Path MTU, загрузки интерфейсов, ошибок на интерфейсах, мониторинг самого приложения и прочая. Если бы мониторинг был активен, вы могли бы посмотреть, какие события коррелировали с возникновением задержек.
Вы не подскажите, можно ли иметь между двумя серверами несколько маршрутов, чтобы на тот случай если под одному маршруту будут проблемы, была возможность использовать другой маршрут?На самом деле между вашими серверами (точнее, автономными системами хостинг-провайдеров) практически наверняка имеется множество маршрутов, проблема лишь в том, что вы не можете влиять на их выбор. Если необходимо выбирать маршрут самостоятельно, то можно сделать следующее - зарегистрировать две автономные системы (в смысле BGP),к примеру, AS1 с префиксом 1.1.1.1/24 и AS2 с префиксом 2.2.2.2/24. Каждую автономную систему подключить через несколько аплинков (установив с ними BGP-соседство). Наблюдать за производительностью (см. мониторинг) и в случае неудовлетворительной работы сети переключать маршруты при помощи программного BGP-решения вроде Bird/ExaBGP. Как вы, наверное, уже догадались, это потребует некоторых финансовых затрат, как капитальных, так и оперативных (продление регистрации автономных систем, ежемесячная оплата трафика/аплинков).
Связь между отделами должна осуществляться или с помощью шлюза, или мостов.Это промышленная сеть или предмет курсовой работы? Меня использование термина "мост" немного удивило.
Составленная схема правильная?Если цель схемы - отобразить физическую топологию, то примерно да.
и какое оборудование использовать?С такими размытыми требованиями (и без указания бюджета) - практически любое. Коммутатор, поддерживающий 802.1q вланы, маршрутизатор, поддерживающий 802.1q, NAT и способный подключиться к вашему провайдеру.
И посоветуйте, пожалуйста, гайды по проектированию таких сетей.В данном случае "проектирование" - слишком громкое слово. Если это курсовая, то должен быть и учебник. Если промышленная сеть - то тут реально два активных сетевых устройства; к тому же я считаю, что без опыта эксплуатации глубоко лезть в "дизайн" непродуктивно. Если все-таки неймется, то в книгах курса CCDA, насколько мне известно, среди маркетинговой хохломы есть и полезные сведения.
distance += abs((i - m[i][j] / 4)) + abs((i - m[i][j] % 4))Если вы вычисляете "манхэттенское" расстояние между текущим и идеальным положениями плитки, то почему под знаками модуля в каждом случае используется один лишь индекс i? Я полагаю, корректнее будет исправить:
distance += abs((i - m[i][j] / 4)) + abs((j - m[i][j] % 4))
алгоритм ставит пустую фишку всегда в позицию [0, 0] а если поставить ее в другое место он "висит"Предполагаю, это из-за вашего подсчета расстояния. Вы нулевое значение (т.е. положение пустой кдетки) игнорируете по какой-то причине.
m = eval(puzz)это очень плохо. Может быть, это сгодится для "олимпиадок", но не рекомендую вам привыкать так делать.
Возможна ли DoS/DDoS атака на устойство слушающее SPAN-порт?Атака возможна на что угодно. Другой вопрос, насколько эффективна она будет.
Возможно ли вообще в принципе завалить SPAN порт трафиком так чтобы устройство перестало с ним справляться?Без уточнения, о каком устройстве идет речь, ответ дать трудно. В общем, если вы подключились в гигабитный порт, и устройство обработает 1.5 миллиона фреймов в секунду, то есть надежда на устойчивую его работу.
На сколько я понимаю технологию зеркалирования вопрос перегрузки SPAN-порта трафиком (и как следствие любого устройства подключенного к нему) вообще не имеет смыслаSPAN-порт (в роли destination) не сможет пропустить трафика больше, чем физически возможно (этот предел задан скоростью среды и размерами буферов). Пример - вы копируете трафик с 3 портов (каждый загружен на 400 Мбит/с в среднем) в один гигабитный (1000 Мбит/с) порт. Примерно одну шестую трафика (3*400 Мбит/с - 1000 Мбит/с =200 Мбит/с) вы будете терять.
т.к. зеркалить можно только заранее аппаратно-определенный поток или вообще только один какой-то порт.Как правило, копировать трафик можно с порта (иногда с фильтрацией по вланам), группы портов, из влана - в другой порт.
Тогда в чем смысл вообще, если мы что-то важное можем пропустить?Часто, например, через SPAN мониторят трафик, приходящий на процессор. Увеличение объема такого трафика, как правило, ничего радостного не сулит.
Как мы тогда можем весь трафик видеть который идет через свич?Если бы я сейчас реализовывал подобный проект (т.е. необходимо видеть "весь" трафик), я бы обратил внимание на продукцию Gigamon (если много денег) или бы поэкспериментировал с пассивными оптическими разветвителями (логично их устанавливать на линки с интересующим нас трафиком).
Scrapy глохнет при скармливании ему неправильного URL.А вы пробовали к ресурсу, адресуемому этим URL, обратиться браузером? У меня открывается статья, с библиографическим номером 2002JIMO...30..199R. Более того, при помощи requests я получаю HTTP 200 в ответ на HEAD:
>>> import requests
>>> response = requests.head('http://adsabs.harvard.edu/full/2002JIMO...30..199R')
>>> response
<Response [200]>Scrapy глохнет при скармливании ему неправильного URL(и так ли это вообще, может быть, эти явления не связаны). Может быть, сайт временно не работоспособен? Может быть, сервер вас (или ваш прокси) блокирует? Может быть, это ошибка Scrapy?
Как быстро выполнить топологическую сортировку дерева из списка?У вас фактически заданы дуги (arcs) графа. Вы можете из этих данных заполнить более удобную структуру данных (adjacency list, например) и на ней уже запустить алгоритм топологической сортировки. Например, основанный на поиске в глубину. То есть, при помощи DFS (depth-first search, поиск в глубину) ищем ноду (вершину, node, vertex), из которой нет исходящих дуг (sink node), присваиваем ей значение, равное количеству нод, удаляем ее из графа, повторяем. Число - позиция ноды в результирующем списке. Сложность O(m+n), где n - число нод, m - число дуг. Это если вам достаточно топологически отсортированного списка нод.
Как наиболее быстро восстановить дерево из этого списка?Это уже другой вопрос. Что вы имеете в виду? В каком смысле 'восстановить'? У вас дерево (как частный случай графа) уже задано списком дуг фактически, в каком виде вам его необходимо представить?
Человек поставил 1 верную галочку и 1 неверную - какой процент верности?20% за одну верную поставленную галочку и 40% за две верные непоставленные галочки, всего 60%
Человек поставил 1 верную галочку и 2 неверных - какой процент верности?20% за верную поставленную галочку, 20% за одну верную непоставленную галочку, всего 40%.
Возможно есть какие-либо статьи или известные решения?Примерно так, по-моему, реализовано тестирование в coursera.
у меня есть сеть и я ставлю чтоб трафик считал только с 111.0.0.0/255.0.0.0Я немного не понял используемую вами нотацию. Обычно используют или A.B.C.D/n, где n - длина префикса (число от 0 до 32), либо A.B.C.D M.M.M.M, где M.M.M.M - битовая маска (32 бита, 4 десятичных числа через точку, пример 255.255.255.0). Проясните этот момент, пожалуйста.
Есть ли на белом свете решение под ключ под наши нужды?
route add -net 192.168.99.0 gw 192.168.99.19 netmask 255.255.255.0У вас уже сеть 192.168.99.0/24 завешана на интерфейсе bond0 и доступна через него:
192.168.99.0 * 255.255.255.0 U 0 0 0 bond0Я чего-то не понимаю и это какой-то линукс-костыль? Какова функция этой строки?
The polarization of this antenna is vertical, and the radiation pattern is roughly donut shaped, with the axis of the donut in the vertical direction.
The Planar Inverted-F Antenna is popular because it has a low profile and an omnidirectional pattern.