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

четверг, 19 марта 2009 г.

Как обойтись без proxy-сервера

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

Про то, что есть DynDNS, позволяющий иметь доступ к машинкам с динамически меняющимся публичным IP знают многие. Недавно столкнулся с сервисом OpenDNS. Полезная штука. Позволяет сделать контентную фильтрацию трафика всего лишь прописав вместо провайдерских свои DNS серверы (208.67.222.222, 208.67.220.220). Причем, если на роутере есть DNS forwarder, а он есть почти везде, можно эти DNS прямо на роутере прописывать. Прежде чем начать пользоваться, нужно бесплатно зарегистрироваться на сайте OpenDNS, указать свой IP и что фильтровать. Фильтр очень гибкий, можно отсеивать порно, социальные сети, файлообменники и пр. Можно самому задавать сайты. Если IP динамический, то можно установить программку OpenDNS Updater, берется бесплатно с сайта OpenDNS. Updater периодически сообщает свой адрес, даже из-за NAT'а.
Есть такой же сервис и у Netpolice , но там, если ограничиться только прописыванием DNS-серверов (81.176.72.82б 81.176.72.83), нет настроек, а ограничения очень жесткие. Для большей гибкости нужно ставить спецприложение. Как видно, эти сервисы вполне можно использовать для родительского контроля, NetPolice, собственно, и был создан для отечественных школ.
Со стороны пользователя это выглядит так: пытается зайти на какой-нибудь запрещенный сайт и редиректится на страничку, где сказано, что доступ к сайту закрыт. Список сайтов можно самостоятельно пополнять.
Есть еще сервис DNS-o-Matic, позволяющий автоматом на многих сервисах (OpenDNS, DynDNS, No-IP и пр.) синхронизировать ваш динамический IP.
Напоследок приведу скрин, который отображает возможности фильтра OpenDNS.


понедельник, 16 марта 2009 г.

Настройка VPN-клиента (PPTP) в Linux

Не секрет, что многих пользователей удерживает от перехода на linux то, что доступ в Интернет местным провайдером предоставляется на основе технологии VPN. Если быть точным, то PPTP. От этого пользователи сталкиваются с ничем не оправданными трудностями.

На самом деле все просто. Покажем это на примере Kubuntu.

Наиболее удобной программой для организации VPN подключения мне представляется kvpnc - графическая оболочка для pptp, openVPN, Cisco VPN и т.д. Как видно из приставки «k» - программа создана для KDE, так что пользователям Gnome, XFCE и пр., возможно, потребуется установить некоторые дополнительные библиотеки.

Для подключения предлагается использовать программу kvpnc.

1. Установка самой программы:

sudo apt-get install pptpd pptp-linux pppd kvpnc

2. После установки программа запускается через меню KDE и появляется мастер настройки. Нужно нажать «Далее».


3. Выбрать «Microsoft PPTP» и нажать «Далее».

4. Выбрать «Требовать MPPE» и нажать «Далее».

5. Ввести «Имя пользователя» и нажать «Далее».

6. Оставить сетевое устройство по умолчанию и нажать «Далее».


7. Выбрать «Keep default route» и нажать «Далее».

8. Оставить значения по умолчанию и нажать «Далее».


9. Оставить значения по умолчанию и нажать «Далее».

10. Ввести имя профиля и адрес VPN-сервера и нажать "Готово".

11. Нажать "Готово".


12. Зайти в настройки и в меню «Command Execution» --> «After Connect» задать маршрут в удаленную сеть через адрес, получаемый от VPN сервера.

13. Для подключения нажать "Connect".

В случае удачного подключения лог-файл /var/log/messages появится примерно такая информация:

Jun 19 10:41:51 till pppd[10123]: pppd 2.4.4 started by root, uid 0

Jun 19 10:41:51 till pppd[10123]: Using interface ppp0

Jun 19 10:41:51 till pppd[10123]: Connect: ppp0 <--> /dev/pts/4

