Home
Just Another Sysadmin's blog (просто еще один блог сисадмина)
System log
Recent Entries 

Advertisement

Customize
Вот, как и обещал, да и пока есть время и энергия, чтобы начать.

IPSec - это широко используемая технология, которая позволяет добавить дополнительный уровень шифрования и проверки подлинности/целостности сообщений к любому траффику, который передается поверх IP. Ее используют как для создания VPN, так и просто для защиты отдельно взятых хостов или данных.
Принципиально в IPSec можно выделить три отдельные части:
1. это протокол AH, который позволяет подписывать/хешировать IP-пакеты, что позволяет проверять подлинность отправителя и целостность пакета. Он просто добавляет подписи к пакетам и ничего не шифрует.
2. Протокол ESP - Encapsulated Security Payload - позволяет шифровать все данные в пакете целиком, используя различные алгоритмы.
3. Протокол IKE, который опционально может использоваться для обмена ключами шифрования между сторонами.

В основном для проверки подлинности сторон используется RSA-сертификат или общий ключ. Что из этого выбирать - зависит от задачи. В общем случае, RSA-сертификаты являются более расширяемым вариантом, особенно при наличии распределенной сети с множеством связей между хостами или маршрутизаторами, так как в этом случае каждому узлу достаточно иметь только сертификат вашего центра сертификации (CA) для проверки подлинности отправителя, а не отдельную секретную фразу для каждого соединения.

IPSec может использоваться в двух разных режимах, у которых разные области применения.
1. Транспортный режим. Просто шифрует/подписывает пакеты с данными в соответствии с заданной политикой. Используется в соединениях хост-хост.
2. Туннельный режим. Используется на маршрутизаторах для создания шифрованных туннелей между приватными сетями через публичные сети, например Интернет. Отличается тем что траффик из защищаемой сети инкапсулируется в IP-пакеты вместе с заголовками и шифруется/подписывается, а затем отправляется другому маршрутизатору, который это расшифровывает и передает дальше.

Таким образом, есть различные режимы, в которых можно использовать IPSec:
1. Соединение хост-хост.
2. Соединение хост-шлюз.
3. Соединение шлюз-шлюз.

Во всех трех случаях используется немного разный подход, особенно в варианте мобильный хост-шлюз, где адрес мобильного хоста заранее неизвестен.

Более того, для некоторых операционных систем существует несколько реализаций IPSec-стека, которые конфигурируются по-разному (хотя понятия везде одни и те же).

Основной сложностью в установке IPSec-соединений между различными ОS/устройствами является возможная несовместимость реализаций или разные множества поддерживаемых протоколов и методов аутентификации.
Об этом тоже пойдет речь.


Навеяно параноидальностью одного пользователя IRC

А именно - MS Windows Vista (а может и все более новые системы) сразу же после появления сетевого подключения делают примерно вот это:
1. Спрашивают у DNS адрес dns.msftncsi.com
2. Спрашивают у DNS адрес www.msftncsi.com
3. Скачивают файлик http://www.msftncsi.com/ncsi.txt

Что это? У людей истерика.

Это вот та самая штука, которая проверяет, есть ли у машины подключение к Internet. NCSI -Network Connectivity Status Indicator

Читать про это можно на MS TechNet
Там же написано как это, на ваш страх и риск, выключается.

На случай если маленькая конторка просит высылать краткий анализ логов сквида на мыло...
$ squid-parser.pl 2009-07-12 < squid-access.log | mail blabla@company.com 
Собственно, скрипт, наваянный на скорую руку:
#!/usr/bin/perl -w

# aggregates squid logs

use strict;

use POSIX qw(strftime);
my $pattern = $ARGV[0];


my $line;
my @fields;

my $date;

my $ip;
my $bytes;
my $url;

my %ipstats;

my %urlstats;
my %ipurlstats;
while ($line=<STDIN>)

{
        @fields = split ' ', $line;
        $date=POSIX::strftime("%Y-%m-%d %H:%M:%S", localtime($fields[0]));

        $ip=$fields[2];
        $bytes=$fields[4];

        $url=$fields[6];
        $url=~s/.*:\/\/([^\/]*)\/.*/$1/;

        if ($date =~ m/$pattern/)
        {

                $ipstats{$ip}+=$bytes;
                $ipurlstats{$ip}{$url}+=$bytes;


        }
}

my $urls;
my $mbytes;

while (($ip, $urls) = each (%ipurlstats))

