Авторизация пользователей на Cisco ASA5510

Классическая авторизация пользователей. Пример конфигурации Cisco ASA5510.

Предисловие

Это третья часть статьи, посвященной применению авторизации для выборочного ограничения доступа пользователей к сетевым ресурсам и сервисам. Здесь рассматривается конфигурация ASA5510 .

Конфигурация

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

[cc lang=»bash»]
!
hostname firewall1
!
! — Список серверов —
names
name 192.168.1.100 FTP_server_1
name 192.168.1.101 FTP_server_2
name 192.168.1.102 TS_server
name 192.168.1.103 DMZ_DB_server
name 10.1.1.10 OUT_DB_server
!
!
interface Management0/0
shutdown
nameif management
security-level 100
management-only
no ip address
!
interface Ethernet0/0
description OUT
speed 100
duplex full
nameif outside
security-level 0
ip address 10.1.1.250 255.255.255.0
no shutdown
!
interface Ethernet0/1
description DMZ
speed 100
duplex full
nameif DMZ
security-level 50
ip address 192.168.1.254 255.255.255.0
no shutdown
!
interface Ethernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
!
!
! — Список сетевых групп —
object-group network DMZ_net
network-object 192.168.1.0 255.255.255.0
object-group network FTP_servers
network-object host FTP_server_1
network-object host FTP_server_2
!
!
access-list OUT_IN remark ***OUT->DMZ***
access-list OUT_IN remark ***ftp traffic to FTP servers***
access-list OUT_IN extended permit tcp any object-group FTP_servers eq ftp
access-list OUT_IN extended permit tcp any object-group FTP_servers eq ftp-data
access-list OUT_IN remark ***RDP traffic to DMZ servers***
access-list OUT_IN extended permit tcp any object-group DMZ_net eq 3389
access-list OUT_IN remark ***DB traffic between DB servers***
access-list OUT_IN extended permit tcp host OUT_DB_server host DMZ_DB_server eq 1526
access-list OUT_IN remark ***Virtual Telnet for Authentication*** access-list OUT_IN extended permit tcp any host 10.2.2.2 eq https
access-list OUT_IN extended deny ip any any log
!
!
access-list DMZ_IN remark ***DMZ->OUT***
access-list DMZ_IN remark ***ftp traffic from FTP servers***
access-list DMZ_IN extended permit tcp object-group FTP_servers eq ftp any
access-list DMZ_IN extended permit tcp object-group FTP_servers eq ftp-data any
access-list DMZ_IN remark ***RDP traffic from DMZ servers***
access-list DMZ_IN extended permit tcp object-group DMZ_net eq 3389 any
access-list DMZ_IN remark ***DB traffic between DB servers***
access-list DMZ_IN extended permit tcp host DMZ_DB_server eq 1526 host OUT_DB_server
access-list DMZ_IN remark ***Virtual Telnet for Authentication*** access-list DMZ_IN extended permit tcp host 10.2.2.2 eq https any
access-list DMZ_IN extended deny ip any any log
!
!
logging enable
logging buffered informational
!
!
! — NAT не используем, —
! — адреса транслируются сами в себя —
nat (DMZ) 0 192.168.1.0 255.255.255.0
static (outside,DMZ) 10.1.1.0 10.1.1.0 netmask 255.255.255.0
! — Без этой строки WEB страница аутентификации не откроется —
static (outside,DMZ) 10.2.2.2 10.2.2.2 netmask 255.255.255.255
!
!
access-group OUT_IN in interface outside
access-group DMZ_IN in interface DMZ
route outside 0.0.0.0 0.0.0.0 10.1.1.254 1
timeout xlate 4:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
! — Определяем таймаут аутентификации —
timeout uauth 4:00:00 absolute
!
!
! — Указываем TACACS+ сервер —
aaa-server ACS_1 protocol tacacs+
aaa-server ACS_1 (DMZ) host 192.168.1.4
key test
!
! — Для управления фаерволом потребуется —
! — аутентифицироваться на TACACS+ сервере. —
! — Если TACACS+ сервер не доступен, —
! — можно зайти локальным пользователем. —
aaa authentication serial console ACS_1 LOCAL
aaa authentication enable console ACS_1 LOCAL
aaa authentication ssh console ACS_1 LOCAL
!
!
! — Говорим, что весь входящий с наружи трафик —
! — требует аутентификации. —
aaa authentication include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1
! — Исключение для трафика серверов БД —
aaa authentication exclude tcp/1526 outside DMZ_DB_server 255.255.255.255 OUT_DB_server 255.255.255.255 ACS_1
!
!
! — Говорим, что весь входящий с наружи трафик —
! — требует авторизации. —
aaa authorization include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1
! — Исключение для трафика серверов БД —
aaa authorization exclude tcp/1526 outside DMZ_DB_server 255.255.255.255 OUT_DB_server 255.255.255.255 ACS_1
!
!
! — Без этой строки WEB страница аутентификации не откроется —
aaa authentication include https outside 10.2.2.2 255.255.255.255 0.0.0.0 0.0.0.0 ACS_1
aaa proxy-limit 128
!
! — Без этой строки WEB страница аутентификации —
! — будет иметь намного худший вид —
aaa authentication listener https outside port 1443 redirect
! — Указываем виртуальный адрес WEB страницы аутентификации —
virtual telnet 10.2.2.2
telnet timeout 5
ssh 10.1.1.0 255.255.255.0 outside
ssh timeout 5
ssh version 2
console timeout 5
!
no threat-detection basic-threat
no threat-detection statistics access-list
ssl encryption des-sha1 rc4-md5
!
! — Локальный пользователь для управления —
! — фаерволом на случай, когда —
! — TACACS+ сервер не доступен, —
username admin1 password test privilege 15
!
!
[/cc]
Комментарий к конфигурации

