RSS

Компьютерная терминология    1_9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  .....  A  Б  В  Г  Д  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч

Настройки сети

Как превратить Windows 7 / Windows Server 2008 R2 в точку доступа WiFi

В Windows 7/2008 появилась отличная функция, которая позволяет превратить вашу ОС в беспроводную точку доступа, которая может использоваться другими беспроводными клиентами в качестве точки доступа в Интернет.

В ОС Windows 7/Windows Server 2008 R2 с установленной службой Wireless LAN Service появилась новая WLAN функция под названием wireless Hosted Network (в документации Microsoft на русский переводится как беспроводная Размещенная Сеть). Эта служба реализует две основные функции:

Виртуализует физический беспроводной адаптер в несколько виртуальных беспроводных адаптеров, иногда называемых Virtual WiFi.

Реализует функцию программной точки доступа (AP), или SoftAP, которая использует необходимые виртуальные беспроводные адаптеры

 

Новости

Русское видео - https://rusfap.com/
 
WiFi windows7

Чтобы включить данную функцию, нужно воспользоваться командой netsh

Откройте командную строку с правами администратора

Выполните следующую команду:

netsh wlan set hostednetwork mode=allow ssid= <SSID NAME> key= <PASSWORD>

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

netsh wlan set hostednetwork mode=allow ssid= ConnectMe key= Connect1!

В приведенном выше примере, имя SSID ConnectMe, и ключ/пароль Connect1!

Затем выполните другую команду для того, чтобы включить hosted network:

netsh wlan start hostednetwork

В результате в сетевых подключениях появится виртуальный WiFi Miniport Adapter:

Теперь перейдите в свойства сетевого адаптера, который подключен к Интернету. В моем случае, это Wireless Network Connection

В свойствах перейдите на вкладку Sharing и отметьте галочкой опцию "Allow other network users to connect through this computer"s Internet connection" (Разрешить другим пользователям сети использовать это подключение к Интернету).

Вот и все! Теперь ваша машина с Windows 7/Windows 2008 R2 может обслуживать других беспроводных клиентов, работая в режиме точки доступа. В том случае, если вы запустите поиск точек доступа, в списке доступных вы увидите сеть с именем SSID, который вы создали. Как вы поняли, процедура настройки работы вашей Windows 7 в качестве точки доступа WiFi достаточно простая.

Управление сетями WiFi из командной строки

Список доступных интерфейсов можно узнать следующей командой:

netsh wlan show interface

Указать конкретный интерфейс, при помощи которого выполнять подключение:

netsh wlan connect name=ИмяПрофиляСети interface=ИмяИнтерфейса

Список WiFi сетей

Узнать, какие WiFi сети доступны, можно командной

netsh wlan show networks

Подключение к WiFi сети

Для подключения к WiFi сети служит команда

netsh wlan connect name=ИмяПрофиляСети

Отключение от WiFi сети

Чтобы отключиться от WiFi сети, необходимо выполнить следующую команду

netsh wlan disconnect

Указать конкретный интерфейс

netsh wlan disconnect interface=ИмяИнтерфейса

Профили WiFi сетей

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

Просмотреть все доступные профили:

netsh wlan show profile

Подключиться к сети с выбранным профилем:

netsh wlan connect ssid=ИмяСети name=ИмяПрофиляСети

Экспорт в XML файл и импорт профилей беспроводных сетей, синтаксис команды экспорта:

netsh wlan export profile name=ИмяПрофиля folder=Путь:\К\Папке\ДляХранения\XML-файлов

Указать беспроводной интерфейс, которому соответствует профиль.

netsh wlan export profile name=ИмяПрофиля folder=Путь:\К\Папке\ДляХранения\XML-файлов

Поместить ключ подключения к сети в открытом виде. Если это требуется, необходимо дополнить команду опцией key=clear:

netsh wlan export profile name=ИмяПрофиля folder=Путь:\К\Папке\ДляХранения\XML-файлов

Импорт профиля из XML файла:

netsh wlan add profile filename="D:\profiles\Wireless Network Connection 3-TRENDnet.xml"

Автоматическое создание скрипта для подключения к WiFi сети

Отобразить скрипт, используемый для подключения к WiFi сети:

netsh wlan dump

Перенаправить вывод в текстовый файл, вы сможете использовать его в дальнейшем для подключения к сети, например, на другом компьютере:

