1) http://docs.fortinet.com/fgt
2) http://docs.fortinet.com/fgt/
3) http://docs.fortinet.com/fgt/index.htm
4) http://docs.fortinet.com/fgt/index.html
5) http://docs.fortinet.com/fgt/index.php
Go!
1.
2.
3.
4.
5.
среда, 27 апреля 2011 г.
HTTP Errors Zoo
Let's look at 5 different URLs below and enjoy 5 different error messages.
1) http://docs.fortinet.com/fgt
2) http://docs.fortinet.com/fgt/
3) http://docs.fortinet.com/fgt/index.htm
4) http://docs.fortinet.com/fgt/index.html
5) http://docs.fortinet.com/fgt/index.php
Go!
1.
2.
3.
4.
5.
1) http://docs.fortinet.com/fgt
2) http://docs.fortinet.com/fgt/
3) http://docs.fortinet.com/fgt/index.htm
4) http://docs.fortinet.com/fgt/index.html
5) http://docs.fortinet.com/fgt/index.php
Go!
1.
2.
3.
4.
5.
понедельник, 14 июня 2010 г.
Поломаный ext3-раздел и Acronis
В процессе миграции с NTFS на ext3 неаккуратно обошелся я с одним разделом. Точнее, в KDE Partition Manager'е решил испытать опцию "Move". Получил сообщение об ошибке... и 2 пустых раздела вместо пустого пространства и исходного раздела.
Попробовал разобраться с testdisk: инструмент интересный, нашел разные мертвые файловые системы, но то ли не сумел найти следы моего раздела, то ли я это не увидел...
Попробовал photorec из того же пакета: запустил на пустом пространстве, много файлов восстановилось, но не все корректно, плюс исходные названия потерялись.
В планах было еще воспользоваться gpart - старый инструмент, но отзывы хорошие.
Потратив полдня решил идти по пути наименьшего сопротивления: загрузился в винду, запустил Acronis Disk Director Suite и на пустом пространстве (где были данные) включил Recovery в быстром режиме. Он просканировал диск, нашел видимо бэкапные записи 2 файловых систем - успешно удаленной ранее NTFS и нечаянно поломаной ext3.
Применил изменения и вуаля! Раздел и данные снова на месте.
Попробовал разобраться с testdisk: инструмент интересный, нашел разные мертвые файловые системы, но то ли не сумел найти следы моего раздела, то ли я это не увидел...
Попробовал photorec из того же пакета: запустил на пустом пространстве, много файлов восстановилось, но не все корректно, плюс исходные названия потерялись.
В планах было еще воспользоваться gpart - старый инструмент, но отзывы хорошие.
Потратив полдня решил идти по пути наименьшего сопротивления: загрузился в винду, запустил Acronis Disk Director Suite и на пустом пространстве (где были данные) включил Recovery в быстром режиме. Он просканировал диск, нашел видимо бэкапные записи 2 файловых систем - успешно удаленной ранее NTFS и нечаянно поломаной ext3.
Применил изменения и вуаля! Раздел и данные снова на месте.
воскресенье, 23 мая 2010 г.
"Селективная" виртуализация
Хочется сделать такую схему виртуализации на домашнем компьютере (он же медиа-центр и сервер):
1. Гипервизор
2. Гостевая (guest OS) Windows
3. Гостевая Linux
Здесь всё как обычно.
Что необычного?
Хочется запускать windows в виртуальной мешине и в то же время иметь близкую к нативной 2D/3D-производительность и вывод на физический дисплей.
В винде запускаются игры, поэтому нужно выделить или пробросить в гостевую win
- видеокарту - плюс с нее уходит и звук по HDMI;
- USB-порт - через него работает приемник беспроводных клавы и мыши.
Я пока вижу 2 варианта:
1. Искать информацию, читать интернет - основной вариант
2. Проверить производительность VirtualBox, благо на ноутбуке он есть. Запустить не самую новую игру типа GTA San Andreas и посмотреть.
1. Гипервизор
2. Гостевая (guest OS) Windows
3. Гостевая Linux
Здесь всё как обычно.
Что необычного?
Хочется запускать windows в виртуальной мешине и в то же время иметь близкую к нативной 2D/3D-производительность и вывод на физический дисплей.
В винде запускаются игры, поэтому нужно выделить или пробросить в гостевую win
- видеокарту - плюс с нее уходит и звук по HDMI;
- USB-порт - через него работает приемник беспроводных клавы и мыши.
Я пока вижу 2 варианта:
1. Искать информацию, читать интернет - основной вариант
2. Проверить производительность VirtualBox, благо на ноутбуке он есть. Запустить не самую новую игру типа GTA San Andreas и посмотреть.
воскресенье, 11 апреля 2010 г.
Тестируем пропускную способность WiFi с iPerf
Intro
Есть беспроводная сеть. Но скорость передачи файлов бывает падает до 700 кБ/с и ниже. Так что захотелось выяснить, в чем дело: где узкое место и кого давит жаба.
Вероятные источники проблемы:
- Интерференция
- Другой трафик
- Ноутбук или точка ASUS WL-500W: неудачаная реализация/драйверы/система
Для проверки этих гипотезы подойдет iPerf - открытый и бесплатный инструмент для тестирования пропускной способности сети. Работает под Linux и Windows (здесь), интерфейс - командная строка (отмечу, что есть еще jPerf - переписан на Java и с графическим интерфейсом).
В Debian устанавливается через:
apt-get install iperf
Запуск
Одна сторона - сервер: iperf -s
Другая сторона - клиент: iperf -c Server_IP
При этом iperf замеряет пропускную способность по TCP от клиента к серверу. Для полудуплексной беспроводной сети это и нужно, трафик идет от беспроводного клиента (ноутбук) через точку доступа к компьютеру в обычной сети.
В других случаях может быть полезной опция -d (Do a bidirectional test simultaneously).
В ходе тестов удалось посмотреть как ведет себя сеть и убедиться, что действительно в разное время пропускная способность разная.
Нормальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 33344 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 5.0-10.0 sec 12.9 MBytes 21.7 Mbits/sec
[ 3] 10.0-15.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 15.0-20.0 sec 13.3 MBytes 22.3 Mbits/sec
[ 3] 0.0-20.0 sec 52.5 MBytes 22.0 Mbits/sec
Как видно, при теоретическом пороге для полудуплексного 802.11g в 27 Мбит/c мы получаем приемлемое значение около 22-23 Мбит/c. Передача файла по SMB с линукс-станции на виндовую шару в такое время выдает 2 Мбайт/c = 16 Мбит/с, что кажется приемлемым, учитывая болтливость протокола SMB.
Аномальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 37460 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 12.7 MBytes 21.3 Mbits/sec
[ 3] 5.0-10.0 sec 10.1 MBytes 16.9 Mbits/sec
[ 3] 10.0-15.0 sec 6.71 MBytes 11.3 Mbits/sec
[ 3] 15.0-20.0 sec 2.33 MBytes 3.91 Mbits/sec
[ 3] 0.0-20.5 sec 31.8 MBytes 13.0 Mbits/sec
Что-то происходит и скорость начинает падать. Вот продолжение:
[ 3] 0.0- 5.0 sec 4.71 MBytes 7.90 Mbits/sec
[ 3] 5.0-10.0 sec 5.09 MBytes 8.53 Mbits/sec
[ 3] 10.0-15.0 sec 3.92 MBytes 6.58 Mbits/sec
[ 3] 15.0-20.0 sec 6.41 MBytes 10.7 Mbits/sec
Отключение домашней сети (плоская сеть с сотней компьютеров) ситуацию не меняет.
Остаются варианты:
а) интерференция - микроволновки и т.п.
б) левый трафик в беспроводной сети: нужно при случае перевести карточку в monitor mode и посмотреть, что там бегает.
Диагностика в режиме UDP
А пока я успел перевести iperf в режим работы через UDP и пронаблюдал следующую интересную картину.
sk@hal:~$ iperf -i 5 -t 300 -c 192.168.0.65 -u -b 25m
------------------------------------------------------------
Client connecting to 192.168.0.65, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 35797 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 9.81 MBytes 16.5 Mbits/sec
[ 3] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec
[ 3] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec
[ 3] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec
[ 3] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec
Т.е. удалось запечатлеть момент когда закончилась "яма" и скорость снова вышла на нормальный уровень.
На самом деле тестирование по UDP в случае беспроводной сети позволяет заглянуть еще дальше и точнее понять происходящее. Вот выходные данные на стороне сервера:
H:\soft\Network\iPerf, jPerf>iperf -s -i 5 -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
[1928] local 192.168.0.65 port 5001 connected with 192.168.0.63 port 35797
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1928] 0.0- 5.0 sec 9.84 MBytes 16.5 Mbits/sec 0.602 ms 0/ 7022 (0%)
[1928] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec 0.600 ms 0/10521 (0%)
[1928] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec 0.591 ms 0/ 4684 (0%)
[1928] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec 0.590 ms 0/10609 (0%)
[1928] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec 0.586 ms 0/10638 (0%)
Видно что потерь пакетов нет. UDP, как известно, протокол без потверждения доставки; в отличии от TCP он не может адаптироваться к заторам в сети; UDP-клиент (в нашем случае iperf) отсылает трафик с возможной для него скоростью (для iperf выставлено 25 Мбит/c).
Но мы видим, что в "яме" скорость отправки составляла 16.5 Мбит/с и даже 11.0 Мбит/с. Вместе с тем, нет сброшенных пакетов и ошибок, в сети ничего не потерялось. Значит, что-то не давало клиенту возможности отправлять трафик в сеть с большей скоростью. Что это?
Это - механизм контроля доступа к беспроводной среде - CSMA/CA (Carrier sense multiple access with collision avoidance). Он мониторит среду и обнаруживает, что какая-то станция уже передает трафик, и не позволяет отправить фрейм в этот момент.
Т.е. тест показывает, что в беспроводной сети присутствует некий "левый" (с моей точки зрения) трафик; остается его идентифицировать и принять меры по лечению...
Что касается iPerf, он снова хорошо показал себя: легкий, удобный и удивительно полезный инструмент.
воскресенье, 13 сентября 2009 г.
WPA2 на Windows XP SP2
Кто-то может сказать, что тема WiFi под Windows XP SP2 сейчас не актуальна. В общем да, но среди домашних машин вполне можно встретить и более древние экземпляры ОС от M$. Так к чему это я?
Часть первая, практическая.
Исходное состояние дел:
Хоть при автоопределении сети, хоть при ручном задании - коннекта нет. "Не-не-не!" - отвечает винда. Подключение не устанавливается, и после каждой попытки сваливаются настройки аутентификации с WPA Pre-shared key на 802.1X (TLS/PEAP).
Следующим шагом обновил драйвер (был за 2006 год) - и что же? "Не-не-не!" - опять говорит мне винда: "Windows is unable to connect to the selected network. The network may no longer be in range. Please refresh the list of available networks, and try to connect again". Но настройки уже не слетают.
Дальше в помощь google. Выяснилось, что Win XP SP2 не поддерживает WPA2. Вот только тогда я вспомнил, что WPA != WPA2 : )
И после установки фикса KB893357 ноут стал нормально коннектиться к сетке с WPA2.
Часть вторая, теоретическая.
Вопрос отчасти риторический. Почему ноутбук без поддержки WPA2 пытается подключиться к сети с защитой WPA2 и ведет себя неадекватно: соединение выдает ошибку или просто тихо не устанавливается, вместо того, чтобы указать - "неподдерживаемый протокол"?
На момент создания Win XP SP2 было 2 механизма защиты wireless сетей:
- на базе WEP (включая полностью открытую сеть с отсутствием защиты)
- на базе WPA.
WPA - это по сути ранняя и облегченная версия стандарта 802.11i.
WPA2 - это уже полноценный 802.11i 2004 года.
Как известно, типичная практика (и не только в сетях): включать в протокол версионность.
WPA и WPA2 - ранняя и финальная реализации 802.11i соответственно - согласно стандарту включают в поле version значение 1. Таким образом, тупо проверить версию и уведомить пользователя о неподдерживаемом протоколе не получится. Нужно проводить дальнейший разбор.
Если разработчики Win XP SP2 действовали по принципу: "всё что не WEP - то WPA" - становится понятным, что начиная с какого-то момента в процессе аутентификации станция продолжает действовать согласно WPA, тогда как точка доступа ожидает поведения в стиле WPA2. Точка доступа тихо отбрасывает несоответствующие кадры, станция продолжает их отсылать - и по истечении таймаута пользователь получает сообщение: "Товарищ, сеть больше не видна". Что и наблюдалось на практике.
И в догонку пара ссылок: wiki про WPA, стандарт IEEE 802.11i.
Часть первая, практическая.
Исходное состояние дел:
- работает домашняя точка доступа ASUS WL-500W, включен WPA2-PSK
- 2 ноутбука подключаются нормально (Win XP)
Хоть при автоопределении сети, хоть при ручном задании - коннекта нет. "Не-не-не!" - отвечает винда. Подключение не устанавливается, и после каждой попытки сваливаются настройки аутентификации с WPA Pre-shared key на 802.1X (TLS/PEAP).
Следующим шагом обновил драйвер (был за 2006 год) - и что же? "Не-не-не!" - опять говорит мне винда: "Windows is unable to connect to the selected network. The network may no longer be in range. Please refresh the list of available networks, and try to connect again". Но настройки уже не слетают.
Дальше в помощь google. Выяснилось, что Win XP SP2 не поддерживает WPA2. Вот только тогда я вспомнил, что WPA != WPA2 : )
И после установки фикса KB893357 ноут стал нормально коннектиться к сетке с WPA2.
Часть вторая, теоретическая.
Вопрос отчасти риторический. Почему ноутбук без поддержки WPA2 пытается подключиться к сети с защитой WPA2 и ведет себя неадекватно: соединение выдает ошибку или просто тихо не устанавливается, вместо того, чтобы указать - "неподдерживаемый протокол"?
На момент создания Win XP SP2 было 2 механизма защиты wireless сетей:
- на базе WEP (включая полностью открытую сеть с отсутствием защиты)
- на базе WPA.
WPA - это по сути ранняя и облегченная версия стандарта 802.11i.
WPA2 - это уже полноценный 802.11i 2004 года.
Как известно, типичная практика (и не только в сетях): включать в протокол версионность.
WPA и WPA2 - ранняя и финальная реализации 802.11i соответственно - согласно стандарту включают в поле version значение 1. Таким образом, тупо проверить версию и уведомить пользователя о неподдерживаемом протоколе не получится. Нужно проводить дальнейший разбор.
Если разработчики Win XP SP2 действовали по принципу: "всё что не WEP - то WPA" - становится понятным, что начиная с какого-то момента в процессе аутентификации станция продолжает действовать согласно WPA, тогда как точка доступа ожидает поведения в стиле WPA2. Точка доступа тихо отбрасывает несоответствующие кадры, станция продолжает их отсылать - и по истечении таймаута пользователь получает сообщение: "Товарищ, сеть больше не видна". Что и наблюдалось на практике.
И в догонку пара ссылок: wiki про WPA, стандарт IEEE 802.11i.
Подписаться на:
Сообщения (Atom)