30 окт. 2010 г.

Настройка openvpn-туннеля к PirateISP (Швеция)

Получил я приглашение от PirateISP на закрытое бета-тестирование их VPN-анонимайзера, который они замутили на OpenVPN. При настройке подключения возникли две проблемы, и об их решении мы сегодня поговорим. 
Во-первых, провайдером присылается сертификат, зашифрованный паролем, который вводился при регистрации. И, соответственно, опенвпн его при поднятии туннеля спрашивает. Неудобно, к тому же и пароль "кучерявый" у меня. Эта проблема решается простым добавлением в конфигурационный файл строчки  askpass /etc/openvpn/pass, где /etc/openvpn/pass есть файл, в котором, собственно, пароль и записан. 
Вторая проблема - некорректная обработка процессом опенвпн-а случая, когда маршрут по умолчанию задан не шлюзом, а интерфейсом, то есть:
inspire:/home/delayer# route -n | grep 0.0.0.0
0.0.0.0         0.0.0.0          0.0.0.0         UG    0      0        0 ppp200
При таком раскладе опенвпн (версия 2.1.3-2) не может отработать push-нутую сервером команду redirect-gateway, которая подменяет текущий маршрут по умолчанию новым, проходящим внутри туннеля, и задает дополнительный статический маршрут на удаленный vpn-сервер через старый маршрут по умолчанию, дабы туннель после смены дефгейтвея не отвалился сам по себе. При этом туннель все же поднимается, но трафик через него наотрез ходить отказывается.
Эту проблему удалось решить, подменяя перед запуском опенвпн-а маршрут по умолчанию через ppp-интерфейс маршрутом по умолчанию через шлюз, являющийся внешним ip-адресом означенного ppp-интерфейса. К сожалению, сделать это сразу (например, при начальной конфигурации интерфейсов при запуске ОС) не представляется возможным, ибо мой ISP дает мне хоть и "белый", но динамический IP-адрес. Поэтому приходится выкручиваться, определяя каждый раз выданный адрес снова и подставляя его в качестве маршрута.
Конечно, проделывать все вышеописанные идеи в консоли долго и неспортивно, поэтому был набросан небольшой bash-скрипт, позволяющий одной командой поднимать и опускать наш туннель к шведам.
cat /usr/local/bin/pisp.sh
#!/bin/bash

# Дано ;)
SUDO=/usr/bin/sudo
ROUTE=/sbin/route
OVPN_INIT=/etc/init.d/openvpn
EXP=/usr/bin/expect
PirateISP=pirateisp
FLUSH=/usr/bin/flush

# Получение внешнего IP
Rtel_IP=`/sbin/ifconfig ppp200 | grep "inet addr:" | awk {'print $2'} | sed "s/addr://"`

# Функция поднятия туннеля, включает в себя операции
# по изменению маршрутов по умолчанию
function up_tunnel {
    $SUDO $ROUTE del default dev ppp200
    $SUDO $ROUTE add default gw $Rtel_IP
    $SUDO $OVPN_INIT start $PirateISP
}

# Обратная предыдущей функция опускания туннеля
function down_tunnel {
    $SUDO $OVPN_INIT stop $PirateISP
    $SUDO $ROUTE del default gw $Rtel_IP
        $SUDO $ROUTE add default dev ppp200
}
# Выбор действия
case "$@" in
# Старт туннеля и запуск торрент-клиента
# (ради чего всё и писалось =) )
    flush)
        up_tunnel
        sleep 5
        $FLUSH
    ;;
# Поднятие туннеля
    start)
        up_tunnel
    ;;
# Отключение соединения
    stop)
        down_tunnel
    ;;
# Справка
    *)
          echo "Usage: $0 {start|stop|flush}" >&2
          exit 1
      ;;
esac
Теперь, набрав pisp.sh start, я через несколько секунд получаю openvpn-туннель с белым адресом, который Яндекс определяет как стокгольмский. Ввиду закрытости бета-теста народу немного, поэтому скорости отличные (по сравнению с тем же IPredator'ом, где, по слухам, больше 200kbps не дождешься). Такая скорость, по мнению Яндекса, у меня напрямую (IP: 94.181.193.48):
А такая - через PirateISP (IP: 194.14.172.146):
Я.Интернет. Измерьте вашу скорость.
Вот и сказочке конец, а кто слушал - молодец =).