netsh wlan dump > d:\script.txt

Указать скрипт утилите Netsh:

netsh exec d:\script.txt

Узнать полный список опций Netsh:

netsh ?

Получить все команды, относящиеся конкретно к управлению WiFi:

netsh wlan ?

FAQ По командам OpenVPN в Windows

Режимы работы OpenVPN

Код * dev [tun | tap] (сервер, клиент) - указание типа интерфейса и режима работы: tun = L3-туннель, tap = L2-туннель

* dev-node TAP-interface-Name (сервер, клиент) - указание использование конкретного интерфейса, актуально если их в ситеме несколько и они по разному настроены в ОС (например, один tap и включён в мост, а второй - tun)

* proto [tcp-server | tcp-client | udp] (сервер, клиент) - протокол, по умолчанию UDP

* port 1194 (сервер, клиент) - номер порта, default=1194 (на клиенте для tcp-client игнорируется и используется динамический порт) lport (указание локального порта) и rport (указание удалённого порта).

* mode - задаёт режим работы сервера. По умолчанию OpenVPN работает в p2p-режиме, при указании mode server он работает в режиме сервера с многими клиентами.

* tls-server, tls-client - использование режима TLS

* ifconfig Local-IP Remote-IP/NetMask (сервер, клиент) - задаёт конфигурацию интерфейса.

Для dev tun: ifconfig Local-IP Remote-IP - указывает IP-адрес локального интерфейса и адрес второй стороны туннеля. Важно, что в режиме клиент-сервер в отличие от режима static-key второй стороной туннеля является не адрес сервер и не адрес клиента, а адрес виртуального интерфейса виртуального OpenVPN-роутера

Для dev tap: ifconfig Local-IP NetMask - указывает IP-адрес и маску локального интерфейса.

Команды настройки сервера

Код* server network netmask (сервер) - макрокоманда конфигурации сервера. Задаёт сеть и маску для всей OpenVPN-сети. Первый адрес из этой сети назначается интерфейсу сервера, остальные выделяются клиентам. Не используйте эту макрокоманду для режима L2-моста, для этого есть server-bridge.

Реально команда, например, server 10.8.0.0 255.255.255.0 раскрывается так (в скобках комментарии)

Для режима dev tun:

mode server

tls-server

ifconfig 10.8.0.1 10.8.0.2 (серверу назначается первый адрес из первой подсети /30)

ifconfig-pool 10.8.0.4 10.8.0.251 (остальной блок адресов выделяется клиентам)

route 10.8.0.0 255.255.255.0 (системе объявляется маршрут на всю OpenVPN-сеть)

if client-to-client:

push "route 10.8.0.0 255.255.255.0" (если включен режим client-to-client, то клиентам также передаётся маршрут на всю OpenVPN-сеть)

else

push "route 10.8.0.1" (иначе, если не включен режим client-to-client, клиентам передаётся только маршрут на сервер)

Для режима dev tap:

ifconfig 10.8.0.1 255.255.255.0 (серверу назначается первый адрес)

ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0 (остальной блок адресов выделяется клиентам)

push "route-gateway 10.8.0.1" (клиентам объявляется адрес шлюза, через который, при необходимости, они могут назначать маршруты)

* server-bridge gateway netmask pool-start-IP pool-end-IP (сервер) - макрокоманда конфигурации сервера для режима L2-моста. Важно то, что в этом режиме IP-параметры мостового интерфейса настраиваются в системе! Здесь же параметр gateway может указывать или на этот же IP-адрес мостового интерфейса или на следующий шлюз в этой сети.

Реально команда, например, server-bridge 10.8.0.4 255.255.255.0 10.8.0.128 10.8.0.254 раскрывается так (в скобках комментарии)

mode server

tls-server

ifconfig-pool 10.8.0.128 10.8.0.254 255.255.255.0 (клиентам выделяется диапазон, указанный в макрокоманде)

push "route-gateway 10.8.0.4" (параметр gateway передаётся клиентам как шлюз)

* remote host (сервер) - в режиме tcp-server этот параметр на сервере работает как фильтр и принимает соединения ТОЛЬКО от указанного host.

* client-to-client (сервер) - разрешает обмен трафиком между клиентами для режима dev tun

