Показаны сообщения с ярлыком inet. Показать все сообщения
Показаны сообщения с ярлыком inet. Показать все сообщения

22 мая 2015 г.

Bash: Inet switcher

Для сохранности оставлю здесь скрипт автопереключалки инета для трех провайдеров с проверкой доступности ресурсов. Правда, в рабочем порядке он еще не испробован, поэтому применять с осторожностью.

#!/bin/bash

##
## /etc/iproute2/rt_tables:
## 101     fc
## 102     adsl
## 103     gsm
##

##

##Localnet
L1_IF="eth77"
L1_IP="192.168.77.250"
L1_NET="192.168.77.0/24"

##FC
P1_IF="eth77"
P1_GW="192.168.77.159"
P1_TBL="fc"

##ADSL
P2_IF="ppp200"
P2_GW="`ifconfig ppp200 |egrep -o 'addr:[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | awk -F: '{ print $2}'`"
P2_TBL="adsl"

##Cellular 3G
P3_IF="eth77"
P3_GW="192.168.77.200"
P3_TBL="gsm"

## hosts to ping
TEST1="77.88.8.8"
TEST2="8.8.8.8"

##Default for fallback feature
DEF=${P1_GW}

## fullfill iproute2 tables
function fill_p1
        {
                /bin/ip r flush table ${P1_TBL}
                /bin/ip r a default via ${P1_GW} table ${P1_TBL}
                /bin/ip r a ${L1_NET} dev ${L1_IF} src ${L1_IP} scope link table ${P1_TBL}
                /bin/ip rule a fwmark 1 lookup ${P1_TBL}
        }

function fill_p2
        {
                /bin/ip r flush table ${P2_TBL}
                /bin/ip r a default dev ${P2_IF} table ${P2_TBL}
                /bin/ip r a ${L1_NET} dev ${L1_IF} src ${L1_IP} scope link table ${P2_TBL}
                /bin/ip rule a fwmark 2 lookup ${P2_TBL}
        }
function fill_p3
        {
                /bin/ip r flush table ${P3_TBL}
                /bin/ip r a default via ${P3_GW} table ${P3_TBL}
                /bin/ip r a ${L1_NET} dev ${L1_IF} src ${L1_IP} scope link table ${P3_TBL}
                /bin/ip rule a fwmark 3 lookup ${P3_TBL}
        }

## checking internet availability via different providers
function get_status
        {
                CUR_GW=`/bin/ip r sh | grep def | egrep -o [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+`

                /bin/ping -W 1 -i 0.5 -c 2 -m 1 ${TEST1} > /dev/null
                P1_STAT="$?"

                /bin/ping -W 1 -i 0.5 -c 2 -m 2 ${TEST1} > /dev/null
                P2_STAT="$?"

                /bin/ping -W 1 -i 0.5 -c 2 -m 3 ${TEST1} > /dev/null
                P3_STAT="$?"

                if [ "$P1_STAT" -ne "0" ] && [ "$P2_STAT" -ne "0" ] && [ "$P3_STAT" -ne "0" ]
                        then
                               echo "${TEST1} failed, trying ${TEST2}"
                                /bin/ping -W 1 -i 0.5 -c 2 -m 1 ${TEST2} > /dev/null
                                P1_STAT="$?"

                                /bin/ping -W 1 -i 0.5 -c 2 -m 2 ${TEST2} > /dev/null
                                P2_STAT="$?"

                                /bin/ping -W 1 -i 0.5 -c 2 -m 3 ${TEST2} > /dev/null
                                P3_STAT="$?"
                fi

        }

##main

echo "filling rt_tables"
fill_p1
fill_p2
fill_p3

echo "cheking gateways"
get_status
echo "P1: $P1_STAT P2: $P2_STAT P3: $P3_STAT"

echo "action: "
if [ "$P1_STAT" -eq "0" ] && [ "$CUR_GW" = "$DEF" ]
        then
               echo "do nothing"
                exit 0
fi

if [ "$P1_STAT" -eq "0" ] && [ "$CUR_GW" != "${DEF}" ]
        then
               echo "restoring to $P1_TBL"
              /sbin/ip r ch default via ${P1_GW}
                exit 0
fi

if [ "$P2_STAT" -eq "0" ] && [ -n "$P2_GW" ]
        then
               echo "switching to $P2_TBL"
              /bin/ip r ch default via ${P2_GW}
                exit 0
fi
if [ "$P3_STAT" -eq "0" ]
        then
               echo "switching to $P3_TBL"
              /bin/ip r ch default via ${P3_GW}
                exit 0
        else
               echo "swag!"
fi


11 янв. 2013 г.

Squid cache peer proxy

