Главная страница
Навигация по странице:

  • Внимание!

  • ViPNet Coordinator Linux. Руководство администратора |62

  • ViPNet Coordinator Linux. Руководство администратора |63

  • ViPNet Coordinator Linux. Руководство администратора |64

  • ViPNet Coordinator Linux. Руководство администратора |65

  • Без использования межсетевого экрана

  • Координатор

  • ViPNet Coordinator Linux. Руководство администратора |66

  • Со статической трансляцией адресов (см. «Настройка режима „Со статической трансляцией адресов“» на стр. 107) или С динамической трансляцией адресов

  • ViPNet Coordinator Linux. Руководство администратора |67

  • Решение задач vipnet linux. vipnet_linux решение задач. Руководство администратора


    Скачать 1.91 Mb.
    НазваниеРуководство администратора
    АнкорРешение задач vipnet linux
    Дата18.04.2022
    Размер1.91 Mb.
    Формат файлаpdf
    Имя файлаvipnet_linux решение задач.pdf
    ТипРуководство
    #482334
    страница5 из 17
    1   2   3   4   5   6   7   8   9   ...   17
    Внимание! Если у двух узлов с совпадающими реальными адресами (но разными виртуальными) установить параметр forcereal в значение on
    , это приведет к непредсказуемым результатам.

    always_use_server
    – признак работы узла в режиме использования межсетевого экрана с динамическим NAT с направлением трафика через выбранный Координатор
    (см. «
    Настройка режима „С динамической трансляцией адресов“
    » на стр. 109).
    Параметр принимает значение on и присутствует только в случае работы данного узла в указанном режиме.
    Внимание! Параметр always_use_server является служебным и менять его вручную не следует.

    ViPNet Coordinator Linux. Руководство администратора
    |
    61

    secondaryvirtual
    – механизм назначения виртуальных адресов для данного узла.
    Этот параметр может принимать значение on или off
    , значение off равноценно отсутствию этого параметра в секции (при этом параметр удаляется из секции при следующем запуске управляющего демона). При включении данного параметра каждому реальному адресу сетевого узла, указанному в параметре ip
    , назначается виртуальный адрес (см. «
    Общие принципы назначения виртуальных адресов
    » на стр.
    76). Если данный параметр отсутствует или его значение равно off
    , то механизм назначения виртуальных адресов для каждого реального адреса данного узла выключается, работа с узлом осуществляется только с использованием базового виртуального адреса, определяемого параметром virtualip
    . В этом случае все виртуальные адреса, присутствующие в параметрах ip
    , удаляются из файла конфигурации. По умолчанию данный параметр отсутствует.

    filterdefault
    – действие над пакетами, направленными к данному узлу или от него, по умолчанию, если они не подпадают под более конкретные фильтры.
    Параметр может принимать значение pass
    (пропускать пакеты) или drop
    (не пропускать пакеты). Каждая секция
    [id]
    имеет только один параметр filterdefault

    blockforward
    – включение/отключение блокировки транзитных пакетов, идущих от данного узла либо к нему. Этот параметр может принимать значение on или off
    , значение off равноценно отсутствию этого параметра в секции. По умолчанию параметр отсутствует для всех узлов. При включении данного параметра все транзитные пакеты для данного узла блокируются с кодом 70 (см. «
    Программа просмотра журнала регистрации IP-пакетов
    » на стр. 128). Параметр разрешается использовать только в секциях для чужих узлов. Его указание в собственной секции, а также в главном и широковещательном фильтрах защищенной сети является ошибкой, при этом управляющий демон не запускается.

    filtertcp
    – правила для пропускания или блокировки пакетов TCP. Значение этого параметра состоит из четырех или пяти частей, разделенных запятыми. Первая часть содержит номер локального порта TCP-соединения, вторая – номер удаленного порта
    TCP-соединения. В обоих случаях можно указывать вместо одного номера порта диапазон, в этом случае начало и конец диапазона разделяются дефисом. Обратите внимание на то, что, в отличие от большинства распространенных сетевых экранов, в
    ViPNet эти номера портов не зависят от направления пакета, они не описывают номера портов отправителя и получателя, а всегда описывают локальный и удаленный порт, независимо от того, в каком направлении идет пакет. Третья часть описывает, что нужно делать с пакетом, и может принимать значение pass
    (пропускать) или drop
    (блокировать). Четвертая часть описывает направление TCP- соединения и может принимать значения send
    , recv и any
    . Эта часть также описывает не направление пакета, а направление TCP-соединения, т. е. какой узел являлся при установлении TCP-соединения клиентом, а какой - сервером. Если она принимает значение send
    , то из TCP-пакетов, имеющих номера локального и удаленного портов, соответствующие указанным, под правило подпадают пакеты, относящиеся к

    ViPNet Coordinator Linux. Руководство администратора
    |
    62
    соединениям, в которых данный узел являлся клиентом, при этом направление самих пакетов не имеет значения. Если она принимает значение recv
    , то под правило подпадают пакеты, относящиеся к соединениям, в которых данный узел являлся сервером. Наконец, при значении any под правило подпадают любые пакеты с соответствующими номерами портов. Пятая часть необязательна и может принимать значение disable
    , которое указывает на временное отключение данного фильтра, при этом он ведет себя так, как будто его не существует.
    Например, правило filtertcp= 22, 1024-65535, pass, recv указывает, что должны пропускаться TCP-пакеты, относящиеся к тем соединениям, в которых удаленный узел, использующий номер порта от 1024 до 65535, установил соединение с портом 22 данного узла. При этом пакеты пропускаются в обоих направлениях. С другой стороны, это правило не разрешает пропускание пакетов, где данный узел устанавливает соединение с портом 22 удаленного узла.

    filterudp
    – правила для пропускания или блокировки пакетов UDP. Синтаксис этого параметра аналогичен синтаксису параметра filtertcp с одним отличием: поскольку протокол UDP не подразумевает установку соединений, то четвертая часть правила, описывающая направление, относится непосредственно к направлению, в котором идет пакет: o send для пакета, посланного с данного узла; o recv для пакета, посланного на данный узел; o any для обоих направлений.

    filtericmp
    – правила для пропускания или блокировки пакетов ICMP. Синтаксис этого параметра похож на синтаксис параметра filterudp
    , однако вместо номеров портов указывается тип и подтип сообщений ICMP: первая часть задает тип, а вторая
    – подтип. При их задании также можно указывать диапазоны. Остальные части правила имеют то же значение, что и для параметра filterudp
    Каждая секция
    [id]
    может содержать сколько угодно параметров filtertcp
    , filterudp и filtericmp
    . При приходе какого-либо пакета от данного узла или посылке пакета на него фильтры просматриваются в том порядке, в котором они указаны. Если пакет соответствует какому-либо правилу, то выполняется заданное этим правилом действие, и просмотр правил на этом прекращается. Если пакет не соответствует ни одному правилу, то выполняется действие, заданное параметром filterdefault

    filterip
    – правила обработки пакетов, соответствующих протоколам IP, отличным от TCP, UDP и ICMP (например, IGMP и т.п.). Значение этого параметра состоит из двух частей, разделенных запятыми. В первой части указывается номер протокола IP.
    Вторая часть описывает, что нужно делать с пакетом, и может принимать значение

    ViPNet Coordinator Linux. Руководство администратора
    |
    63
    pass
    (пропускать) или drop
    (блокировать). Указание в этом правиле номеров протоколов ICMP, TCP и UDP (1, 6 и 17) считается ошибкой. Каждая секция
    [id]
    может содержать любое количество параметров filterip

    filterservice
    – правила обработки пакетов, соответствующих какому-либо сервису. Сервис представляет собой именованную совокупность правил filtertcp
    , filterudp
    , filtericmp
    (см. ниже). Значение этого параметра состоит из двух или трех частей, разделенных запятыми. Первая часть – это имя сервиса, на соответствие которому будет проверяться пакет. Вторая часть описывает действие с пакетами – pass или drop
    . Третья часть необязательна, если она указывается, то может принимать только значение inform
    . Если третья часть указана, то после старта управляющего демона после данной строки filterservice вставляются служебные комментарии, которые описывают, какую именно совокупность правил представляет данный сервис.

    tunnel
    – незащищенные компьютеры, которые туннелируются данным узлом.
    Имеет смысл только для узла, являющегося Координатором. Значение этого параметра имеет вид:
    - to -
    , где ip1
    и ip2
    – начальный и конечный адреса туннелируемого диапазона, ip3
    и ip4
    – начало и конец отображения этого диапазона на данном узле. В большинстве случаев нужно задавать одинаковые диапазоны, то есть ip3
    такое же, как и ip1
    , и ip4
    такое же, как ip2
    . Однако иногда бывают случаи, когда диапазон ip1-ip2
    принадлежит к частной сети, и такие же адреса частной сети уже есть в локальной сети данного узла. В этом случае диапазон ip1-ip2
    отображается на другие, свободные адреса путем указания других значений ip3
    и ip4
    . Следует отметить, что значение ip4
    игнорируется и генерируется автоматически путем прибавления к ip3
    разницы между ip2
    и ip1
    . Например: tunnel= 192.168.201.5-192.168.201.10 to 192.168.201.5-192.168.201.10
    задает, что данный Координатор туннелирует адреса с 192.168.201.5 по
    192.168.201.10, которые отображаются на локальной машине без изменения; tunnel= 192.168.201.5-192.168.201.10 to 192.168.202.5-192.168.202.10
    задает, что данный Координатор туннелирует адреса с 192.168.201.5 по
    192.168.201.10, которые отображаются на адреса с 192.168.202.5 по 192.168.202.10.
    Параметры tunnel не рассылаются по сети. Это означает, что если какой-либо
    Координатор туннелирует группу незащищенных компьютеров, то другие узлы не получат информацию об этом автоматически. Необходимо вручную указать, что данный Координатор будет туннелировать данные компьютеры, на каждом узле, который будет работать с этими туннелируемыми компьютерами посредством
    ViPNet.
    Подробные примеры настройки туннелей в типовых схемах приведены в
    Приложении (см. «
    Примеры настройки туннелей с использованием Координаторов
    ViPNet
    » на стр. 184).

    ViPNet Coordinator Linux. Руководство администратора
    |
    64
    Некоторые из секций
    [id]
    имеют специальное значение. Самая первая секция
    [id]
    описывает компьютер, на котором установлен ViPNet Coordinator Linux. Путем изменения параметров этой секции можно изменять собственные настройки, которые затем рассылаются по сети.
    Несколько замечаний, касающихся собственной секции
    [id]
    :

    Менять параметры ip не следует. Они автоматически заполняются при старте управляющего демона значениями, полученными от операционной системы.

    Изменяя параметры usefirewall, firewallip, port, proxyid, fixfirewall в совокупности с изменением параметров секции
    [dynamic]
    (см. ниже), можно установить различные режимы работы через межсетевой экран (см. «
    Режимы работы
    ПО ViPNet через межсетевой экран
    » на стр. 27). Описание настроек различных режимов функционирования собственного узла через межсетевой экран приведено в разделе
    Настройка режимов работы через межсетевой экран
    (на стр. 105).

    Если собственный узел будет туннелировать какие-либо незащищенные компьютеры, то при указании параметра tunnel нужно всегда задавать одинаковые значения для реального диапазона адресов и диапазона отображения. В этом случае параметр tunnel должен иметь вид tunnel= ip1-ip2 to ip1-ip2
    . При несоблюдении этого правила диапазон отображения приводится в соответствие с реальным диапазоном автоматически.
    С помощью параметров собственной секции
    [id]
    также настраиваются различные режимы работы ViPNet Coordinator Linux (см. «
    Режимы работы ПО ViPNet через межсетевой экран
    » на стр. 27). Более подробно установка и настройка этих режимов описана ниже. При этом необходимо уделять внимание настройке маршрутизации.
    Следует соблюдать несколько правил:

    Если собственный узел туннелирует какие-либо компьютеры, то на всех туннелируемых компьютерах необходимо указать собственный узел в качестве default gateway

    Если собственный узел будет работать хотя бы с одним узлом по виртуальному адресу, то у него должен быть настроен default gateway
    . Если default gateway не будет указан, то пакет может быть блокирован системой на ранней стадии и вообще не дойти до драйвера.

    Если собственный узел используется как прокси-сервер, то на нем должна быть включена функция
    IP forwarding
    (параметр ipforwarding в секции
    [misc]
    (см.
    «
    Секция [misc]
    » на стр. 69) должен быть установлен в значение on
    ).

    ViPNet Coordinator Linux. Руководство администратора
    |
    65
    За первой секцией
    [id]
    следуют две секции, также имеющие специальное значение. Они отличаются от других значением параметра id
    , равным
    0xffffffff и
    0xfffffffe
    . Эти секции предназначены только для установки фильтров. Для этих двух секций имеют смысл только следующие параметры: filtertcp, filterudp, filtericmp, filterip, filterdefault
    . Секция с id= 0xffffffff отвечает за широковещательные пакеты, посылаемые сетевыми узлами. Установкой соответствующих фильтров в этой секции можно запрещать или разрешать прохождение определенных типов широковещательных пакетов. Секция с id= 0xfffffffe
    – это главный фильтр защищенной сети. Правила, указанные в нем, просматриваются до того, как начинается просмотр фильтров для конкретного узла. Если пакет подпадает под какое-либо правило, то он сразу пропускается или блокируется, и дальнейший анализ фильтров прекращается. Если же для главного фильтра пакет подпадает под правило filterdefault и он установлен в pass
    , то анализируются фильтры для конкретного узла. Установка filterdefault в drop для главного фильтра приведет к полному блокированию всех зашифрованных пакетов.
    Некоторый набор фильтров, необходимый для нормальной работы защищенной сети, устанавливается в главном фильтре автоматически и не может быть удален.
    Для связи с узлами, описанными в параметрах секций
    [id]
    , могут использоваться реальные или виртуальные адреса. Независимо от режимов работы узлов, для связи с узлами, от которых собственный узел получает широковещательные пакеты (broadcast), используются их реальные адреса. В иных ситуациях используемый тип адреса для связи с узлом определяется следующим образом:

    Если собственный узел работает в режиме Без использования межсетевого экрана
    (см. «
    Настройка режима „Без использования межсетевого экрана“
    » на стр. 105), т.е. не стоит за внешним межсетевым экраном, то: o
    Для связи с Клиентами, работающими в режиме Без использования
    межсетевого экрана, т.е. не стоящими за какими-либо внешними межсетевыми экранами, используются реальные адреса. o
    Для связи с сетевыми узлами, работающими в режиме Координатор и использующими собственный узел как ViPNet-прокси, используются реальные адреса. o
    Для связи со всеми другими сетевыми узлами используются виртуальные адреса.

    Если собственный узел работает в режиме Координатор (см. «
    Настройка режима
    „Координатор“
    » на стр. 106), т.е. стоит за каким-либо ViPNet-прокси, то: o
    Для связи с Клиентами, работающими в режиме Без использования
    межсетевого экрана, т.е. не стоящими за какими-либо внешними межсетевыми экранами, используются реальные адреса. o
    Для связи с Координаторами, кроме используемого ViPNet-прокси, всегда используются виртуальные адреса.

    ViPNet Coordinator Linux. Руководство администратора
    |
    66
    o
    Для связи с сетевыми узлами, стоящими за тем же интерфейсом того же самого
    ViPNet-прокси, что и собственный узел (их firewallip равен firewallip собственного узла), а также для связи с самим ViPNet-прокси используются реальные адреса. o
    Для связи с сетевыми узлами, стоящими за тем же самым ViPNet-прокси, что и собственный узел, но за другим интерфейсом, а также работающими в режиме, отличном от режима Без использования межсетевого экрана, т.е. стоящими за какими-либо внешними межсетевыми экранами, используются виртуальные адреса.

    Если собственный узел работает в режиме Со статической трансляцией адресов
    (см. «
    Настройка режима „Со статической трансляцией адресов“
    » на стр. 107) или С
    динамической трансляцией адресов (см. «
    Настройка режима „С динамической трансляцией адресов“
    » на стр. 109), т.е. стоит за каким-либо внешним межсетевым экраном, то: o
    Для связи с Клиентами, работающими в режиме Без использования
    межсетевого экрана (см. «
    Настройка режима „Без использования межсетевого экрана“
    » на стр. 105), т.е. не стоящими за какими-либо внешними межсетевыми экранами, используются реальные адреса. o
    Для связи с сетевыми узлами, стоящими за тем же самым внешним межсетевым экраном, что и собственный узел (их firewallip равен firewallip собственного узла), используются реальные адреса. o
    Для связи со всеми другими сетевыми узлами используются виртуальные адреса.
    Во всех описанных выше случаях, когда для доступа к сетевому узлу должен использоваться виртуальный адрес, при установке для этого узла параметра forcereal
    (см. выше) для доступа к нему всегда используется реальный адрес.
    Описанные выше правила видимости сетевых узлов запоминать, как правило, не нужно.
    Текущий адрес доступа к сетевому узлу всегда отображается в параметре accessip соответствующей секции
    [id]
    , и любые обращения по сети к этому сетевому узлу должны производиться по этому адресу.
    Секция [adapter]
    Секции
    [adapter]
    описывают сетевые адаптеры, установленные на компьютере.
    Каждому адаптеру должна соответствовать своя секция
    [adapter]
    . Все пакеты на адаптерах, не описанных секциями
    [adapter]
    , блокируются. Если в файле iplir.conf нет ни одной секции
    [adapter]
    , то управляющий демон при старте получает от системы список адаптеров и автоматически создает секции
    [adapter]
    . В качестве параметров данной секции достаточно указать только параметры name и type
    (см. ниже). Параметр

    ViPNet Coordinator Linux. Руководство администратора
    |
    67
    ip указывать не обязательно, так как его значение будет получено от системы при запуске. В процессе работы управляющий демон производит периодический опрос параметров известных ему адаптеров с интервалом времени, задаваемым параметром ifcheck_timeout секции
    [misc]
    (см. «
    Секция [misc]
    » на стр. 69). Если обнаруживается, что адаптер деактивирован в системе, то он деактивируется и в драйвере сетевой защиты
    ViPNet. Если адаптер активируется или изменяется его адрес, то управляющий демон загружает эти изменения в драйвер. Информация обо всех описанных событиях выводится в системный журнал.
    В секции
    [adapter]
    указываются следующие параметры:

    name
    – системное имя адаптера, например, eth0, ppp0 и т.п.
    Если в системе заданы несколько IP-адресов на одном адаптере и присутствуют одно или несколько псевдоустройств (eth0:0, eth0:1 и т.д.), то для управляющего демона и драйвера все они будут представлять одно физическое устройство с базовым именем (eth0).

    ip
    – IP-адрес адаптера.
    Этот параметр заполняется автоматически и присутствует только для информационных целей. Для каждого адаптера может быть несколько параметров ip
    (например, если на адаптере используются дополнительные адреса).

    type
    – тип адаптера для ViPNet.
    Этот параметр можно устанавливать в одно из значений internal
    (внутренний) или external
    (внешний). Параметр заполняется, исходя из следующей логики: o
    Если узел не стоит за внешним межсетевым экраном или за ViPNet-прокси, т.е. работает в режиме
    1   2   3   4   5   6   7   8   9   ...   17


    написать администратору сайта