aaa-server ACS_1 protocol tacacs+ aaa-server ACS_1 (DMZ) host 192.168.1.4 key test

Этими строками мы говорим фаерволу, что AAA сервером является TACACS+ сервер, указываем его ip адрес и ключ.

aaa authentication include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1 aaa authorization include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1

Здесь говорим, что весь трафик, приходящий на интерфейс outside должен пройти аутентификацию и авторизацию.

aaa authentication exclude tcp/1526 outside DMZ_DB_server 255.255.255.255 OUT_DB_server 255.255.255.255 ACS_1 aaa authorization exclude tcp/1526 outside DMZ_DB_server 255.255.255.255 OUT_DB_server 255.255.255.255 ACS_1

Делаем исключение для трафика серверов БД. Этот трафик должен проходить без аутентификации и авторизации.

Virtual Telnet

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

Когда пользователь открывает HTTP, HTTPS, FTP и Telnet сессию, требующую аутентификации или авторизации, у него в браузере или в окне FTP или Telnet сессии появляется приглашение для ввода логина и пароля. Когда пользователь пытается открыть сессию по другим портам, например RDP соединение, предложение для ввода пароля не появляется, сессия закрывается по таймауту, а в логе фаервола появится запись “User must authenticate before using this service”.

Прежде чем открывать RDP сессию, пользователь должен авторизоваться на фаерволе. Но как это сделать? Где вводить логин и пароль? Для этого и нужен Virtual Telnet.

Несмотря на название, это совсем не telnet. Это дополнительная https сессия. Для пользователя процесс аутентификации выглядит следующим образом:

Пользователь запускает браузер и набирает в строке адреса https://10.2.2.2.

После подтверждения доверия сертификату, откроется следующее окно.

Обратите внимание, что изначально открывалась страница с адресом 10.2.2.2. А теперь ASA перенаправила пользователя на реальный ip адрес — 10.1.1.250. Подробнее об этом — чуть ниже.

Для продолжения надо нажать кнопку «Log in now».