28 окт. 2010 г.

MSS & MTU

Часто, когда речь идет об организации доступа в интернет проводных (Ethernet) и беспроводных (Wi-fi) клиентов, возникает проблема несоответствия MTU, основными симптомами которой является "полуоткрытие" или полная ошибка доступа к некоторым web-ресурсам (при идеальной работе других), затыки в трассировке и тому подобное. Причем при использовании специализированных устройств (wi-fi/adsl/wimax роутеров) таких проблем не наблюдается.А избежать подобных несуразиц очень просто с помощью того же iptables, благодаря которому мы интернет и раздаем ;). Например, если поместить в /etc/ppp/ip-up.d/ скрипт следующего содержания:
#!/bin/bash
if [ $PPP_IFACE = "ppp200" ]; then
   iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    iptables -t nat -A POSTROUTING -o ppp200 -j MASQUERADE
fi
то при поднятии PPPoE-соединения на означенном интерфейсе мы, во-первых включаем маскарадинг на нем, а во-вторых, автоматически изменяем MSS проходящих пакетов. По умолчанию, для PPPoE (MTU 1492 байта) максимальный размер сегмента равен (MTU - 40 = 1452 байта). Размеры пакетов для других типов соединений и еще некоторые другие цифирки можно подглядеть, например, тут или тут. Ну или погуглить на предмет этих аббревиатур в частности и фрагментации IP-пакетов вообще.

Инкрементное возрастание имени сетевого интерфейса при загрузке ОС

Столкнулся со странной и очень неприятной проблемой: сетевая карта на нвидиевском чипе:
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
При загрузке системы сетевка определяется и udev-ом ей назначается имя eth0, все хорошо. Однако при следующей загрузке сетевка по каким-то неведомым причинам получает другой MAC и, соответственно, udev считает ее новым устройством и дает имя eth1. И так далее... На одном из форумов (ссылка где то утерялась) вычитал предпололжение, что на некоторых материнских платах некоторых производителей на NIC назначается какой-то "неправильный" с точки зрения модуля forcedeth MAC-адрес. Он, модуль, сему не верит, и присваивает некий свой, или что-то в этом роде. Короче, правда это, или сказки, но жопа имеет место быть. Лечение, предложенное там же, выглядит как добавление в строку привязки устройства аттрибутов ATTR{device} и ATTR{vendor}, которые неизменны. Узнать оные для сетевки можно так (X - номер интерфейса):
cat /sys/class/net/ethX/device/device
cat /sys/class/net/ethX/device/vendor
Или глянуть в файл /etc/udev/rules.d/70-persistent-net.rules, в закомментированном поле после PCI Device как раз указываются нужные параметры в порядке vendor:device
 cat /etc/udev/rules.d/70-persistent-net.rules | grep '#'
# PCI device 0x10de:0x03ef (forcedeth)
Однако, если убрать меняющийся мак из 70-persistent-net.rules и внести ATTR{device} и ATTR{vendor}, то есть, примерно так:
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",  ATTR{device}="0x03ef", ATTR{vendor}="0x10de", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 То... ничего не изменяется, и после ребута снова появляется еще одна строчка в 70-persistent-net.rules с новым именем нашего интерфейса. В итоге, решение нашлось в следующем: так как мак меняется только по вторым трем байтам, то можно использовать маску: ATTR{address}=="00:00:6c:*". Однако, аттрибуты ATTR{device} и ATTR{vendor} лучше все же оставить, потому что если окажется в системе еще один сетевой интерфейс, удовлетворяющий маске, udev может "сойти с ума", назначив обоим одно имя или не назначив вовсе. 
Таким образом, окончательный вид файла 70-persistent-net.rules получился таким:
cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:6c:*", ATTR{device}="0x03ef", ATTR{vendor}="0x10de", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 P.S.: Описанные действия проводились в Ubuntu 8.04 LTS, однако проблема в принципе может проявиться и в других дистрибутивах. Решение будет работоспособно и там, разве что имя файла persistent-net.rules может различаться.

21 окт. 2010 г.

LXDE + Not Authorized