Краткая справка о том, как настроить простейший каскадный (cache-peer) прокси. Все настройки прописываются в squid.conf:
http_port 3128  ## ждем подключения клиентов на этот порт
acl myuser src 192.168.1.100 ## даем доступ для заданных рабочих станций
http_access allow myuser ## активируем описанный выше доступ
cache_peer 192.168.1.254   parent  3128  7 no-digest no-query allow-miss ## описываем вышестоящий (родительский) прокси-сервер, куда следует перенаправлять запросы
never_direct allow myuser ## запрещаем прямые (в обход parent proxy) запросы от заданных рабочих станций
Если все сделано верно, в cache.log после перезапуска squid-а должна появиться следующая запись:
2013/01/11 14:01:51| Configuring 192.168.1.254 Parent 192.168.1.254/3128/7
2013/01/11 14:01:51| Ready to serve requests.
Теперь на рабочей станции 192.168.1.100 в настройках, например, браузера выставляем IP и порт этого squid и получаем рабочий каскадный прокси.

22 сент. 2011 г.

Debian + USB ADSL modem

Совершенно внезапно словил "зов из прошлого" - потребовалось завести под Debian-ом старый-старый USB ADSL модем. Так как они все на Conexant-овском чипе, то и заводятся идентично. Вся проблема - найти фирмварь для ядерного модуля (да-да, в ядре уже давно все, как в Греции). Здесь мне помог вот этот ресурс. Более того, там описан и весь процесс установки и настройки сего девайса. В общем, читаем, смотрим, настраиваем. Единственное, что там не описано, на появившийся псевдо-интерфейс (nas0) следует навесить какой-нибудь IP-адрес, иначе pppoe-discovery не сможет корректно отработать.

19 июл. 2011 г.

Установка и настройка vnstat + vnstat php frontend

Простенькая последовательность на "не забыть" по установке-настройке простенького же монитора трафика vnstat в Debian Squeeze, и не только.
apt-get install vnstat apache2 libapache2-mod-php5 php5-gd
Настройки в основном умолчальные (/etc/vnstat.conf), правим только интефейс (если хочется несколько, то через запятую):
#Interface "eth0"
Interface "ppp200"
Уводим логи в собственный файл вместо syslog:
#UseLogging 2
UseLogging 1
LogFile "/var/log/vnstatd.log"
Единоразово инициализируем базу:
root@demos:/home/interra/!# vnstat -e -i ppp200
Перезапускаем демон:
root@demos:/home/interra/!# service vnstat restart
Stopping vnStat daemon: vnstatd.
Starting vnStat daemon: vnstatd.
Убеждаемся, что все хорошо:
root@demos:/home/interra/!# cat /var/log/vnstatd.log
[2011.07.19 11:53:47] vnStat daemon 1.10 started.
[2011.07.19 11:53:47] Daemon running with pid 30757.
[2011.07.19 11:53:47] Monitoring: ppp200
Скачиваем веб-морду vnStat PHP Frontend отсюда (на момент написания версия 1.5.1), распаковываем в /var/www/vnstat.
Настройки находятся в файле  /var/www/vnstat/config.php. Для базового запуска достаточно переопределить интерфейсы:
$iface_list = array('ppp200');
$iface_title['ppp200'] = 'Internet';
Получать данные для отображения можно или запросом текущих данных, тогда указывается путь к бинарнику vnstat:
$vnstat_bin = '/usr/bin/vnstat';
или чтением данных из текстового дампа базы, выполненного командой вида vnstat --dumpdb -i $iface > /path/to/data_dir/vnstat_dump_$iface. В этом случае переменная $vnstat_bin комментируется, и описывается переменная $data_dir:
// $vnstat_bin = '/usr/bin/vnstat';
$data_dir = './dumps';
В приведенном примере полный путь к каталогу - /var/www/vnstat/dumps. Важно, чтобы файл с дампом назывался строго vnstat_dump_$iface, где $iface - имя интерфейса, за которым ведется мониторинг. Несколько интерфейсов - несколько файлов, каждый из которых заполняется отдельной командой.
Далее внесем в cron задание на периодическое обновление дампа такого вида, создав файлик в /etc/cron.d/ или вызвав редактор - crontab -e:
*/2 * * * * /usr/bin/vnstat --dumpdb -i ppp200 > /srv/www/vnstat/dumps/vnstat_dump_ppp200
Всегда используем в кроне только абсолютные пути!
Далее остается только перезапустить apache и обратиться браузером по адресу http://адрес_сервера/vnstat

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-пакетов вообще.

3 сент. 2010 г.

МТС Коннект