* ifconfig-pool-persist File_Name [Time_in_seconds] (сервер) - задаёт файл, в котором на указанное время (по умолчанию 600 сек) кэшируются выданные адреса клиентам, что позволяет при переподключении выдать клиенту тот же адрес.

* ifconfig-pool-linear (сервер) - задаёт для dev tun режим распределения адресов клиентам не подсетями /30, а "поштучно", то есть /32. Несовместим с Windows!

* management localhost 8329 (сервер, клиент) - открыть порт 8329 на интерфейсе 127.0.0.1 для управления.

Команды настройки маршрутизации

Код* route network/IP [netmask] [gateway] [metric] (сервер, клиент) - добавляет указанный маршрут в ОС после установления соединения. Значения параметров по умолчанию:

netmask по умолчанию равно 255.255.255.255.

gateway по умолчанию равно параметру, указанному в команде route-gateway или второму параметру команды ifconfig в режиме dev tun. То есть, по умолчанию исользуется шлюз в "OpenVPN-сеть". Если же нужно параметр указать (например, если нужно задать метрику), то это же значение можно указать ключевым словом vpn_gateway. Кроме того есть ещё ключевое слово net_gateway - это основной шлюз, который был в ОС до установления OpenVPN-соединения.

* iroute network [netmask] - применяется в client-connect script или в client-config-dir файле, указывает OpenVPN-серверу, что данная сеть находится за соответствующим клиентом. Важно, что это только указание OpenVPN-серверу, для задания этого маршрута самой ОС надо указывать route или в конфиге сервера или вообще в самой ОС.

* route-method exe (сервер, клиент) - указывает OpenVPN-у, что добавление маршрута надо делать не через API, а через route.exe.

* route-delay 10 (сервер, клиент).

Команды конфигурирования клиентов на стороне сервера

Код * client-config-dir Dir_Name (сервер) - использовать из указанного каталога дополнительные индивидуальные файлы для конфигугации каждого клиента, файлы должны называться так же как и CN клиента (Common Name, то есть то что укзывается при конфигурации ключа клиента командой build-key). Расширения у файла быть не должно, то есть, например, для клиента client1 файл так и должен называться - client1

* push "команда" - указывает серверу передать "команду" клиенту. Например, команда в конфиге сервера push "ping 10" - это не команда ping 10 самому серверу, а указание серверу передать команду ping 10 клиенту. Описание самих команд для push даны отдельно. Это могут быть route, route-gateway, route-delay, redirect-gateway, ip-win32, dhcp-option, inactive, ping, ping-exit, ping-restart, setenv, persist-key, persist-tun, echo

* push-reset (сервер, но в client-config-dir-файле) - указывает, что для данного клиента надо проигнорировать все глобальные команды push. Однако все push-команды из самого client-config-dir-файла будут исполнены.

* ifconfig-push Local-IP Remote-IP/NetMask (сервер) - применяется в client-connect script или в client-config-dir файле, задаёт конфигурацию интерфейса соответствующего клиента.

Для dev tun: ifconfig Local-IP Remote-IP - указывает IP-адрес локального интерфейса клиента и адрес второй стороны туннеля. Важно, что в режиме клиент-сервер второй стороной туннеля является не адрес сервер и не адрес клиента, а адрес виртуального интерфейса виртуального OpenVPN-роутера

Для dev tap: ifconfig Local-IP NetMask - указывает IP-адрес и маску локального интерфейса

Команды конфигурирования клиентов на стороне клиента

Код* client - макрокоманда режима клиента, исполняется так:

pull (указывает клиенту принимать от сервера команды, которые на сервере заданы как push)

tls-client

* nobind (клиент) - указание использовать динамический порт на клиенте, актуально только для udp, т.к. для tcp на клиенте всегда используется динамический порт.

* remote host [port] (клиент) - указание второй стороны, host может быть как DNS-именем, так и IP-адресом. Клиент обязан иметь эту строку, причём она может быть не одна - это обеспечивает возможность подключения к разным интерфейсам сервера (отказоустойчивость) или распределение нагрузки.

* remote-random (клиент) - использовать в случайном порядке одну из нескольких строк remote

* resolv-retry infinite (клиент) - пытаться бесконечно определить адрес сервера (при указании его по имени), чтобы "обойти" проблему с завершением попытки установления соединения при отказе DNS или сбое внешних соединений