После очередного обновления LXDE в моем Debian Sid возникла неприятность: при попытке подключить съемный носитель (флешку ли, диск ли) pcmanfm выдавал окно Not Authorized и не монтировал устройство. Вручную, естественно, все монтируется. Решение нашлось на форуме LXDE. Если лень читать тред, продублирую тут. Нужно смягчить политики policykit-а, разрешив действия с подключаемыми устройствами всем. Делается это заменой всех строк no на yes в файле /usr/share/polkit-1/actions/org.freedesktop.udisks.policy (в зависимости от дистрибутива название может различаться). Согласен, что это есть попустительство в плане безопасности системы, однако на домашней рабочей станции, думаю, вполне можно себе это позволить в качестве временного решения. Уверен, разработчики в курсе, и через какое-то время сие будет порешено неким официальным патчем.

20 окт. 2010 г.

CUPS + ipp (http) + Unauthorized error.

Еще один хинт на тему печати. Если встречается следующая проблема: принтер подключен к linux-машине, расшарен cups-ом, c win-машины настраивается подключение по http (ipp то бишь). Печать с винды уходит без ошибок, но купс дропает задание, говоря в error_log-e: Print-Job: Unauthorized.
Лечится следующим образом:
lpadmin -pprinter_name -o auth-info-required=none
И еще один момент: при использовании ipp на вин-системе можно не устанавливать драйверы конкретно для printer_name, достаточно выбрать Generic - MS Publisher Imagesetting в списке драйверов ОС. Задание передастся, как я понимаю, в RAW-формате (поправьте, если я не прав), а непосредственно на принтер его обработает и отправит уже CUPS.

16 окт. 2010 г.

Windows 7 + проблемы сетевой печати.

Продолжая тему виндов ;)
Имел сегодня продолжительный секс с "семеркой" на предмет подключения и работы сетевого принтера. Подключенный локально, USB'ом, он  работает. Подключенный по сети, через http ли, через smb, не работает. Причем "не работает" без ошибок и проблем - просто задание уходит в никуда. Единственное, что в итоге получилось - подключение принтера (сабж - Xerox WorkCentre 4118, для которого еще и человеческих дров под Win7 на сайте не сыщешь) по старинке через параллельный порт, в который net use'ом "воткнут" smb-принтер. На деле выглядит это так: добавляется локальный принтер с интерфейсом LPT1. Затем в командой строке пишется 
net use lpt1: \\server_ip\printer_name /USER:username password /y
Таким образом, винда отправляет задание на вроде бы локальный порт принтера, а на деле - в сеть на рашаренный по smb девайс. Метод работает как для доисторических программ из DOS, так и для наисвежайшей Win7.
Сунув описанную команду в автозагрузку, имеем решение "на постоянку".

Сетевой доступ к Windows XP.

Очень годная статья на предмет доступа к ресурсам ОС Windows XP по сети. Без нее я бы еще долго к admin$ ломился... На заметку, так сказать, ибо не линуксами едиными.

6 окт. 2010 г.

/etc/skel + ldap грабельки.

 При настройке авторизации через LDAP практически всегда будут иметь место пользователи, которые, будучи добавлены в дерево каталогов, не будут иметь домашней директории на конкретном компьютере. Для автоматического создания оных испольуется модуль  pam_mkhomedir.so, которые подгружается в /etc/pam.d/common-session. Однако есть интересные гра ельки: если мы умолчальный файл, который выглядит, как правило, примерно так:

session    required     pam_unix.so
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
поправим для работы с pam_ldap, к примеру, вот так (чтобы осталась возможность авторизоваться и не-ldap-ным пользователям):

session    sufficient     pam_unix.so
session    sufficient     pam_ldap.so
session    required        pam_mkhomedir.so skel=/etc/skel/ umask=0077
то обнаружится, что skel перестает отрабатывать. Пользователь авторизуется, заходит, но домашний каталог ему не создается.
Это происходит потому, что параметр sufficient, при успешной отработке заданного ему модуля, не продолжает проверку остальных параметров, что далее по списку, а сразу "дает добро" на вход. Об этом, и некоторых других важных для работы с PAM вещах, можно почитать тут.
Параметр required не предполагает принятия положительного решения (если заданный ему модуль дает отрицательный ответ, дальнейшая проверка прекращается), поэтому в случае положительного ответа модуля просмотр файла в /etc/pam.d/ продолжается.
Посему наши грабельки лечатся до безобразия просто:
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
session    sufficient     pam_unix.so
session    sufficient     pam_ldap.so