Поговорим о 3G/EDGE/GPRS USB модемах, раздаваемых "большой тройкой". Сейчас речь пойдет о Huawei E1550, но, думаю, для других моделей все нижесказанное тоже актуально, за исключением разве что idProduct'а и idVendor'а, которые можно найти в Сети для каждой железки.
Проблема работы этих устройств в линуксах заключается, по большому счету, в том, что при подключении девайс определяется как CD-ROM, на котором лежит софт для подключения и работы в винде. После установки он сам переключает (flip-flop) девайс на "режим модема". У linux же такое переключение возможно, если работать с модемом софтинкой Mobile Partner от Huawei. Но она, на мой взгляд, уж сильно прожорливая и неторопливая, что особо нехорошо для мобильных устройств. Итак, основная задача - перевести девайс в режим модема, заимев в результате /dev/ttyUSB0, через который pppd и  будет "звонить". В случае Ubuntu все просто:
sudo apt-get install usb-modeswitch
Свежие версии "знают" о Huawei E1550, поэтому добавлять ничего не придется.
Для того, чтобы модем переключался в нужный режим автоматически при подключении, создадим правило udev: /etc/udev/rules.d/45-huawei1550.rules следующего содержания:
SUBSYSTEM=="usb", SYSFS{idProduct}=="1446", SYSFS{idVendor}=="12d1", RUN+="/usr/sbin/usb_modeswitch -v 0x12d1 -p 0x1446 -m 0x01 -M 55534243000000000000000000000011060000000000000000000000000000"
Таким образом, если udev видит подключенное устройство с совпадающими параметрами, он выполняет соответствующую команду.
Для проверки следует переподключить модем и поглядеть вывод lsusb, который должен отрапортовать о наличии модема.
lsusb | grep Huawei
Bus 003 Device 004: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem
В случае с Debian Lenny действий придется совершить чуть больше, ибо пакет usb-modeswitch доступен только для sid. Не беда, соберем сами. Алгоритм простой: качаем исходники, распаковываем, собираем и устанавливаем. Предварительно полезно прочитать информацию на страничке продукта, выяснив, к примеру, что для сборки необходимо установить пакеты tcl и libusb-dev, а также pppconfig для последующей настройки подключения.
apt-get install tcl libusb-dev pppconfig
mkdir modswitch; cd modeswitch
wget -c http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.1.4.tar.bz2
tar zjvf  usb-modeswitch-1.1.4.tar.bz2
cd  usb-modeswitch-1.1.4
make install
cd ..
wget -c http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-20100826.tar.bz2
tar xjvf usb-modeswitch-data.tar.bz2
cd  usb-modeswitch-data
make install
Установщик сам "договорится" с udev-ом, поэтому переключение в режим модема при подключении девайса должно работать сразу, что и следует  проверить после окончания установки usb-modeswitch.
Теперь осталось лишь настроить ppp-подключение. Запускаем pppconfig, отвечаем на вопросы, к примеру, так: 
Create -> mts -> dynamic -> pap -> mts -> mts -> 115200 -> tone -> *99# -> Нет -> /dev/ttyUSB0 -> Finished
Все, осталось запустить соединение:
pppd call mts nodetach
Все должно работать. 
Один раз, на убунте, столкнулся с ошибкой: pppd отключался с таким отлупом:
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 ]
sent [IPCP ConfReq id=0x2 ]
Modem hangup
Connection terminated.
Полечилось явным указанием точки входа в /etc/chatscripts/mts:

# modeminit
'' ATZ
'' AT+CGDCONT=1,\"IP\",\"internet.mts.ru\"
Проверка скорости на internet.yandex.ru:

Я.Интернет. Измерьте вашу скорость.
То бишь - HSDPA имеет место быть худо-бедно ;)

1 февр. 2008 г.

VPN via kvpnc