В следующем окне надо ввести логин и пароль и нажать кнопку «Continue».

Если на фаерволе и ACS сервере все настроено корректно, и пользователь верно ввел логин с паролем, откроется страница как на следующем рисунке.

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

Явно разлогиниваться не обязательно. Если в течении определенного времени все соединения открытые пользователем простаивают, фаервол сам закроет авторизацию.

Тайм аут определяется командой :

timeout uauth 4:00:00 absolute

Если пользователь логинился несколько часов назад, и теперь сомневается действтельна ли его ранее открытая регистрация или нет, он должен открыть страницу аутентификации. Там он увидит свой статус.

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

virtual telnet 10.2.2.2

Здесь указан виртуальный ip адрес страницы аутентификации. Именно его пользователи набирают в адресной строке браузера. Точнее они должны набрать https://10.2.2.2. Https страница загружается с фаервола. Для повышения безопасности используется не реальный ip адрес интерфейса фаервола, а виртуальный.

Это адрес надо указать в нескольких местах в конфигурации фаервола. В аксес листах должен быть открыт https трафик на виртуальный адрес страницы аутентификации.

access-list OUT_IN extended permit tcp any host 10.2.2.2 eq https access-list DMZ_IN extended permit tcp host 10.2.2.2 eq https any

Кроме того, для этого адреса надо явно прописать команду :

aaa authentication include https outside 10.2.2.2 255.255.255.255 0.0.0.0 0.0.0.0 ACS_1

Это надо сделать обязательно, даже не смотря на то, что есть команда

aaa authentication include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1

покрывающая все адресное пространство.

Ну и последняя строка:

aaa authentication listener https outside port 1443 redirect

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

Настройка авторизации пользователей на Cisco Secure ACS

Пример настройки классической авторизации пользователей на Cisco Secure ACS v4.0.

Настройка Cisco Secure ACS

Наша задачи:

  • создать AAA клиента, использующего TACACS+ аутентификацию
  • создать две группы пользователей с нужными свойствами

Этот раздел статьи содержит много рисунков и мало текста. Действительно, удобнее все увидеть на картинке, чем долго читать описание.

Настройка AAA клиента

Начинаем с того, что добавляем AAA клиента на ACS сервере.

Для этого открываем страницу Network Configuration.

Добавляем AAA клиента. В Блоке AAA Clients нажимаем Add Entry.

Заполняем поля как на рисунке и нажимаем Submit + Apply.

В итоге получаем следующую картину.

На странице Interface Configuration появилась строка со ссылкой TACACS+ ( Cisco IOS ). Нажимаем ее.

Проверяем, что флажок рядом Shell ( exec ) установлен. В противном случае нужные нам поля не отобразятся в свойствах групп.

Настройка группы обычных пользователей.

Создадим и настроим группу для рядовых пользователей. Напомню, что им требуется ftp трафик к двум FTP серверам и RDP трафик к терминальному серверу.

На странице Group Setup выбираем нужную группу и нажимаем кнопку Edit Settings.

В блоке TACACS+ Settings / Shell Command Authorization Set устанавливаем переключатели и заполняем поля согласно следующему рисунку.

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

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

Итак, сохраняем изменения, нажав Submit + Apply.

Снова открываем свойства редактируемой группы. Как Вы можете заметить, в блоке Shell Command Authorization Set появились поля для новых правил. Заполняем их в соответствии со следующим рисунком и нажимаем Submit + Apply.

Осталось только добавить пользователей в группу.

На странице User Setup находим нужного пользователя и в его свойствах указываем нужную группу.

Настройка группы администраторов серверов.

Администраторам нужен такой же, как у пользователей, FTP доступ, плюс RDP доступ ко всем серверам.

Настройки в той части, которая касается ftp трафика, совпадает на 100%. Во второй части, в поле аргумент в последнем октете адреса вместо цифры ставим «*». Таким образом, мы указали вместо одного адреса всю сеть 192.168.1.0/24.

