throughtheether

Как можно отследить проблему?

Какую проблему?

Пробовал подключать его к своему роутеру и через lan, и через wlan, но через какое-то время замечал, что на всех компьютерах в сети начинал падать инет. Отключаю сервак от сети - инет сразу везде работает.

Уточните, что означает "падает"/"работает" интернет? Открываются/не открываются страницы в браузере? Проходят/пропадают icmp-пакеты ("пинги")? Сравните настройки (адрес, маска сети на интерфейсе, маршрутизатор по умолчанию, DNS-сервера, arp-таблица, таблица маршрутизации) на подверженном проблеме компьютере в условиях "рабочего" и "нерабочего" интернета.

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

Как определить с помощью утилиты pathping в какой точке сети проблема?

Если вы не понимаете, что именно вы ищете при помощи pathping, то никак.

но не смог понять где именно проблема

Расскажите для начала, какую именно проблему вы наблюдаете? Медленно качаются файлы? Высокий пинг до какого-то хоста?

везде бездумно копируют и вставляют один и тот же пример,

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

1. Почему в таблице 2 столбца "Утер./Отпр.", а выводов 3;

Третий вывод (справа от него стоит символ |) показывает на предполагаемый процент "потерь" на линке/хопе между соответствующими хостами (37% между 9 и 10 хопами в вашем случае).

UPD:

1. Ищу конкретно к кому обращаться на тему дурно работающего оборудования, так как порядком надоели проблемы с интернетом.

"Дурно работающее оборудование", "проблемы с интернетом" - это какие-то расплывчатые формулировки. Есть интернет. Есть в нем некие сервисы. Вы, используя различные (это важно) протоколы передачи данных, получаете к этим сервисам доступ. Есть различные количественные и качественные характеристики качества предоставления доступа/сервиса. Например, вчера сайт загружался за 1 секунду, а сегодня - за 3. Или вчера файл качался со скоростью 2 МБ/с, сегодня - 0.5. Или телефония вчера работала приемлемо, а сегодня голос стал металлическим и звонки стали сбрасываться.

2. Проблема - потеря данных. А это нестабильность связи, проблемы с ошибками при просмотре онлайн видео и прочие мморпг например.

В случае использования протокола TCP (например, просмотр видео на Youtube) потери пакетов могут приводить к уменьшению эффективной скорости передачи данных. Различные ошибки ("невозможно открыть файл, повторите еще раз"), на мой взгляд, чаще связаны с различными проблемами CDN (сети распределения контента, грубо говоря, сети кэширующих серверов).

3й пункт не совсем я понял. Для диагностирования проблемы на конкретном участке утилита вполне пригодна и справляется лучше чем traceroute, я не ошибаюсь?

Не думаю, что уместно сравнивать pathping и traceroute. На моей машине, например (windows 7), pathping 8.8.8.8 не отображает хопы, входящие в AS Google, a tracert отображает. Больше всего для диагностики проблем с доступом к некому сервису, на мой взгляд, полезно посылать сообщения того же протокола (http head, tcp syn в случае с web, tcp syn в случае tcp, udp-сообщения в случае udp) и анализировать количественные (задержка, отношение количества ответов к количеству запросов) и качественные (наличие ответов как таковых) характеристики взаимодействия. Например, в случае доступа к web-странице вывод ping может быть малорелевантен.

4. Тогда я не понимаю, почему и между линком и на исходном узле присутствуют потери. Означает ли это, что проблемы на исходном узле на самом деле вызваны проблемой коммутации меж узлов?

я не знаю что такое конкретно исходный узел, что такое конкретно маршрутный узел

Если я правильно понял, в колонке "исходный узел" (не самый лучший перевод оригинального названия "source to here") приведены показатели потерь при отправлении icmp-запросов непосредственно на данный хост. В этом случае трафик, как правило, обрабатывается отдельным процессором (входящим в control plane). С целью защиты control plane от DoS-атак трафик до него ограничивается (control plane protection policy в оборудовании Cisco, встроенный полисер в оборудовании Juniper). В колонке "маршрутный узел" приведены (оценочные) показатели потерь, вносимых непосредственно линком между текущим хопом и следующим. Подробнее здесь.