Итак, простенький мануальчик по сабжу. Даже со скриншотами ;) Правда, немного с артефактами некоторые получились, ну да ладно, на информационную составляющую сии огрехи не влияют особо. Но, тем не менее приступим.
Для поднятия VPN-соединения в SuSE я рекомендую использовать kvpnc версии не ниже 0.8.6 (у меня на момент написания стоит 0.8.8). Взять софтинку можно практически в любом репозитории, а если лень, то есть и на инсталляционном dvd. Однако в таком случае нужно контролировать версию: в более старых есть бага, не позволяющая клиенту пройти MS-CHAP аутенфикацию на впн-сервере (ошибка unrecognized option: mppe-requied).
В нашем случае, считаем, что актуальная версия уже установлена и готова к работе:
(первый артефакт должен был быть курсором мыши с всплывающей посказкой функции кнопы Мастера) - ето думаю итак все догадались ;) Так вот, кликаем на волшебную палочку и запускаем Мастера установки соединения. В появившемся окне выбираем тип соединения - в моем случае сабжевым является vpn, так что берем Microsoft PPTP (а что поделать, такой сервер ;) большая часть клиентов - винда, так что на openVPN'e не разбежишься)
Далее предлагается указать некоторые параметры PPTP. В принципе, если у вас в локалке ничего специфического не понастроено (уточните у того кто настраивал что ли..), то добавлять или видоизменять ничего не требуется. В моем случае, как уже было сказано выше, сервер заточен под виндовых клиентов, так что требуется MS-CHAP аутенфикация, в линуксе реализованная в качестве модуля ядра MPPE (MPPC). Да, примечание... если у вас ядро ниже 2.6.13, то придется его или обновить, или пропатчить дабы сия опция там появилась. Патч я где то на просторах инета видел. Нужно наложить его на исходники ядра и пересобрать последнее с включенной модульно или константно option MPPE. все как обычно ;). Но лучше уж сразу поновее ядрышко иметь, так онои секурнее, и эстетичнее ;)
Но, двигаемся дальше. Ну а дальше вообще семечки. Вводим имеющийся логин и пароль, желательно без ошибок и в нужной раскладке ). Тычки насчет сохранения оных расставляем согласно личным пристрастиям и степени паранойи. NT доменные имена думаю не пригодятся - не встречал я локалок с AD.... ну если ето ваш случай - я думаю вы знаете что вводить.
Тут я и сказать не знаю чего... одно поле выбора сетевого интерфейса... причем еси через локалку впн - то палюбому eth0... неинтересно (тока артефакт картинку чуток веселит). Топаем дальше.
А дальше у нас окно работы с роутингами. Тут в приципе на любителя, вернее, по обстоятельствам. В моей локалке прописанный в настройках маршрутизации default gateway в курсе, куда пулять мои пакеты как на запрос соединения, так и вообще в инет. ;) На то он и default $) Если у вас такого счастья нет, то ставим галку Use additional network routes, жмем Добавить маршрут (Add route) и в появившемся окошечке все вбиваем. Еси я все правильно понял, то етот маршрут создастся при подключении, и удалится при завершении работы программы. Да, как видно на скрине, в моем случае следует проставить опцию Replace default route. В иных ситуациях, возможно, правильным будет выбрать Keep default route. ( Скорее всего в тех случаях, когда сервер смотрит уже непосредственно в инет, а то у нас там куча всего за ним...traceroute классный выводится ;) )
Дальше нам предлагается включить\выключить проверку статуса соединения, указать ее временные интервалы, сказать, что удаленное пинговать для проверки степени живости коннекта и ресконнектить в случае отрицательного результата. В принципе, если соединение не мрет постоянно при отсутствии сетевой активности, то можно и отключить.

И последний штрих. Дженеральные, так сказать настройки. Помните капитана Врунгеля? "как вы судно назовете, так оно и поплывет"... воот! Так что придумываем имя и описание профиля не абы как, а с фантазией и вкусом. Вот только, прошу вас, отключить фантазерство напрочь при введении VPN gateway'я. Тут нужна счетверготоченность и полное осознание собственных действий. Неверный путь к впн шлюзу - и софтинка будет ломиться незнамо куда, и никакого инета вам не будет. Если не в курсе, спросите у уже упоминавшегося выше настройщика впн-шлюза вашего, или хотя бы у более прошаренных (читай, уже подключившихся) товарищей.
Вот и все. Дальше коннект! И если все было сделано правильно - вы в Сети. И можете с легкостью прочитать этот мануал ;)) Действительно, уже дописывая эти строки, опять вспомнились слова про то, что дрова от модема всегда оказываются в интернете. Но ведь надо же все-таки хотя бы пытаться сеять разумное-доброе-вечное на просторах Сети в общем, и на страницах моего блога в частности. Ищущий да обрящет. И для облегчения поиска и создания Коннекта и был накорябан сей пост. Хочется надеяться, что кому нибуть он поможет. Еще раз сорри за артефакты ;) и антрям.
Постскриптум: Добавочка выяснилась одна. Немаловажная как вышло. В общем, если в вашей сети VPN-шлюз и ваш хост находятся в пределах одной подсети, то дальше можно не читать. У меня к примеру, ситуация иная - я нахожусь в подсети 10.0.0.0/21, а мой впн-шлюз - в 10.1.0.0/19. Поэтому по умолчанию хост шлюз не видит, и соответственно, kvpnc будет стучаться неизвестно фкуда - а именно, выдавать ошибку о том что no route to host или что то в этом роде. Поэтому топаем в Yast - Сетевые службы - Маршрутизация, жмем Добавить - и добавляем маршрут в нужную подсеть (предварительно поставив тычку Настройки эксперта). Точные настройки будут у каждого свои, но у меня они выглядят так:
хЫ.... только сейчас заметил. Оболочки окон разные получились ;) Последний скрин - с Большого Брата (привет Emerald'у) Так что дополнительно оцените различия между оным и kwin. Но это ...уже совсем другая история, о ней - в следующий раз.