{
        print "-------------------------------------------------\n";
        print "$ip:\n";

        print "----------------------------------------------- \n";
        foreach $url (sort {$urls->{$b} <=> $urls->{$a}} (keys %$urls))

        {
                print "$url: $urls->{$url} bytes \n";
        }

        $bytes = $ipstats{$ip};
        $mbytes = sprintf "%8.3f", $bytes/1024/1024;

        print "----------------------------------------------\n";
        print "Total: $bytes b ($mbytes MB)\n";
        print "----------------------------------------------\n\n";

}
5th-Jul-2009 10:10 pm - Красная шляпка и IPSec
Когда все просто - транспортный режим и нужно только зашифровать весь траффик от хоста А до хоста Б все понятно - делаем ifcfg-ipsec0 с содержимым вида
ONBOOT=yes
TYPE=ipsec
DST=A.A.A.A
IKE_METHOD=PSK


ну и потом ifup ipsec0. Но вот захотелось посмотреть, как же можно прикрутить более сложную политику, скажем, требовать шифрования или аутентификации только для пакетов на определенный порт и тут магия вдруг неожиданно исчезла... (пробовал A.A.A.A:AA или A.A.A.A[AA]). Ковыряние в ifup-ipsec не помогло совершенно.

Неужели дальше все делается только руками?

Оказывается, для свича с номинальным питанием 7V, если его питать по витой паре, нужно подавать не меньше 12V, если до него 100 метров или около того. А вообще надо бы попробовать купить 14V блок питания.

А все почему? Сегодня все началось с 16% packet loss и закончилось 100%. После поднятия напряжения с 9V до 12V - 2%. Красота, все счастливы.
Чем дольше пытаешься ковырять в ней что-то сетеовое, тем чаще начинаешь находить то, чего не хватает. Опять же - VMWare Workstation 6.0 очень хреново, как оказалось, рабоотает с групповым вещанием (multicasting). Поэтому какие-то практические попытки настроить RIPv2 без широковещания или юникаста - откладываются. Да и routed в режиме широковещания ведет себя достаточно странно. Про то что в ней нереально сделать бридж из виртуальной машины я уже писал.
20th-Mar-2008 01:03 pm - RIPv2
RIPv2 - это расширенная версия протокола RIPv1, основной целью которой было улучшение безопасности протокола RIP, а также увеличения количества полезной информации, передаваемой в пакетах обновления.
Сделано это за счет использования ранее забитых нулями полей заголовка и записей маршрутов. Принципиально сам пакет не менялся, поэтому маршрутизаторы, использующие RIPv1 могут продолжать принимать объявления RIPv2.
В записи маршрутов были добавлены маска и адрес следующего хопа, а также тег маршрута. То, что обновления RIPv2 стали переносить информацию о масках сетей, добавило в протокол поддержку VLSM, а не только классовой адресации.
Тег маршрута служит для указания источника, от которого был получен маршрут, хотя это поле может быть использовано и в других целях - главное, чтобы его назначение было одинаково для всех маршрутизаторов в области RIP.
Но кроме этого, заголовок обновления RIPv2 может быть расширен. Дело в том, что в протокол были добавлены возможности аутентификации обновлений. Поэтому в пакете могут быть встречены два поля - тип аутентификации, и, собственно, данные для аутентификации.
В официальнй версии RIP поддерживается только один тип аутентификации - прямым текстом (2).

Ну и последнее отличие - RIPv2 распространяет обновления не через широковещание, а через групповое вещание (адрес 224.0.0.9). Это позволило несколько снизить нагрузку на сеть от использования протокола.
Итак, мир давно отказался от классовой адресации. Сейчас классы сетей в основном используются только для назначения "умолчательной" классовой маски при настройке интерфейсов хостов. Вот, скажем, введете вы у себя в Windows в настройках tcp/ip адрес 10.0.0.1 - а он автоматически предложит маску 255.0.0.0. В остальном важность понятия класса сети уже утрачена.
Взамен пришли две технологии - VLSM, о которой я уже немножко писал и CIDR. Это две разные технологии, которые замечательно работают вместе и сетевым администраторам могут облегчать жизнь, если использовать их с умом (т.е. там где это реально нужно). Естественно, если у вас в конторе всего один офис из 7 компьютеров, вы можете вообще не изучать ничего из сетевых технологий - вам на этом месте это даже не пригодится. )
Read more... )
Я не знаю, как Microsoft позиционирует свою систему на маршрутизаторы и почему, потому что, имхо, это не лучший выбор по соотношению цены и возможностей. Но Windows Server поддерживает динамическую маршрутизацию и RIP в том числе. Как обычно, есть два варианта настройки - через rrasmgmt.msc и netsh
Read more... )
Тема эта - больше классика, чем практически полезная, потому что routed морально устарел. Но мне очень хотелось попробовать. )

