Ошибка сетевого интерфейса на терминале

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

Источник

6.2.4. Проверка работы сетевого интерфейса

6.2.4. Проверка работы сетевого интерфейса

Если вы не подняли (активировали) интерфейс в процессе графического конфигурирования, сделайте это сейчас. Перейдите на текстовую консоль или откройте окно терминала и выполните команду ifup eth0 (деактивировать интерфейс можно командой ifdown eth0).

Для получения сведений об активных интерфейсах выполните команду ifconfig. Она покажет примерно следующее:

eth0 Link encap:Ethernet HWaddr 00:02:F0:73:B0:85

inet addr:192.168.1.11 Beast:192.168.1.255

UP BROADCAST MULTICAST MTU:1500 Metric:1

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING MTU:16436 Metric:1

Интерфейс lo, которого вы не настраивали, — это интерфейс обратной петли. Не отключайте его, он необходим для работы некоторых приложений.

В первых двух строчках утилита ifconfig выводит тип (Ethernet) адаптера, его физический адрес (MAC-адрес) и присвоенный ему IP-адрес. Дальше — параметры интерфейса, указывающие, что он запушен и используется.

MTU (Maximum Transfer Unit) — максимальный размер единицы передачи данных. Практически все протоколы позволяют использовать в кадре поля переменной длины, это касается даже заголовка кадра. Максимально допустимое значение длины поля — это как раз и есть MTU.

Далее следует статистика — сколько пакетов принято/передано, сколько байтов принято/передано, сколько коллизий было с участием этого интерфейса.

Теперь проверим, как работает соединение. Это делают командой ping (пингуют нужный адрес).

Эта команда посылает на указанный адрес по протоколу ICMP маленький пакет, требующий эхо-ответа, раз за разом, пока не будет остановлена (например, нажатием комбинации клавиш Ctrl+). Обычно ею пользуются для проверки доступности узлов.

Потом пропингуйте свою машину по имени, которое вы ей дали: ping dhsilabs.

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

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

разделенные пробелами. Откройте этот файл в любом текстовом редакторе и добавьте туда сведения о машинах своей локальной сети. Символ # в этом файле понимается как знак комментария.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Читайте также

Проверка работы

Проверка работы Работоспособность механизма мониторинга ссылок можно проверить командами:#netamsctl show dshost: localhost port: 20001 login: anton password: aaacmd: show dsData–source type LIBPCAP source xl1:0 loop 82356480 average 35 mcsecPerf: average skew delay 2676 mcsec, PPS: 1060, BPS: 904985IP tree: 258 nodes [12] + 4 dlinks [1024] + 254 unodes [20] = 12272 bytesFlows: 1644/2507 act/inact entries

1.8. История сетевого обеспечения BSD