Другие небольшие хитрости, которые нам не потребовались в этом примере, но могут Вам пригодиться :

— Можно указывать диапазон портов. Строка команды тогда будет выглядеть так: tcp/10000-10007.

— Чтобы открыть все порты, поставьте после черты “0”, например udp/0.

Так же добавим во вторую группу нужных пользователей.

Теперь все, что требовалось сделать на AAA сервере, выполнено.

Комментарий в заключении

Если Вы заметили, мы по-разному описали RDP и ftp трафики. Дело в том, что HTTP, HTTPS, FTP и Telnet трафик описываются явно. Т. е. в поле “Command” надо написать http или https или ftp или telnet. Для всех других портов требуется указывать комбинацию из названия протокола и номера порта, разделенных чертой, например tcp/3389 или udp/53. Но если вы напишете tcp/80, HTTP трафик не пройдет. Надо писать http. Тоже самое для HTTPS, FTP и Telnet. Но и это еще не все. Если нужно описать ICMP трафик, придется писать “1/8” для эхо запросов и “1/0” для эхо ответов. Как Вы, наверное, знаете, у каждого протокола есть свой номер: tcp=6, udp=17, icmp=1 и т. д. Как это не смешно, но если описать, например, RDP трафик через 6/3389, то такой вариант тоже работать не будет.

Как это не удивительно, но описать весь нужный трафик в одном формате не удается. Не могу сказать, в чем здесь причина. Возможно в более свежих версиях Cisco Secure ACS все намного лучше.

Использование авторизации пользователей на Cisco ASA для ограничения доступа к сетевым ресурсам

Использование авторизации пользователей на фаерволе Cisco ASA для ограничения доступа к сетевым ресурсам.

Предисловие

Иногда возникает необходимость ограничить доступ к выборочным сетевым ресурсам и сервисам для определенных пользователей. Особенностью такой задачи является то, пользователи используют динамически меняющиеся ip адреса. Следовательно, нужно контролировать не ip адрес компьютера, с которого выполняется соединение, а идентификатор самого пользователя. О том, как это сделать с помощью Cisco ASA и Cisco Secure ACS рассказано в этой статье.

Общая информация

Для решения задачи требуется AAA сервер и фаервол Cisco ASA.

AAA сервер это программа, предоставляющая сервисы аутентификации (Authentication), авторизации (Authorization) и учёта использования ресурсов (Accounting).

Аутентификация – это процесс проверки подлинность пользователя. Система спрашивает у пользователя: “Кто ты?”

При авторизации система проверяет, что пользователю разрешено делать, а что нет, доступ к каким ресурсам позволен, к каким — нет. Система определят “Куда ты идешь?” и решает пропустить или нет.

Таким образом, аутентификация вполне самодостаточна, то есть может существовать без авторизации. Авторизация же без аутентификации работать не может.

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

Есть два способа реализации авторизации.

Первый – это классическая авторизация пользователей.

Правила доступа определяются на AAA сервере. В конфигурации фаервола указывается трафик, требующий авторизации. Если пользователь инициирует соединение, которое требует авторизации, фаервол запрашивает AAA сервер. Если на AAA сервере определено, что для данного пользователя данный трафик разрешен, фаервол предоставляет соединение. В противном случае соединение разрывается.

Классическая авторизация поддерживается только TACACS+ сервером.

Второй способ реализации авторизации – это динамически загружаемые списки доступа (access lists). На AAA сервере создаются аксес листы. Они привязываются к определенным пользователям или группам. В момент, когда пользователь проходит аутентификацию на фаерволе, ASA загружает с AAA сервера нужные аксес листы. При этом в качестве ip адреса источника соединения прописывается ip адрес аутентифицировавшегося пользователя. Клода пользователь разлогинивается, его аксес листы удаляются из памяти фаервола.