Итак, чтобы включить routed в BSD-системе, необходимо в случае FreeBSD добавить вот такие строки в /etc/rc.conf:
router_flags=""
router="/sbin/routed"
router_enable="YES"

Либо, в случае OpenBSD - достаточно просто исправить "routed_flags="NO"" на что-то другое, например просто убрать "NO" в том же /etc/rc.conf:
router_flags=""

Можно, конечно, в соответстии с man routed, задать все опции в этих самых кавычках, но так как нам нужен RIP-демон, мы оставим конфигурацию по-умолчанию без ключей и будем пользоваться /etc/gateways для для его настройки. Routed сам определит, что он запущен на маршрутизаторе и начнет распространять маршруты. (Условия для этого - gateway="yes" и наличие более одного сетевого интерфейса).
Кроме RIP этот демон поддерживает и другие методы настройки маршрутизации, например, протокол ICMP, а точнее - сообщения, которые отвечают за анонс/поиск/объявление маршрутизатора. Но так как эти функции пока выходят за пределы рассказа про RIP, рассматривать их я не буду. Да и они, опять же - мало применимы практически и больше относятся к старой доброй классике...
Итак, судя по топологии из предыдущих постов, у нас есть по крайней мере один интерфейс, на котором мы RIP использовать не должны.
Поэтому наш /etc/gateways у нас будет выглядеть вот так:
if=lnc4 no_rip passive
no_rdisc

Он в первую очередь отключает рассылку обновлений через интерфейс lnc4, во вторых - отключает ICMP-функции по работе с маршрутами.

Но на OpenBSD такой метод запрета рассылки анонсов почему-то не прокатил. Поэтому в hostname.pcn3 к настойкам интерфейса я просто добавил метрику 16, что сделало маршрут в сеть на этом интерфейсе недоступным для RIP.:
# cat /etc/hostname.pcn3
inet 10.0.0.5 255.0.0.0 NONE description "Control Interface" metric 16

Да, и надо не забыть запустить routed:
# routed

Для отладки полезно использовать ключи -d и -t:
# routed -d -t 
-- 08:25:51 --
Tracing actions started
Add interface lo0                 -->/32             <loopback> <passive> 
RCVBUF=61440
Add interface pcn0 127.0.0.1      -->/24              
turn on RIP
Add interface pcn1 192.168.1.0    -->/24              
Add interface pcn2 192.168.249.0  -->/24              
Add interface pcn3 192.168.255.0  -->/8              metric=16 <passive> 
start suppying routes
Add    127.0.0.1       -->10.0.0.0         metric=16 <if> pcn3 08:25:51
Add    192.168.1.1     -->192.168.255.0    metric=0  <if> pcn2 08:25:51
Add    192.168.249.1   -->192.168.249.0    metric=0  <if> pcn1 08:25:51
Add    10.0.0.0        -->192.168.1.0      metric=0  <if> pcn0 08:25:51
Add    10.0.0.5/32     -->127.0.0.1        metric=0  <if> lo0 08:25:51

Еще один метод отладки - это использование tcpdump:
# tcpdump -s 512 -i pcn1 -n udp port 520
tcpdump: listening on pcn1, link-type EN10MB
08:29:45.192544 192.168.249.2.520 > 192.168.249.255.520:  RIPv1-resp [items 9]:
{192.168.2.0}(3) {192.168.3.0}(4) {192.168.4.0}(2) {192.168.6.0}(1) 
{192.168.250.0}(1) {192.168.251.0}(2) {192.168.252.0}(2) {192.168.253.0}(2) 
{192.168.254.0}(3) (DF)

Все это позволяет увидеть и то, что рассылает routed, и то, что он получает от соседей. В tcpdump мы видим как раз один из пакетов, которые выслала Quagga на linux-роутере, с маршрутами в известные ей сети.

Иными словами, настройка routed практически тривиальна и не сулит ничего сложного. Кроме RIPv1 он поддерживает и RIPv2. Кроме того, в нем отстутвуют настройки поведения протокола. И почему-то он ведет себя иногда довольно-таки странно. В общем, я так и не понял его местами. Например, в openbsd он почему-то не хочет делать ращепление горизонта, хотя в мануале написано - что он просто не умеет не делать этого.

Advertisement

Customize
This page was loaded Nov 9th 2009, 4:30 pm GMT.