Невозможное - возможно!

Пожалуй, сегодня возьму желтый...

Недостаточная видимость?

Только до 31 февраля!

Ну не смог пройти мимо :)

Настройка туннеля в Linux Ubuntu

Для настройки сети необходимо добавить в файл /etc/network/interfaces следующие строки:

auto tun1
iface tun1 inet static
    # Адрес машины внутри туннелся. Соединения точка-точка, по этому маска из одних единиц
    address 192.168.0.1
    netmask 255.255.255.255
    # Адрес внутренний адрес машины, с которой установлен тунель
    pointopoint 192.168.0.2
    # Размер MTU
    mtu 1480
    # Перед поднятием интерфейса нужно создать тунель, что мы тут и делаем
    pre-up iptunnel add tun1 mode ipip local 89.123.1.234 remote 89.123.2.234 ttl 255
    up ifconfig tun1 multicast
    # Весь трафик в соседнюю сеть надо завернуть в тунель
    up route add -net 192.168.2.0/24 gw 192.168.0.2 dev tun1
    # Удаляем туннель после удаления интерфейса
    post-down iptunnel del tun1

В примере используется имя интерфейса tun1, но, в принципе, его можно назвать как угодно.
Размер MTU может быть различным. Для его вычисления надо взять минимальный MTU от интерфейсов, смотрящих в интернет (это можно сделать командой ifconfig), и вычесть из него заголовок пакета ipip, которые равен 20 байтам.
Основная борьба под Linux начитается с фаерволом. У меня она свелась к добавлению следующих правил в файл /var/lib/ufw/user.rules (но это сильно зависит от конкретного случая):

-A ufw-user-input   -p ipencap -i ppp0 -j ACCEPT
-A ufw-user-input   -i tun1 -j ACCEPT
-A ufw-user-forward -i tun1 -j ACCEPT

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

sudo ifup tun1
sudo /etc/init.d/ufw restart

Для диагностики могу посоветовать следующий порядок действий:

1. Проверить наличие туннеля:

   ~$ ip tunnel show
   tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
   tun1: ip/ip  remote 83.123.1.234  local 83.123.2.234  ttl 255

2. Проверить, поднялся ли интерфейс:

   ~$ ifconfig tun1
   tun1      Link encap:IPIP Tunnel  HWaddr
    inet addr:192.168.0.1  P-t-P:192.168.0.2  Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1480  Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B)  TX bytes:6478 (6.4 KB)

   Здесь надо отметить, что кол-во RX-пакетов должно расти при пинговании той стороны даже в том случае, если маршрутизатор на той стороне выключен.
   То есть если идет попытка пинговать адрес 192.168.0.2 или 192.168.2.100, то RX должен увеличиваться. В противном случае надо искать проблему в фаерволе.
3. Проверить, проходят ли пакеты через нужные правила iptables.
   Для этого можно воспользоваться ключем -v. Он показывает сколько пакетов и байт прошло через указанное правило.
4. Проверить, уходят ли пакеты во внешний интерфейс:

   sudo ~$ tcpdump -i ppp0 -n proto ipencap

Нарушители 12.02.2013

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

Для начала - утро, торопыга слева решил не пропускать пешеходов. До этого упорно пытался подрезать. Ну ничего, разговор с инспектором и штраф - лучшая награда за такое поведение на дороге.

Ну а потом - то же самое место, день, мадмуазель припарковалась на пешеходном переходе.

Стоит с аварийками, но где знак аварийной остановки? Причем аварийки она включила позже, т.к. когда проезжал ранее мимо нее - аварийки еще не были включены.

Asterisk и UTF-8

Как хорошо живется американцам и англичанам! Никаких проблем с раскладками клавиатуры, кодировками и т.п. А вот в условиях России борьба с кодировками - это просто вид спорта какой-то. Вчерась встал на очередные грабли при попытке писать логи астериска (cdr) в MySQL. Проблема выплывала спонтанно, и вместо русских букв в поле clid начинали появляться крокозяблы. Отладка запросов к MySQL вывела на то, что Asterisk сам менял кодировку запросов. Это, в принципе, логично - то, что не определено явно, устанавливается "по дефолту", т.е. по прихоти разработчика, а разработчику нравится кодировка latin1. Это зашито в исходниках, а вот чтобы поменять всё на UTF-8 - надо внести нужную строчку в cdr_mysql.conf:
[global]
...
charset=utf8

После перезапуска астериска все пришло в норму.

Но вот еще одна напасть - часть записей-то осталась крокозяблами! И как теперь их вернуть в нормальный читаемый вид? Ведь есть записи и с нормальной кодировкой, и их перекодировать не надо. Гугление и курение мануалов привело к рождению вот такого запроса, который одним махом приводит всё в нормальное состояние:

update cdr set clid=unhex(hex(convert(clid using latin1))) where instr(unhex(hex(convert(clid using latin1))),"?") = 0;

Причем, если по счастливой случайности строки были закодированы дважды (а у меня и такое было после экспериментов с настройками) - то повторный запуск раскодирует и их