Jun 19 10:41:52 till pppd[10123]: CHAP authentication succeeded

Jun 19 10:41:52 till pppd[10123]: MPPE 128-bit stateless compression enabled

Jun 19 10:41:54 till pppd[10123]: local IP address 192.168.0.193

Jun 19 10:41:54 till pppd[10123]: remote IP address 192.168.0.180

Таблица маршрутизации примет вид:

root@till:~# netstat -nr

Таблица маршутизации ядра протокола IP

Destination Gateway Genmask Flags MSS Window irtt Iface

192.168.0.180 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

192.168.0.0 192.168.0.193 255.255.255.0 UG 0 0 0 ppp0

10.59.26.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

0.0.0.0 10.59.26.1 0.0.0.0 UG 0 0 0 eth0

Несколько трюков с ng_ipacct

Приведу здесь свою статью 2006 года про ng_ipacct, т.к. ip-lab'а, на котором она была размещена уже нет. В дальнейшем оттуда появится еще пара рецептов.

Инструмент ng_ipacct, разработанный Романом Палагиным, предназначен для сбора статистики о трафике и реализует Cisco ip accounting. Являясь нодой netgraph, он работает полностью в ядре системы, что существенно снижает требования к системным ресурсам. Снятие и обнуление статистики происходит с помощью утилиты ipacctctl.
Инструмент ng_ipacct, разработанный Романом Палагиным, предназначен для сбора статистики о трафике и реализует Cisco ip accounting. Являясь нодой netgraph, он работает полностью в ядре системы, что существенно снижает требования к системным ресурсам. Снятие и обнуление статистики происходит с помощью утилиты ipacctctl. Для возможности работы с ng_ipacct описанными ниже методами нужно скомпилировать ядро с опциями:

options NETGRAPH
options NETGRAPH_ETHER
options NETGRAPH_IFACE

options NETGRAPH_KSOCKET

options NETGRAPH_SOCKET

options NETGRAPH_TEE


Классический метод использования ng_ipacct предполагает, соединение через ng_tee с нодой ng_ether, т.е. трафик считается на ethernet интерфейсе. Приведем пример соответствующего скрипта, который поставляется вместе с исходным кодом самой утилиты.

/sbin/kldload ng_ipacct > /dev/null 2>&1

/usr/sbin/ngctl mkpeer rl0: tee lower right
/usr/sbin/ngctl connect rl0: lower upper left
/usr/sbin/ngctl name rl0:lower rl0_acct_tee
/usr/sbin/ngctl mkpeer rl0_acct_tee: ipacct right2left rl0_in
/usr/sbin/ngctl name rl0_acct_tee:right2left rl0_ip_acct
/usr/sbin/ngctl connect rl0_acct_tee: rl0_ip_acct: left2right rl0_out

В первой строке загружается модуль ng_ipacct, остальные строки иллюстрирует рисунок.




Таким образом, входящий в ethernet интерфейс rl0 трафик с хука lower попадает на ноду rl0_acct_tee, где происходит его копирование на хук upper ноды rl0 и на хук rl0_in ноды rl0_ip_acct. В обратном направлении все происходит аналогично - с хука upper через tee ноду на
хук lower, при параллельном копировании в ng_ipacct. Как видно из примера, нода tee служит для дублирования потоков данных проходящих через нее в обоих направлениях.
При кажущейся простоте метода, сложности все же возникают при необходимости учета трафика на gif и tun интерфейсах, а так же на интерфейсах, работающих в режиме моста, в виду особенностей их реализации. Ниже приведены приемы, позволяющие обойти эти проблемы. Наиболее универсальный способ - это использование правила tee файервола ipfw.

nodename=ipacct_${IFACE}
hookprefix=${IFACE}

/sbin/kldload ng_netflow