* redirect-gateway [local] [def1] (клиент) - переключение шлюза на удалённый, есть 2 доп.параметра - local и def1 - изменяет маршрут не методом удаления старого маршрута 0.0.0.0/0 и назначением нового, а методом назначения двух более узких маршрутов 0.0.0.0/1 и 128.0.0.0/1

* dhcp-option DNS 192.168.1.254 (клиент) - использование удалённого DNS

* dhcp-option WINS 192.168.1.254 (клиент) - использование удалённого WINS

Другие команды

Код * comp-lzo (сервер, клиент) - сжатие трафика

* status openvpn-status.log (сервер, клиент) - периодически сохранять информ. о текущем состоянии в указанный файл, это текстовый файл.

* log openvpn.log или log-append openvpn.log (сервер, клиент) - сохранять или добавлять лог в указанный файл

* keepalive 10 60 (сервер) - макрокоманда "пинговать" противоположную сторону туннеля с указанным периодом 10 сек, при отсутствии встречных пингов в течение 60 сек считать туннель упавшим и запускать пересоединение. Полезно также для поддержания статуса работающего udp-потока в транзитных NAT-шлюзах.

Реально исполняется так (в скобках комментарии):

Для mode server:

ping 10 (сервер посылает OpenVPN-ping каждые 10 секунд. Не путать с ping в IP - здесь на OpenVPN-ping удалённая сторона не отвечает, поэтому эти пакеты надо отправлять с обеих сторон)

ping-restart 120 (при отсутствии встречных пакетов, то есть от клиента, в течении 120 сек сервер перезапускает клиентскую сессию. Не путать, перезапускается НЕ ВЕСЬ OpenVPN-СЕРВЕР!)

push "ping 10" (сообщить клиентам пинговать сервер каждые 10 секунд)

push "ping-restart 60" (сообщить клиентам, что при отсутствии пингов от сервера в течение 60 секунд, клиент должен перезапустить свою сессию).

Для mode p2p:

ping 10

ping-restart 60

Расширенная конфигурация туннеля L3 (IP-туннель, aka "routed")

Код

В данном режиме OpenVPN-сервер эмулирует работу некоего многопортового виртуального маршрутизатора, к каждому порту которого подключен каждый клиент и сам серверный хост. При этом каждому виртуальному tun-интерфейсу хоста (и сервера в том числе) присваивается IP-адрес, также присваиваивается IP-адрес соответствующему порту этого виртуального маршрутизатора и выделяется подсеть, включающая эти 2 адреса + неожходимые 2 служебных, в итоге для каждого подключения выделяется подсеть /30 (255.255.255.252) из 4 адресов, назначение которых, например, для первой подсети 10.1.1.0/30 из OpenVPN-сети 10.1.1.0/24 таково:

10.1.1.0 - адрес подсети 10.1.1.0/30

10.1.1.1 - адрес tun-интерфейса сервера

10.1.1.2 - адрес интерфейса виртуального маршрутизатора

10.1.1.3 - адрес широковещания (broadcast)

Далее каждому подключающемуся клиенту выделяются подсеть и адрес именно блоками /30, то есть по 4 адреса.

Замечу, что к самим IP-адресам виртуального маршрутизатора непосредственно обратиться никак нельзя, оне НЕ ПИНГУЮТСЯ, и в tracert не отображаются.

Ключи

Код

Все действия производятся в папке C:\Program Files\OpenVPN\easy-rsa

Действия выполнять так, чтобы сохранялся контекст переменных, например, в командной строке без выхода из неё. Первой командой при каждой операции работы с ключами (кроме начальной инициализации) должна быть vars.bat.

Начальная инициализация, выполняется 1 раз

* init-config.bat - начальная инициализация, создаст файлы vars.bat и openssl.cnf

В файле vars.bat надо установить ВСЕ параметры

set HOME=%ProgramFiles%\OpenVPN\easy-rsa

set KEY_CONFIG=openssl.cnf

set KEY_DIR=keys # путь к папке ключей относительно текущей (..\easy-rsa)

set KEY_SIZE=1024

set KEY_COUNTRY=ZZ

set KEY_PROVINCE=ZZ

set KEY_CITY=ZZZ

set KEY_ORG=ZZZ

set KEY_EMAIL=zz@zzz.zz

* vars.bat

* clean-all.bat # очистка и инициализация папки ключей

Создание master Certificate Authority (CA) certificate & key, выполняется 1 раз

