Аналог reply-to из PF в IPFW

Нашел интересную статью с описанием работы межсетевого экрана IPFW. В частности, упомянута реализация действия, аналогичного reply-to из PF:
«
Тот факт, что на самом деле "перепрыгивание" выполняется на параметры действия, позволяет использовать это для интересных вещей. В частности, с использованием появившегося во FreeBSD 6.2 параметра tag на каждый пакет можно навешивать внутриядерный тег, что в применении со skipto позволяет сделать, к примеру, запоминание, с какого шлюза пришел входящий пакет на машине с каналами к двум разным провайдерам, и ответные пакеты отправлять в тот канал, откуда они пришли (допустим, у вашей машины только один IP-адрес, и сделать fwd на базе внешнего адреса не получится), т.е. реализовать аналог reply-to из PF:

ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 }  # входящие снаружи
ipfw add 400 allow in recv $int_if  # разрешить ответы на внутреннем проходе
ipfw add 500 fwd $gw1 tagged 1      # остались ответы на внешнем интерфейсе,
ipfw add 600 fwd $gw2 tagged 2      # зарулим их куда надо

»

Трансляция PPTP (GRE) на шлюзе с PF

Как известно, межсетевой экран PF, портированный в FreeBSD из OpenBSD, не может корректно транслировать (NAT) GRE-протокол и, к примеру, из локальной сети невозможно создать несколько одновременных соединений к внешнему серверу VPN PPTP.
Одним из способов решения проблемы является трансляция PPTP-соединений родным IPFW с «ядерным» NAT. При этом вовсе необязательно компилировать ядро. Все описанные действия проверены в FreeBSD версии 7.2. Но должно работать и в других версиях, где есть поддержка «ядерного» NAT для IPFW.

В «/etc/rc.conf» добавляем

#Включаем IPFW
firewall_enable="YES"
# Подгружаем модуль ядра ipfw_nat
firewall_nat_enable="YES"
# Указываем путь к скрипту загрузки правил
firewall_script="/etc/ipfw.script"

Создаем файл «/etc/ipfw.script»

#!/bin/sh

/sbin/ipfw -q /dev/stdin <<RULES
flush
#em0 - внешний интерфейс шлюза
nat 10 config if em0
#Правила для трансляции PPTP-соединения
add 10 nat 10 gre from any to any
add 11 nat 10 tcp from any to any dst-port pptp
add 12 nat 10 tcp from any pptp to any
# Разрешаем весь трафик
add allow all from any to any

RULES

Делаем скрипт исполняемым

# chmod +x /etc/ipfw.script

Добавляем в правила PF

# Запрещаем PF транслировать PPTP-соединения
no nat on $external_if proto gre all
no nat on $external_if proto tcp from any to any port = pptp
no nat on $external_if proto tcp from any port = pptp to any

... skip ...

# Пропускаем PPTP-соединения
pass quick on $external_if inet proto tcp from any to any port 1723
pass quick on $external_if inet proto tcp from any port 1723 to any
pass quick on $external_if inet proto gre from any to any

После всех сделанных изменений перезагружаемся.

Неужто??!

Чиновникам велено осваивать безбумажные технологии

Цитата: «Через год чиновникам будет запрещено требовать от граждан справки, если эти данные уже есть в государственных или муниципальных информационных фондах. Такое решение принято российским правительством. Это означает, что ведомства должны будут сами обмениваться необходимой информацией, а не заставлять граждан стоять в бесконечных очередях. Это, кстати, - составная часть той самой программы "электронного правительства", о которой в своем послании говорил и президент Дмитрий Медведев.»

Не верю!

debconf и /tmp с флагом noexec

Если раздел «/tmp» смонтирован с флагом noexec в процессе установки пакетов на этапе предварительной настройки появляются ошибки, похожие на такую

Can't exec "/tmp/fprobe-ulog.config.48931": Permission denied at /usr/share/perl/5.10/IPC/Open3.pm line 168.
open2: exec of /tmp/fprobe-ulog.config.48931 configure  failed at /usr/share/perl5/Debconf/ConfModule.pm line 59
не удалось выполнить начальную настройку пакета fprobe-ulog, код ошибки 255