Этот вариант авторизации поддерживается только RADIUS сервером.

Пример настройки классической авторизации.

Здесь мы рассмотрим пример реализации классической авторизации. В качестве AAA сервера будем использовать Cisco Secure ACS v4.0, а в качестве фаервола — ASA5510 с ios Cisco Adaptive Security Appliance Software Version 8.0(3).

На рисунке Вы видите схему тестовой сети.

В нашем примере за фаерволом есть небольшая сеть, включающая в себя несколько серверов. Двум группам пользователей нужен доступ к внутренней сети. Первая группа – это обычные пользователи. Им надо открыть ftp трафик к двум FTP серверам и RDP трафик к терминальному серверу. Вторая группа – это администраторы серверов. Им так же требуется ftp трафик к FTP серверам и RDP трафик ко всем серверам внутренней сети (точнее сказать, надо открыть RDP ко всей внутренней сети 192.168.1.0/24). Если бы пользователи имели статические ip адреса, достаточно было бы написать аксес листы на фаерволе. Но так как пользователи используют динамические ip адреса, без аутентификации не обойтись. Более того, пользователям нужен разный доступ к разным ресурсам. Следовательно, аутентификации не достаточно, нужна еще и авторизация.

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

 

Восстановление (сброс) пароля на cisco ASA серии 5500

Шаг 1: Подключаемся к консольному порту согласно процедурам, описанным здесь: «Accessing the Command-Line Interface» section on page 2-1.

Шаг 2: Выключаем, затем включаем питание.

Шаг 3:В процессе появления сообщений загрузки жмем клавишу Escape для того, чтобы попасть в ROMMON. Обычно появляется сообщение »Press ESC to enter rommon»

Шаг 4: Для того, чтобы устройство проигнорировало автоматически загружаемый файл конфигурации, введите следующую команду:

rommon #1> confreg

Устройство отобразит текущее значение конфигурационного регистра и запросит вас, хотите ли вы изменить данный параметр:

Current Configuration Register: 0x00000011
Configuration Summary:
boot TFTP image, boot default image from Flash on netboot failure
Do you wish to change this configuration? y/n [n]:

Шаг 5: ОБЯЗАТЕЛЬНО запишите текущее значение конфигурационного регистра, для того чтобы позднее его восстановить.

Шаг 6: В ответ на приглашение об изменении параметра, введите Y чтобы начать изменения. После чего устройство предложит вам ввести новые значения.

Шаг 7: Примите настройки по усолчанию для всех параметров, кроме параметра «disable system configuration?»; в этом пункте ответьте Y.

Шаг 8: Перезагрузите устройство введением следующей команды:

rommon #2> boot

После чего устройство загрузит свою изначальную конфигурацию, вместо вашей стартовой конфигурации

Шаг 9:Войдите в привилегированный режим(EXEC) вводом следующей команды:

hostname> enable

Шаг 10:В случае возникновения приглашения о вводе пароля, ничего не вводите, а просто нажмите Enter.
Пароль пуст.

Шаг 11:Загрузите свою стартовую конфигурацию, вводом следующей команды:

hostname# copy startup-config running-config

Шаг 12:Войдите в режим глобальной конфигурации, использованием следующей команды:

hostname# configure terminal

Шаг 13:Задайте пароли по средствам использования следующих команд(по выбору, в зависимости от вашей ситуации):

hostname(config)# password
hostname(config)# enable password
hostname(config)# username password

Шаг 14: Установите значение конфигурационного регистра так чтобы после следующей при перезагрузке устройство смогло загрузить вашу стартовую конфигурацию. Используйте следующую команду :

hostname(config)# config-register ЗНАЧЕНИЕ

ЗНАЧЕНИЕ – это значение конфигурационного регистра, которое вы записали в ходе шага №5. 0×1 – это значение регистра по умолчанию. За более подробной информацией относительно значений, которые может принять конфигурационный регистр ознакомьтесь с документом: Cisco Security Appliance Command Reference.