* vars.bat

* build-ca.bat # генерация сертификата и ключа - ca.crt, ca.key

Генерация сертификата и ключа для сервера, выполняется 1 раз

* vars.bat

* build-key-server ServerName # ServerName - имя сервера. На некоторые доп вопросы можно ответить 2 раза "пусто", на 2 последних - "y":

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

В результате будет создан ключ ServerName.key, сертификат ServerName.crt, запрос Certificate Signing Request (CSR) ServerName.csr, ?непонятный файл? 01.pem (копия ServerName.csr)

Генерация Diffie Hellman parameters, выполняется 1 раз, нужно только для tls-server

* vars.bat

* build-dh # работает около минуты, грузит CPU под 100% , генерит файл dh1024.pem

Генерация сертификатов и ключей клиентов, выполняется по необходимости

* vars.bat

* build-key client1

* build-key client2

* build-key client3

ВАЖНО!!! В вопросе "Common Name (eg, your name or your server's hostname) []:" нужно для каждого ключа указывать УНИКАЛЬНОЕ имя, например, client1, и т.д.

В результате будет создан ключ client1.key, сертификат client1.crt, запрос Certificate Signing Request (CSR) client1.csr, ?непонятный файл? 02.pem (копия client1.csr)

В итоге имеем:

ключи *.key # секретная информация, должны распространяться ТОЛЬКО ПО СЕКРЕТНЫМ КАНАЛАМ. Нужны только на соотв. хостах.

сертификаты *.crt # несекретная информация.

запросы серт. *.csr # Certificate Signing Request, нужны для распределённой генерации и сертификации ключей.

dh1024.pem # Diffie Hellman parameters

Вместо использования на клиентах 3-ёх раздельных файлов (ca, cert, key) можно использовать единый файл формата PKCS12. Для этого надо генерировать ключ клиента командой:

build-key-pkcs12 client1

Будет создан и обычный комплект файлов, и новый файл .p12 - это и есть этот комбинированный файл. Его можно использовать в конфиге клиента одной командой pkcs12 вместо трёх команд ca, cert, key.

Также при генерации этому файлу можно задать пароль для защиты секретного ключа, в таком случае каждый раз при установке соединения будет запрашиваться пароль для доступа к секретному ключу (Внимание! Так нельзя делать при запуске сервиса, т.к. он не сможет запросить пароль и не сможет установить соединение.). Следует также иметь ввиду, что пользователь имеет право самостоятельно изменить/удалить/установить пароль защиты секретного ключа.[/ list]

Отзыв сертификатов клиентов, выполняется по необходимости, например, при утере ключа или пароля, утечке или компрометации ключа клиента.

* vars.bat

* revoke-full client1

Будет сгенерирован файл crl.pem в каталоге keys, этот файл и должен быть параметром инструкции "crl-verify crl.pem". Этот файл несекретный, но от несанкционированных изменений должен быть защищён. После отзыва можно сгенерировать новый ключ с тем же CN-именем (Common Name).

Конфигурация сервера - Server.ovpn

Код

Здесь и далее, параметры указывающие на файлы можно (или даже желательно) указывать с полными путями. Для Windows символ "\" указывается как "\\", пути с пробелами брать в кавычки, например: "C:\\Program Files\\OpenVPN\\config\\ca.crt". В примере это не указано чтобы не загромождать.

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"

cert server.crt

key server.key # секретный файл

dh dh1024.pem

dev tun

server 10.8.0.0 255.255.255.0

Необязательные параметры (кроме общеупотребимых):

push "route 192.168.10.0 255.255.255.0"

Конфигурация клиента - Client.ovpn

Код

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"

cert client.crt

key client.key # секретный файл

dev tun

client

remote 1.1.1.1 1194

Необязательные параметры (кроме общеупотребимых):

remote server.com 1194

remote-random

resolv-retry infinite

Расширенная конфигурация туннеля L2 (Ethernet-туннель, aka "bridged")

Код

В данном режиме тунелируются не IP-пакеты, а пакеты Ethernet, что позволяет использовать поверх такого OpenVPN-соединения:

* не только IP-протокол, но и, например, IPX (лично не проверено)

* приложения работающие только в пределах своей подсети

* приложения, работающие через broadcast (например, NetBIOS)

* иметь доступ к внутренним ресурсам, которые в силу разных причин не имеют настроенного шлюза