На launchpad.net подобный багрепорт уже добавлен. Как временное решение в конфиг «/etc/apt/apt.conf» добавляем строку

APT::ExtractTemplates::TempDir "/var/tmp";

предписывающую aptitude и apt-get использовать директорию «/var/tmp» вместо «/tmp».

Запрет запуска второй копии скрипта

Пример кода с пояснениями

#!/bin/sh

pid_file=/tmp/script-name.pid

#########################
# Создаем файл с правом только на чтение
# и вписываем туда идентификатор процесса (pid)
umask 333
(echo $$ > "$pid_file") 2>/dev/null

#########################
# Если процесс уже запущен, то попытка записи pid
# в файл будет завершена с ошибкой
if [ $? -ne 0 ]
then
        umask 22

        echo "Already started :("
        exit 1
fi

umask 22
#########################
# Что-то долго делаем...
#########################

#########################
# Удаляем файл с pid
rm -f "$pid_file"

WiFi vs Ubuntu Karmic Koala

Радость от обновления Ubuntu на своем ноутбуке (Dell Vostro A860) до версии 9.10 Karmic Koala омрачилась нерабочим вайфаем. Причем в логах наблюдалась абсолютная тишина. Модуль ath5k грузится без ошибки и правильно распознает чип от Atheros. А Network Manager скупо пишет "Устройство не готово".
После продолжительного гугления выяснилось, что все дело в некорректной работе функциональной кнопки (Fn + F11), отвечающей за включение/отключение вайфая и блютуза. К слову – я им никогда и не пользовался, так как казалось, она как-то не так работает.

$ tail /sys/class/rfkill/*/{state,name,type,persistent}

==> /sys/class/rfkill/rfkill1/state <==
0

==> /sys/class/rfkill/rfkill2/state <==
0

==> /sys/class/rfkill/rfkill3/state <==
0

==> /sys/class/rfkill/rfkill1/name <==
phy0

==> /sys/class/rfkill/rfkill2/name <==
dell-wifi

==> /sys/class/rfkill/rfkill3/name <==
dell-bluetooth

==> /sys/class/rfkill/rfkill1/type <==
wlan

==> /sys/class/rfkill/rfkill2/type <==
wlan

==> /sys/class/rfkill/rfkill3/type <==
bluetooth

==> /sys/class/rfkill/rfkill1/persistent <==
0

==> /sys/class/rfkill/rfkill2/persistent <==
0

==> /sys/class/rfkill/rfkill3/persistent <==
0

Как видим, rfkill1 и rfkill2 имеют тип wlan. Состояние (state) у обоих равно 0, означающему SOFT LOCK. Кроме состояния 0 могут быть 1 и 2, UNLOCK и HARD LOCK соответственно.
Вся проблема состоит в том, что при нажатии на упомянутую ранее функциональную кнопку состояние переключается только между значениями SOFT LOCK и HARD LOCK, минуя UNLOCK. Из-за этого блокируется переход интерфейса файвая в активный режим, наглядно демонстрируемый командой

$ sudo ifconfig wlan0 up

SIOCSIFFLAGS: Unknown error 132

Решение состоит в принудительном переводе в состояние UNLOCK.
Для этого пишем простой скрипт

#!/bin/sh

for i in /sys/class/rfkill/rfkill*/type;
do
 type="`cat $i`"
 if [ "$type" = "wlan" ];
 then
  n="`echo $i | sed -r 's%/type$%%'`";
  echo 1 > ${n}/state;
 fi;
done;

Сохраняем скрипт в файл «/usr/local/sbin/unlock-wlan» и делаем его исполняемым

$ sudo chmod +x /usr/local/sbin/unlock-wlan

После ручного запуска скрипта надо перезапускать Network Manager – иначе он ничего не заметит.
Теперь настраиваем Upstart для исполнения нашего скрипта при загрузке системы, перед стартом Network Manager. Для этого создаем файл «/etc/init/unlock-wlan.conf»

# unlock-wlan - unlock wireless device
#

description "unlock wireless device"

# Скрипт запускается перед настройкой сетевых интерфейсов
start on starting networking

task

exec /usr/local/sbin/unlock-wlan