Шаг 15: Сохраните значения новых паролей в ваш стартовый конфигурационный файл с использованием следующей команды:

 hostname(config)# copy running-config startup-config

iftop — просмотр нагрузки на сетевом интерфейсе

iftop command listens to network traffic on a named network interface, or on the first interface it can find which looks like an external interface if none is specified, and displays a table of current bandwidth usage by pairs of hosts. iftop is a perfect tool for remote Linux server over ssh session.

iftop must be run by the root or the user who has sufficient permissions to monitor all network traffic on the network interface.

Type iftop command at tge shell prompt to display traffic:

# iftop


However, iftop works best when you use filters. For example, if you want to find out how much bandwidth users are wasting or trying to figure out why the network is slow,

# iftop -f icmp

You can display or analyses packet flowing in and out of the 192.168.1.0/24 network:

# iftop -F 192.168.1.0/24

Disable output for DNS traffic by using filter code such as:

# iftop -f 'not port domain'

iftop has many options read man page for further information.

Starcraft 2 на Linux

Okie dokie — so I’ve mentioned before that I play Starcraft 2 under my Linux install with no issues. Since the game’s official release a few days ago I have been getting a good bit of traffic on those two pages — so I figured I would put together a quick HOWTO for getting Starcraft 2 working on your Linux distro of choice. The game runs under Wine 1.2 and/or Crossover Games 9.1 with a small bit of work (the latter is easier to make work).

Since free is good I’ll talk about the Wine HOWTO first. First off, download and install Wine 1.2 on your system. Next, run the following commands in terminal:

cd ~/Downloads
 wget http://winezeug.googlecode.com/svn/trunk/winetricks
 chmod +x winetricks
 ./winetricks droid fontfix fontsmooth-rgb gdiplus gecko
 ./winetricks vcrun2008 vcrun2005 allfonts d3dx9 win7
 winecfg

In the configuration Window it opens go to the libraries tab and enter mmdevapi in the new override for library box and click add. Now scroll through the existing over rides list for mmdevapi click edit and set it to disabled. Finally click on the audio tab and set it to alsa.

If you still have audio issues after doing this and your distro uses Pulse Audio (Ubuntu does) install Wine 1.2 that has been built with pulse audio support with the following commands in terminal:

sudo add-apt-repository ppa:c-korn/ppa
sudo apt-get update && sudo apt-get upgrade

As of Crossover 9.1 Starcraft 2 is listed as «officially support» and as such you will find that it has an entry in the automated games installer. The only issue is that after the game has actually finished installing the StarCraft 2 process hangs around — meaning Crossover never actually knows that the game has finished installing and thusly never creates menu entries for it. Thank fully there is a simple fix for this — after Starcraft 2 has finished installing, open up your system monitor and look for any rogue Starcraft 2 processes and kill them off. After you have done this the CXGames installer will know that it has finished installing and will create the menu entries as it should.

If you have audio issues under Crossover you can open your Starcraft 2 bottle’s WineCFG, select the audio tab, and set hardware acceleration from full to emulated.

Also — if you are trying to install from the retail CD (with Wine or Crossover) you might need need to manually mount the disc due to an issue with its split PC/Mac auto mounter. To do this run the following two commands in terminal:

sudo umount /media/SC2*
sudo mount -t udf -o ro,unhide,uid=$(id -u) /dev/cdrom /media/cdrom

Note some drives may use /dev/sr0 (or other mount points) instead if /dev/cdrom. If you are having issues getting it working scroll through the comments for some good tips — if you are still unable to get it working after that, make a comment of your own 🙂

Also — if you are attempting to get the game running with an ATI card, it was suggested in the comments that making it run under a virtual desktop allows it to run on some systems it otherwise fails to work on.

I tested the above methods on Ubuntu 10.04, Linux Mint Debian, and Chakra — but they should be applicable to any modern Linux distribution. Have any issues feel free to drop a comment below and I will do my best to lend a hand debugging. Happy gaming!