* без дополнительных настроек (например, настройка NAT на шлюзе для дополнительной OpenVPN-подсети) использовать перенаправление трафика командой redirect-gateway

В этой схеме на клиенте доступ к удалённой сети производится напрямую, то есть реально через ARP и т.п. Например, 192.168.1.191 - VPN-клиент, а 192.168.1.101 - хост в удалённой сети.

Конфигурация сервера - Server.ovpn

Код

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"

cert server.crt

key server.key # секретный файл

dh dh1024.pem

dev tap

server-bridge 192.168.1.254 255.255.255.0 192.168.1.190 192.168.1.199

# в предыд.команде 192.168.1.254 255.255.255.0 это шлюз из лок.сети во внеш.сети и маска,

# 192.168.1.190 192.168.1.199 - диапазон для VPN-хостов

Необязательные параметры (кроме общеупотребимых):

# команды ниже могут назначить шлюзование всего трафика клиента через VPN

push "route-gateway 192.168.1.254"

push "dhcp-option DNS 192.168.1.254"

push "dhcp-option WINS 192.168.1.254"

push "redirect-gateway"

Конфигурация клиента - Client.ovpn

Код

ca ca.crt # ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"

cert client.crt

key client.key # секретный файл

dev tap

client

remote server.com 1194

remote 1.1.1.1 1194

Необязательные параметры (кроме общеупотребимых):

ifconfig 192.168.1.190 255.255.255.0 # явное указание IP-адреса, назначаемого интерфейсу

dhcp-option DNS 192.168.1.254 # использование удалённого DNS

dhcp-option WINS 192.168.1.254 # использование удалённого WINS

redirect-gateway

Некоторые распростанённые проблемы и методы решения

Код

# После установки в ОС создаётся новый сетевой интерфейс с "адаптером" TAP-Win32 Adapter V8, отображаемый ОС как сетевой адаптер с неподключенным кабелем, он же может отбражаться в области значков. Это виртуальный адаптер OpenVPN. Его можно переименовать по желанию и это имя можно будет использовать в конфиг-файлах в команде dev-node TAP-interface-name

1. Этот адаптер НЕ НУЖНО отключать (распространённое явление - не устанавливается OpenVPN-соединение т.к. отключен этот интерфейс)

2. На этом адаптере в общем случае НЕ НУЖНО настраивать никакие параметры IP-протокола (кроме NetBIOS, см.ниже), включение и конфигурация этого интерфейса производятся автоматически при установке OpenVPN-соединения.

3. Если не нужен NetBIOS, то во избежание проблем с NetBIOS-ом, свойственных multihomed-хостам РЕКОМЕНДУЕТСЯ отключить NetBIOS для данного интерфейса: сетевые подключения - свойства данного сетевого интерфейса – свойства протокола TCP/IP – дополнительно – WINS – Параметры NetBIOS = Отключить NetBIOS через TCP/IP.

4. На этом адаптере во избежание непонятных проблем желательно НЕ ВКЛЮЧАТЬ фаервол (брандмауэр), по крайней мере на начальном этапе установки, изучения и запуска.

# Не происходит добавление маршрута в таблицу маршрутизации, вероятно при включенной службе RRAS (чаще всего возникает на серверных ОС, например, Windows Server 2003, но встречал и на XP) - ошибка:

"NOTE: FlushIpNetTable failed on interface [2] {427E6BDF-F41F-4E7A-B8C4-4F12B25A6C11} (status=1413) : Invalid index."

Похоже дело в Win-довом глюке, по API-команде windows должна добавить маршрут, при этом если в конфиг OpenVPN вставить show-net-up, то OpenVPN запросит windows через API всю таблицу маршрутизации и выведет её в лог, там нужный маршрут будет. А если сделать "route print", то маршрута не будет...

Решение: "route-method exe" в конфиг.файле - это указывает OpenVPN-у, что добавление маршрута надо делать не через API, а через route.exe. Кроме того, может потребоваться небольшая задержка перед добавлением маршрута через route.exe (встречалось, что без задержки route.exe ещё не видит только что появившийся интерфейс и не добавляет маршрут), это делается route-delay 10 (на серверах лично меня "не напрягает" задержка 10 секунд, на клиентах можно уменьшить до экспериментально вычисленного предела)


На главную | Cookie policy | Sitemap

 

po gonn © 2004