ngctl -f- <<-SEQ
mkpeer ipacct ctl ctl
name .:ctl ${nodename}
### хук для входящего трафика
mkpeer ${nodename}: ksocket ${hookprefix}_in inet/raw/divert
name ${nodename}:${hookprefix}_in ${nodename}_in
msg ${nodename}_in: bind inet/0.0.0.0:3021
### хук для исходящего трафика
mkpeer ${nodename}: ksocket ${hookprefix}_out inet/raw/divert
name ${nodename}:${hookprefix}_out ${nodename}_out
msg ${nodename}_out: bind inet/0.0.0.0:3022
rmhook .:ctl
SEQ


В приведенном примере две ноды типа ksocket отправляют в ng_ipacct данные, попадающие в соответствующие сокеты 0.0.0.0:3021 и 0.0.0.0:3022. В эти сокеты трафик направляется правилами файервола:

ipfw add 64021 tee 3021 ip from any to room101 via ${IFACE}
ipfw add 64022 tee 3022 ip from room101 to any via ${IFACE}


При этом следует учитывать, что все запрещающие правила, должны предшествовать правилам tee, т.к. прохождение сетевых пакетов по ipfw заканчивается на этих правилах, и пакеты считаются принятыми. Такую же схему можно реализовать используя правила divert и ноду ng_echo, которая отправляет пришедший поток данных обратно к источнику. Проиллюстрируем это на примере входящего трафика.

/sbin/kldload ng_netflow

ngctl -f- <<-SEQ
mkpeer tee dummy right2left
name .:dummy divert_tee_in
mkpeer divert_tee_in: echo right echo
mkpeer divert_tee_in: ksocket left inet/raw/divert
name divert_tee_in:left divert_sock_in
msg divert_sock_in: bind inet/0.0.0.0:3021
disconnect dummy
mkpeer divert_tee_in: ipacct left2right rl0_in
name divert_tee_in:left2right ng_ipacct
SEQ


В январе 2005 года Gleb Smirnoff опубликовал патч для ноды ng_ipfw, позволяющий копировать трафик из ipfw в netgraph, не прибегая к использованию сокета divert. Это реализуется директивой файервола ngtee. Приведем пример соединения нод.

/sbin/kldload ng_ipacct > /dev/null 2>&1
/sbin/kldload ng_ipfw > /dev/null 2>&1

ngctl -f- <<-SEQ
mkpeer ipfw: ipacct 333 rl0_in
name ipfw:333 rl0_ip_acct
connect ipfw: rl0_ip_acct: 444 rl0_out

SEQ


Трафик перенаправляется в netgraph следующими правилами ipfw:

ipfw add 100 ngtee 333 ip from any to any in
ipfw add 200 ngtee 444 ip from any to any out


Также существует директива netgraph, которую можно использовать совместно с ng_echo, аналогично тому, как это делалось в приведенном выше примере с правилом divert. Проиллюстрируем случай входящего трафика.

/sbin/kldload ng_ipacct > /dev/null 2>&1
/sbin/kldload ng_ipfw > /dev/null 2>&1

ngctl -f- <<-SEQ
mkpeer ipfw: tee 333 left
name ipfw:333 rl0_tee
mkpeer rl0_tee: ipacct left2right rl0_in
mkpeer rl0_tee: echo right qqq
SEQ


Данному примеру будет соответствовать правило ipfw:

ipfw add 100 netgraph 333 ip from any to any in

Попавший в приведенные правила файервола пакет либо будет принят, либо продолжит путешествие по правилам ipfw, в зависимости от значения sysctl переменной net.inet.ip.fw.one_pass (1 - пакет считается принятым, 0 - сравнение продолжается). При этом автор патча сообщает, что такой способ доставки трафика в netgraph более эффективен, чем трюки с tee.

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

PS. А еще добавлю, что с 2006 года в netgraph появились ноды ng_ipfw, связывающая пакетный фильтр ipfw и подсистему netgraph, а также ng_nat, позволяющая делать ядерный NAT. Возможно, позже напишу и об этом.