~Jeff Hoogland

Отключение IPv6 в Linux

В ядрах до 2.6.29 (не уверен!) этот протокол собирался отдельным модулем, поэтому его выключение было возможно помещением в /etc/modprobe.d/blacklist строчку blacklist ipv6.

В ядрах 2.6.30 протокол ipv6 собирался уже на уровне ядра и отключение его подразумевало пересборку ядра без оного.

В ядрах 2.6.31 хоть протокол и размещается в ядре, но предусмотрена возможность отключить его опцией при запуске ядра:

В GRUB’е первом ищем /boot/grub/menu.lst и дописываем строчку запуска ядра (кроме обычных опций ro quiet splash) ipv6.disable=1. Перегружаем компутер и проверяем ifconfig.

В GRUB2 идём в /etc/default/grub и ищем строчку с опциями по умолчанию «quiet splash» и дописываем опцию ipv6.disable=1. Должно получиться вот так: «quiet splash ipv6.disable=1».
И запускаем:

$ sudo update-grub

Перегружаем компутер и проверяем ifconfig.

Теперь я не отключаю ipv6, а просто запрещаю его iptables’ом.

$ ip6tables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

madWiMAX — использование Yota в Linux

madWiMAX — реверс-инжинированный Linux драйвер для устройств доступа к сетям mobile WiMAX (802.16e), выполненных на основе чипа Samsung CMC-730. На данный момент поддерживаются следующие устройства:

  • Samsung SWC-U200
  • Samsung SWC-E100
  • Samsung SWM-S10R

madWiMAX есть в официальном репозитории debian’а.

$ aptitude install madwimax

Настройка йоты проста.

После покупки йота-модема я зарегистрировал его из-под виндовс в личном кабинете, а потом уже сунул в дебиан. Регистрация элементарна и, думаю, что даже из lynx можно было её проделать.

Говорим спасибо Александру Гордееву и остальным разработчикам за madwimax. Говорим спасибо Петру Курышеву за сборку deb пакетов и качаем отсюда http://peter.infosreda.com/ru/2009/03/23/ubuntu-deb-madwimax-0_1_0 два пакета:

$ wget http://peter.infosreda.com/libusb1_1.0.0-1_i386.deb
$ wget http://peter.infosreda.com/madwimax_0.1.0-1_i386.deb

и устанавливаем их:

$ dpkg -i libusb1_1.0.0-1_i386.deb
$ dpkg -i madwimax_0.1.0-1_i386.deb

«Для того, чтобы модем автоматически соединялся с сетью Yota при включении в USB разъем, потребуется раскомментировать последние две строчки (их там всего четыре) файла /etc/udev/rules.d/z60_madwimax.rules»

Настроил NAT для людей в локальной сетке. Все вздохнули облегчённо, но было замечено, что многие сайты не открываются. Спасибо http://x4da.wordpress.com/articles/madwimaxiptablesdhcp/ за описание и разрешение проблемы:

«Пришлось добавить

iptables -t mangle -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN -o wimax0 -j TCPMSS –clamp-mss-to-pmtu

Это правило просто отключает бит DF.»

Была засада — пропал интернет. Запустил на серваке lynx www.rambler.ru и увидел страницу йоты, где было написано про то, что «если вы видите эту страницу, то оплатите…, проверьте…, зарегистрируйте модем…, выньте и всуньте модем…».

Попробовал вынуть/всунуть — помогло. В первый раз, правда, слишком быстро вынул/всунул. Потом попробовал с пару-тройку секундным запозданием и всё заработало.

Вторая засада — при подключении к Йоте по DHCP назначаются новые йотовые DNS, которые прописываются в /etc/resolve.conf. А надо, чтобы доменные оставались, так как есть домен и второй провайдер.

Нагуглил  http://evilzipik.blogspot.com/2009/01/resolvconf-dhcp.html