Кроме того, на добавленном новом скриншоте видно, что:
До узла kzn наблюдается потеря, а затем потери наблюдаются преимущественно в колонках "Исходный узел", что как я понимаю, относится к проблеме конкретно этих узлов, что в случае яндекса я верить отказываюсь, а значит ставлю под сомнение достоверность моего понимания этих данных.

Мое мнение таково - "потери" до узла kzn02.transtelecom.net обусловлены именно защитой control plane соответсвующего устройства (Juniper MX-серии, как предположение).
Комментировать оценки (предполагаю, основанного на статистике) алгоритма pathping, не зная его в деталях , не могу. Рекомендую диагностировать возможные проблемы более реалистичными средствами.

Подскажите пожалуйста, как это можно реализовать,

На мой взгляд, проще всего это реализовать при помощи expect/pexpect. Следует (программно) залогиниться на каждое устройство, получить hostname (из приветствия или конфигурации), сформировать новую команду (snmp-server name ) и выполнить ее. Есть подозрение, что при помощи SNMP реализовать это будет затруднительно.
Если нужна дальнейшая помощь, хотя бы модели устройств и способ доступа на них (ssh/telnet) уточните.

Отвечу в порядке возрастания субъективной сложности вопроса.

И по каким протоколам они работают?

Для обмена маршрутами, как правило, используется BGPv4.

Кто в России владеет каналами интернета которые соединяют нас с Другими странами.

Один ли это провайдер?

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

Думаю, можно "отключить" (null route, на windows делается примерно так) маршрут по умолчанию. Для доступа к VPN-серверу, прописать до него специфичный статический маршрут (как упомянул kodi).

Во-первых, хорошо было бы узнать, откуда задача возникла, и какой смысл в ее решении (т.е. что вам даст/должно дать знание топологии). Трафик снимается из одной точки сети или из нескольких? Пример дампа можете привести?

Я предполагаю, что в сети используется IPv4, инкапсулированный в Ethernet. В таком случае, на мой взгляд, сначала имеет смысл построить граф взаимодействия Ethernet-хостов (аналог в wireshark: statistics -> conversations -> ethernet). Затем, для каждого ethernet-хоста (определяемого unicast MAC-адресом) ставите в соответствие IPv4-адрес инкапсулированного IPv4-пакета (MAC-адресу источника ставите в соответствие IPv4-адрес источника, аналогично с адресами назначения). У вас получается вид топологии сети из точки, в которой происходил захват трафика. На мой взгляд, если нужна топология всей сети, то и трафик захватывать надо с каждого L2-домена.

Каким образом можно создать аналогичный ресурс?

Если надо только показывать видео (без загрузки его на сервер, учета статистики, рекомендаций и прочего), то можно все сделать на коленке:
1) качаете видео
2) верстаете html-страничку с использованием тега video
3) раздаете все каким-либо веб-сервером
4) просите администраторов сети, чтобы какой-либо хостнейм (funny-video.lan, например) разрешался в ваш IP-адрес
5) ???
6) профит! - люди смотрят смешное видео (без регистрации и смс), не тратя деньги на внешний трафик.

Плюсы: дешево, сердито, быстро (см.скриншоты, потрачено минут 10), деревянно. Позволит оценить интерес публики без особых затрат.
Минусы: крайне ограниченная функциональность.

Если нужен функциональный клон youtube, поищите по ключевым словам "video sharing script", "video sharing cms" и прочая.
В любом случае, вам потребуются:
1) сервер в локальной сети, на котором все будет работать
2) соответствующая DNS-запись
3) запущенный веб-сервер, раздающий видео тем или иным образом (статика, стриминг)

Падение линка не падение интерфейса. Подскажите как можно выкрутиться не прибегая к протоколам BGP.

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

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

Очень краткая схема в первом комментарии выше.