1.8. История сетевого обеспечения BSD API сокетов происходит от системы 4.2BSD (Berkeley Software Distribution — программное изделие Калифорнийского университета, в данном случае — адаптированная для Интернета реализация операционной системы Unix, разрабатываемая и распространяемая этим

4.13.2. Обход сетевого экрана

4.13.2. Обход сетевого экрана Сетевой экран не может обеспечить абсолютной безопасности, потому что алгоритм его работы несовершенен. В нашем мире нет ничего безупречного, стопроцентно надежного, иначе жизнь была бы скучной и неинтересной.Как Firewall защищает ваш компьютер

Настройка сетевого обнаружения

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

13.2.5. Тестирование сетевого соединения

13.2.5. Тестирование сетевого соединения Чтобы проверить, соединяется ли ваш компьютер с сетью, попробуйте дать команду ping, указав ей в качестве параметра IP-адрес одного из компьютеров сети. Пусть, например, вам известно (узнайте реальный номер и имя у администратора сети),

4.26 Совместное использование сетевого интерфейса

4.26 Совместное использование сетевого интерфейса Как уже отмечалось, несложно найти локальные и региональные сети, использующие одновременно несколько протоколов. На практике один сетевой узел иногда посылает и принимает данные по нескольким протоколам через единый

27.1.1.1. Уровень сетевого интерфейса

27.1.1.1. Уровень сетевого интерфейса Этот уровень лежит в основании всей модели протоколов семейства TCP/IP. Уровень сетевого интерфейса отвечает за отправку в сеть и прием из сети кадров, которые содержат информацию. Кадр (frame) — это единица данных, которыми обмениваются

Выбор сетевого размещения

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

Оптимизация сетевого трафика

Оптимизация сетевого трафика Как правило, сервер СУБД устанавливается не на одном компьютере вместе с клиентом, а используется через локальную сеть. При этом на времени отклика сервера сказываются задержки при передаче данных по сети, независимо от того, насколько

Настройки параметров работы сетевого экрана

Настройки параметров работы сетевого экрана Для активизации сетевого экрана достаточно нажать ссылку Включить на соответствующей вкладке. Окно настройки параметров можно вызвать нажатием кнопки Настройка внизу окна и выбором соответствующего пункта или из

Учет сетевого трафика

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

Настройка сетевого соединения

Настройка сетевого соединения Итак, у вас есть ноутбук, к которому просто подключен кабель локальной сети. Если в сети присутствует специальный компьютер с настроенными на нем DHCP[3]-сервером, то вам не придется специально устанавливать какие-либо параметры, поэтому

Настройка сетевого обнаружения

Настройка сетевого обнаружения Подсоединение к сети настроено, однако вы не можете видеть компьютеры в сети без дополнительной настройки сетевого окружения.Для этого вернитесь к окну управления сетями и общим доступом (см. рис. 14.7) и нажмите кнопку со стрелкой напротив

Настройка сетевого соединения

Настройка сетевого соединения Итак, у вас есть ноутбук, к которому подключен кабель локальной сети, и пока не произведены настройки. Следует отметить, что если в сети присутствует специальный компьютер с настроенным DHCP-сервером[43], то тогда вам вряд ли придется что-либо

Источник

Как решить некоторые проблемы в Linux

Вступление

Как известно, типичные РС-компьютеры собирают из весьма разношерстных компонентов — процессор от одного производителя, видеокарта от другого, звуковая карта от третьего. Темы про принтеры/сканеры/Wi-Fi адаптеры/TV-тюнеры просто кишат повсюду на форумах. Не добавляют оптимизма и вездесущие китайские производители, не особо-то стремящиеся к стандартизации. Перед операционной системой стоит непростая задача заставить работать согласованно все эти устройства.
Предлагаю вашему вниманию небольшой гайд по устранению типичных проблем в Linux.

Восстановление загрузчика

Как правило, загрузчики Linux достаточно дружелюбны в отношении других ОС, и при установке обнаруживают присутствие соседей на других разделах. А вот Windows при установке нагло затирает MBR своим загрузчиком, и прощай, линукс.
Не стоит рвать на себе волосы беспокоиться, для начала нужно подготовить ваш любимый LiveCD с линуксом. Теперь любой уважающий себя дистрибутив имеет свой LiveCD, но мне приглянулся %distrname%. Загружаетесь с диска, входите в терминал с правами рута и вводите следующую команду:

Если загрузка длится бесконечно

Во времена господства Windows 9x при загрузке линукса по экрану пробегали десятки строк, и можно было определить, на чём именно загрузка стопорится. Сейчас в моду вошли Splash-затычки, и определить, почему ваш любимый Ubuntu загружается вот уже 40 минут, невозможно. Для того, что бы отключить сплеш, при загрузке нажмите Shift (или что там предлагает ваш дистрибутив), станьте курсором на первую строку, нажмите E, перейдите курсором к строке, начинающейся на kernel и снова нажмите E. Удалите параметры quiet и splash. Если загрузка стопорится сразу, рекомендуется в эту строку добавить noapic, эта опция скажет ядру не использовать APIC. Далее нажмите Enter и B для начала загрузки.

В SUSE достаточно ввести в опциях загрузки splash=0.

Ну вот, загрузка пошла.

Далее ждёте сообщение об ошибке, и гуглите её текст.

Что там у меня в жужжащей коробке?

Bus 001 Device 004: ID 03f0:2c17 Hewlett-Packard
Bus 004 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Что бы узнать побольше о конкретном устройстве, есть опции -s и -v:

где непонятные символы 001:004 — адрес устройства из вывода команды lspci или lsusb.
Если вы испытываете страх при взгляде на мигающий курсор в терминале, то можно воспользоваться пакетом Hardinfo

Ох уж эти иксы

Довольно часто бывает, что после окончания начальной загрузки вы лицезреете чёрный экран. Что случилось? Возможно, слетел видеодрайвер. Разумеется, для не искушённого пользователя лучше воспользоваться драйверами из репозиториев. Для того, чтобы войти в ваш любимый Gnome или KDE для запуска менеджера пакетов, нажмите Ctrl-Alt-F1, и вы попадёте в терминал. Зайдите с правами рута, и заставьте ваш Xorg заюзать VESA драйвера: команда dpkg-reconfigure xserver-xorg для дебиана/убунту, yast2 для SUSE, а там выбираете VESA-совместимую видеокарту. Или nano /etc/X11/xorg.conf, ищете там слово intel, nvidia и подобное в секции Driver и меняете на vesa. Далее запускаем иксы: kdm или gdm или startxfce4 и т.д. (по вкусу). Если экран и дальше чёрный, прибиваете иксы с помощью Ctrl-Alt-Backspace и смотрите, где кошка зарыта: cat /var/log/Xorg.0.log | grep EE и гуглите текст ошибки.

Для начала поговорим о беспроводной сети. Проверьте наличие сети с помощью команды ifconfig. Естественно, ваша точка доступа должна быть включена и настроена. Если в выводе команды отсутствует интерфейс, названный ath0 или wlan0, то нужно что-то делать. Есть такие замечательные драйвера, как madwifi. Инструкцию по установке можно найти там же. Если они не помогли, вам возможно поможет такая утилита, как NDISwrapper. Этот костыль позволит использовать виндовые драйвера для адаптеров беспроводной сети в линуксе.

Далее попробуем поднять сеть:

sudo ifconfig wlan0 up
sudo iwlist wlan0 scan

Если на первую команду система ругается вроде «Interface Doesn’t Support Scanning», то вы неверно выбрали название интерфейса, или не тот драйвер. Вторая команда запустит поиск беспроводной сети.

Источник

Имитируем сетевые проблемы в Linux

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

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

Имитируем проблемы с сетью

Обычно ПО тестируется на тестовых серверах с хорошим интернет-каналом. В суровых условиях продакшена всё может быть не так гладко, поэтому иногда нужно проверять программы в условиях плохого соединения. В Linux с задачей имитации таких условий поможет утилита tc.

tc (сокр. от Traffic Control) позволяет настраивать передачу сетевых пакетов в системе. Эта утилита обладает большими возможностями, почитать про них подробнее можно здесь. Тут же я рассмотрю лишь несколько из них: нас интересует шедулинг трафика, для чего мы используем qdisc, а так как нам нужно эмулировать нестабильную сеть, то будем использовать classless qdisc netem.

Запустим echo-сервер на сервере (я для этого использовал nmap-ncat):

Для того чтобы детально вывести все таймстемпы на каждом шаге взаимодействия клиента с сервером, я написал простой скрипт на Python, который шлёт запрос Test на наш echo-сервер.

Запустим его и посмотрим на трафик на интерфейсе lo и порту 12345:

Всё стандартно: трёхстороннее рукопожатие, PSH/ACK и ACK в ответ дважды — это обмен запросом и ответом между клиентом и сервером, и дважды FIN/ACK и ACK — завершение соединения.

Задержка пакетов

Теперь установим задержку 500 миллисекунд:

Запускаем клиент и видим, что теперь скрипт выполняется 2 секунды:

Что же в трафике? Смотрим:

Можно увидеть, что во взаимодействии между клиентом и сервером появился ожидаемый лаг в полсекунды. Гораздо интереснее себя ведёт система, если лаг будет больше: ядро начинает повторно слать некоторые TCP-пакеты. Изменим задержку на 1 секунду и посмотрим трафик (вывод клиента я показывать не буду, там ожидаемые 4 секунды в total duration):

Видно, что клиент дважды посылал SYN-пакет, а сервер дважды посылал SYN/ACK.

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

Здесь мы задали задержку в промежутке от 100 до 900 миллисекунд, значения будут подбираться в соответствии с нормальным распределением и будет 50-процентная корреляция со значением задержки для предыдущего пакета.

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

Потеря пакетов

Попробуем теперь сделать потерю пакетов. Как видно из документации, осуществить это можно аж тремя способами: терять пакеты рандомно с какой-то вероятностью, использовать для вычисления потери пакета цепь Маркова из 2, 3 или 4 состояний или использовать модель Эллиота-Гилберта. В статье я рассмотрю первый (самый простой и очевидный) способ, а про другие можно почитать здесь.

Сделаем потерю 50% пакетов с корреляцией 25%:

К сожалению, tcpdump не сможет нам наглядно показать потерю пакетов, будем лишь предполагать, что она и правда работает. А убедиться в этом нам поможет увеличившееся и нестабильное время работы скрипта client.py (может выполниться моментально, а может и за 20 секунд), а также увеличившееся количество retransmitted-пакетов:

Добавление шума в пакеты

Помимо потери пакетов, можно имитировать их повреждение: в рандомной позиции пакета появится шум. Сделаем повреждение пакетов с 50-процентной вероятностью и без корреляции:

Запускаем скрипт клиента (там ничего интересного, но выполнялся он 2 секунды), смотрим трафик:

Видно, что некоторые пакеты отправлялись повторно и есть один пакет с битыми метаданными: options [nop,unknown-65 0x0a3dcf62eb3d,[bad opt]>. Но главное, что в итоге всё отработало корректно — TCP справился со своей задачей.

Дублирование пакетов

Что ещё можно делать с помощью netem? Например, сымитировать ситуацию, обратную потере пакетов, — дубликацию пакетов. Эта команда также принимает 2 аргумента: вероятность и корреляцию.

Изменение порядка пакетов

Можно перемешать пакеты, причём двумя способами.

В первом часть пакетов посылается сразу, остальные — с заданной задержкой. Пример из документации:

С вероятностью 25% (и корреляцией 50%) пакет отправится сразу, остальные отправятся с задержкой 10 миллисекунд.

Второй способ — это когда каждый N-й пакет отсылается моментально с заданной вероятностью (и корреляцией), а остальные — с заданной задержкой. Пример из документации:

Каждый пятый пакет с вероятностью 25% будет отправлен без задержки.

Изменение пропускной способности

Обычно везде отсылаются к TBF, но с помощью netem тоже можно изменить пропускную способность интерфейса:

Эта команда сделает походы по localhost такими же мучительными, как серфинг в интернете через dial-up-модем. Помимо установки битрейта, можно также эмулировать модель протокола канального уровня: задать оверхед для пакета, размер ячейки и оверхед для ячейки. Например, так можно сымитировать ATM и битрейт 56 кбит/сек.:

Имитируем connection timeout

Ещё один важный пункт в тест-плане при приёмке ПО — таймауты. Это важно, потому что в распределённых системах при отключении одного из сервисов остальные должны вовремя сфоллбэчиться на другие или вернуть ошибку клиенту, при этом они ни в коем случае не должны просто зависать, ожидая ответа или установления соединения.

Есть несколько способов сделать это: например, использовать мок, который ничего не отвечает, или подключиться к процессу с помощью дебаггера, в нужном месте поставить breakpoint и остановить выполнение процесса (это, наверное, самый извращённый способ). Но один из самых очевидных — это фаерволлить порты или хосты. С этим нам поможет iptables.

Для демонстрации будем фаерволлить порт 12345 и запускать наш скрипт клиента. Можно фаерволлить исходящие пакеты на этот порт у отправителя или входящие на приёмнике. В моих примерах будут фаерволлиться входящие пакеты (используем chain INPUT и опцию —dport). Таким пакетам можно делать DROP, REJECT или REJECT с TCP флагом RST, можно с ICMP host unreachable (на самом деле дефолтное поведение — это icmp-port-unreachable, а ещё есть возможность послать в ответ icmp-net-unreachable, icmp-proto-unreachable, icmp-net-prohibited и icmp-host-prohibited).

При наличии правила с DROP пакеты будут просто «исчезать».

Запускаем клиент и видим, что он зависает на этапе подключения к серверу. Смотрим трафик:

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

Сразу удаляем правило:

Можно удалить сразу все правила:

Если вы используете Docker и вам нужно зафаерволлить весь трафик, идущий на контейнер, то сделать это можно следующим образом:

REJECT

Теперь добавим аналогичное правило, но с REJECT:

Клиент завершается через секунду с ошибкой [Errno 111] Connection refused. Смотрим трафик ICMP:

Видно, что клиент дважды получил port unreachable и после этого завершился с ошибкой.

REJECT with tcp-reset

Попробуем добавить опцию —reject-with tcp-reset:

В этом случае клиент сразу выходит с ошибкой, потому что на первый же запрос получил RST пакет:

REJECT with icmp-host-unreachable

Попробуем ещё один вариант использования REJECT:

Клиент завершается через секунду с ошибкой [Errno 113] No route to host, в ICMP трафике видим ICMP host 127.0.0.1 unreachable.

Можете также попробовать остальные параметры REJECT, а я остановлюсь на этих 🙂

Имитируем request timeout

Еще одна ситуация — это когда клиент смог подключиться к серверу, но не может отправить ему запрос. Как отфильтровать пакеты, чтобы фильтрация началась как бы не сразу? Если посмотреть на трафик любого общения между клиентом и сервером, то можно заметить, что при установлении соединения используются только флаги SYN и ACK, а вот при обмене данными в последнем пакете запроса будет флаг PSH. Он устанавливается автоматически, чтобы избежать буферизации. Можно использовать эту информацию для создания фильтра: он будет пропускать все пакеты, кроме тех, которые содержат флаг PSH. Таким образом, соединение будет устанавливаться, а вот отправить данные серверу клиент не сможет.

Для DROP команда будет выглядеть следующим образом:

Запускаем клиент и смотрим трафик:

Видим, что соединение установлено, и клиент не может послать данные серверу.

REJECT

В этом случае поведение будет таким же: клиент не сможет отправить запрос, но будет получать ICMP 127.0.0.1 tcp port 12345 unreachable и увеличивать время между переотправкой запроса по экспоненте. Команда выглядит так:

REJECT with tcp-reset

Команда выглядит следующим образом:

Мы уже знаем, что при использовании —reject-with tcp-reset клиент получит в ответ RST-пакет, поэтому можно предугадать поведение: получение RST-пакета при установленном соединении означает непредвиденное закрытие сокета с другой стороны, значит, клиент должен получить Connection reset by peer. Запускаем наш скрипт и удостоверяемся в этом. А вот так будет выглядеть трафик:

REJECT with icmp-host-unreachable

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

Вывод

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

Рассмотренные в статье утилиты обладают ещё большим количеством возможностей, чем было описано, поэтому вы можете придумать какие-то свои варианты их использования. Лично мне всегда хватает того, про что я написал (на самом деле даже меньше). Если вы используете эти или подобные утилиты в тестировании в своей компании, напишите, пожалуйста, как именно. Если же нет, то надеюсь, ваше ПО станет качественней, если вы решите проверять его в условиях проблем с сетью предложенными способами.

Источник