Чтобы этого не происходило нужно:

в /etc/dhcp3/dhclient-enter-hooks.d/ создать пустой файл, например, nodnsupdate

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

$ chmod +x /etc/dhcp3/dhclient-enter-hooks.d/nodnsupdate

в него занести:

#!/bin/sh
make_resolv_conf(){
 :
}

И ещё. Когда запускаю madwimax -vv для поиска места с максимальным усилением сигнала, то сыпятся сообщения bulk write error. Поменял USB кабель на толстый экранированный. Эти ошибки пропали.

И ещё. Недавно переустановил на сервере debian x32 на debian amd64. Через какое-то время обнаружил, что не могу зайти в gmail почту через https. Не знаю связаны ли эти события. Уменьшил MTU на интерфейсе своей убунты до йотовских значений — 1386 байт. Почта заработала. (временно для проверки увеличил до 1387 байт — почта перестала работать) Примечательно, что под виндами спокойно вхожу в почту. Только одно предупреждающее сообщение и дальше можно работать. Видимо из-за автоматического определения размера MTU.

2010-09-10. С начала сентября 2010 года йота в ауте. Скорость мизерная. Работать невозможно. Ищу дешёвого проводного провайдера.

2010-11-02. Провайдера нашёл, но и с йотой более-менее разобрался. Запускаю:

$ madwimax -vv

и смотрю на значение CINR. Начинаю искать модемом на USB удлинителе максимальное значение CINR. Меньше пяти — плохо. Начиная с 6, 7 — более-менее. 9-10 — хорошо. Это пока максимальное значение достигнутое мной. Значение достигается поворотом модема вокруг вертикальной оси градусов на 45 от оконного стекла и сдвигом его на пару сантиметров влево — вправо около определённой точки на подоконнике.)) Если сигнал есть, но инет тормозной, то передвигаю модем в другую точку на подоконнике, где он цепляется к другой точке доступа. Есть вероятность, что через эту точку доступа инет будет более быстрым.

После испытаний и прерывания Ctrl-C запущенного madwimax -vv, необходимо переткнуть модем, чтобы модем переинициализировался.

Ссылки:

http://peter.infosreda.com/ru/2009/03/23/ubuntu-deb-madwimax-0_1_0
http://x4da.wordpress.com/articles/madwimaxiptablesdhcp/

Настройка APC UPS

Устанавливаем

$ aptitude install apcupsd

В /etc/apcupsd/apcupsd.conf правим соответствующие строчки:

UPSCABLE usb
UPSTYPE usb

Запускаем демон:

/etc/init.d/apcupsd start

apcaccess для вывода информации по UPS.

Ещё команда для теста UPS, для изменения даты смены батареи и т.п. apctest.

Работает после остановки демона apcupsd.

Проблемы:

Остановил apcupsd и дал команду apctest, а в ответ:

# apctest
 2009-12-14 12:28:11 apctest 3.14.4 (18 May 2008) debian
 Checking configuration ...
 Attached to driver: usb
 sharenet.type = DISABLE
 cable.type = USB_CABLE
You are using a USB cable type, so I'm entering USB test mode
mode.type = USB_UPS
Setting up the port ...
apctest FATAL ERROR in device.c at line 70
Unable to create UPS lock file.
If apcupsd or apctest is already running,
please stop it and run this program again.
apctest error termination completed

Запустил apcuspd и дал команду apcaccess, в ответ:

# apcaccess
Error reading status from apcupsd @ localhost:3551: Connection timed out

Остановил apcupsd и проверил:

# ps aux | grep apc
 root 2509 0.0 0.0 193356 1148 ? Ssl Dec13 0:03 /sbin/apcupsd
 root 6739 0.0 0.0 7236 848 pts/1 S+ 12:55 0:00 grep apc

Убил процесс /sbin/apcupsd:

root@deb5:/var/run# kill 2509

И всё заработало.