Если я правильно понял, то можно (нужно?) изменять маршрут по умолчанию (т.е. маршрутизировать трафик на OPENVPNSERVER1 или OPENVPNSERVER2) на 3750 в зависимости от работоспособности тоннеля?

Когда трава была зеленее я видел использованиe route map в зависимости от пинга, но не запомнил и информации сейчас нет.

На мой взгляд, вам подойдет решение в виде статической маршрутизации вкупе с ip sla tracking. См. раздел Резервирование.
UPD2:

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

Я полагал, что хотя бы с одной стороны маршруты исчезают при нарушении работоспособности туннеля. Если нет, то остается RIPv2 (на 3 серверах с openvpn и на устройстве cisco).

При попытке добавить в транк 1 влан

Что именно делаете? Добавляете его тегированным/нетегированным (native)?

VLAN 1

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

Если все-таки нужен влан 1 в тегированном виде, попробуйте на нужном интерфейсе команду
switchport default-vlan tagged

как повесить ещё один айпи на этот же интерфейс

Если не ошибаюсь, ASA не поддерживает secondary ip, то есть никак. С другой стороны, почти наверняка вашу проблему (какую, кстати?) можно решить другим путем.

На мой взгляд, сеть довольно проста, требования не самые трудновыполнимые, но выбрать лучше 3550.
Плюсы:
- когда ваша сеть вырастет из одного L2-сегмента, 3550 можно будет переконфигурировать (используя его L3-возможности)
- больше "кнопочек и рычажков" - более разнообразный опыт настройки для вас

Единственное, если нужны гигабитные аплинки для связи между помещениями (в чем я сомневаюсь), то потребуется докупить модули.

По поводу HP ProCurve, мне запомнился менее удобный по сравнению с cisco/juniper cli-интерфейс и странная терминология (то, что я привык называть portchannel/etherchannel/aggregated ethernet, в терминах HP называется Trunk).

1) Можно ли на одном VPS расположить и сайт, и игровой сервер? Если да, тот каким образом?

Да, можно (хотя непонятно, зачем). Веб-сервер будет прослушивать tcp-порты, например, 80 и 443, а игровой сервер - свои (часто 2106, 7777 и т.д.). Также игровой сервер может использовать UDP-сокеты.

2) Что нужно, чтобы обеспечить защиту от атак на VPS?

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

И обеспечивает ли этой защитой хостер?

От высокоинтенсивных DDoS-атак (SYN-flood, UDP flood) хостер может защитить при наличии соответствующего оборудования. От L7-атак, эксплуатирующих нюансы игрового протокола, вряд ли.

3) Что нужно устанавливать на VPS, для нормальной работы сайта?

Как минимум, необходим веб-сервер (nginx, например). Остальное зависит от сайта.

и как побороть

Зачем? Из приведенного вами листинга наблюдается трафик в виде одного arp-запроса в секунду. Если это представляет значительную нагрузку для вашей сети, то вы, на мой взгляд, что-то делаете неправильно.

что это

Я небольшой знаток сетевой подсистемы Linux, но есть следующие мысли. Во-первых, стоит убедиться, что запросы отправляет именно шлюз (снять дамп трафика со шлюза, отфильтровав на время ARP-запросы извне). Во-вторых, стоит проверить, корректно ли создается соответствующая запись в arp-таблице шлюза при получении ответа. В-третьих, стоит поискать отличия между этим хостом и любым другим, для которого такого поведения не наблюдается. Есть предположение, что таким образом dhcp-сервер (если он активен на шлюзе) проверяет активность хоста и, следовательно, востребованность выданного хосту адреса.

скорость соединения в микротике определяется, как 100 full duplex.

Уточните, пожалуйста, скорость и дуплекс именно определяются автоматически или жестко заданы? На порту, подключенном к провайдеру, CRC-ошибок (иногда используется термин FCS) на входящих фреймах не наблюдается? Интерфейс ноутбука при подключении в каком режиме работает (100 мбит/c или 1 Гбит/c)? Если есть CRC-ошибки на порту Mikrotik и порт ноутбука работает на 1 гбит/c, то попробуйте на порту Mikrotik задать режим 1Гбит/с.