Объединение локальных сетей через интернет: Объединить две локальные сети в одну через интернет? — Хабр Q&A

Соединяем филиалы в одну сеть. Снижаем затраты на интернет / Хабр

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

Первоначальная цель была в экономии денег на Интернет трафике в филиалах т.к. в удалённых районах цена безлимитного ADSL с шириной в 256кб/с стоила порядка 7-10т.р. в месяц, а интернет был жизненно необходим.

Вся радость была в том, что почти все филиалы имели подключения одного провайдера, в котором существовало понятие локального и пирингово трафика, а в Главном офисе был выделенный широкий Интернет (другой провайдер, но волей случая он был лоялен к провайдеру филиалов и у него был «пиринговый трафик» с ценой около 6 копеек за мегабайт).

1. proxy

Самое быстрое решение это было обычный каскад proxy серверов, так и было сделано т.к. раньше все филиалы раздавали интернет у себя прямо модемом, то нужно было всем выделить по 1 системнику, который бы выполнял роль шлюза, системники были не подарки, кто даст 800й пень, кто 233, в общем у кого что было… Хотя сегодня за 4-7 т.р. можно собрать достойный шлюз, но хозяин-барин, хочу говорит без затрат!

На эти шлюзы была установлена ubuntu 8.04 LTS настроена в виде шлюза, чтоб воткнул в локальную сеть, в модем и в розетку, и сразу всё работало т.к. во многих филиалах, админы могли только нажать «Any key» на клавиатуре пользователя, но не беда, дело шло, постепенно 7 филиалов перенастроило свои модемы, и воткнули шлюзы 🙂

сразу же поднимали прокси каскадом, заруливали туда http трафик, но как мы все знаем, хттп трафик это всего некий % от общего трафика, перейдя на более простые тарифы, экономия была, но условная, ведь нерадивый админ или пользователь мог например через torrent стянуть что-то весомое, что сулило попаданием на деньги филиалу…

Попутно появлялись другие задачи в центральном офисе — перенос компаративного почтаря, шлюза, портала настроенного году в 2002 и не тронутого с тех пор, но это заслуживает отдельной статьи…

А нас пока интересует просто сеть…

2. OpenVPN

Эту штуку я видел в первый раз, был некий страх перед первым знакомством, далее чтение мануалов и интернетов, закатав рукава я полез ставить 🙂

2.1 Сервер

имеет 2 сетевых адаптера eth2 (192.168.5.x) — Локальная сеть и eth0 (real ip 111.111.111.111) Интернет с широким каналом.

apt-get install openvpn

Далее создаём файл конфигурации сервера
touch /etc/openvpn/server.conf

при загрузке системы автоматически поднимаются все VPN соединения, для которых в папке /etc/openvpn есть соответствующие файлы с расширением .conf

у меня он получился примерно таким.

port 1194 #Порт

proto udp #Протокол

dev tun #Название виртуального устройства

ca /etc/openvpn/ca.crt

cert /etc/openvpn/server.crt

key /etc/openvpn/server.key # This file should be kept secret

dh /etc/openvpn/dh2024.pem

server 10.10.10.0 255.255.255.0 # vpn subnet

ifconfig-pool-persist ipp.txt # Тут будут храниться ip адреса клиентов

push "route 192.168.5.0 255.255.255.0" # home

keepalive 10 120

comp-lzo

user nobody

group nogroup

persist-key

persist-tun

status openvpn-status.log

log-append openvpn.log

verb 4

mute 20

client-to-client

client-config-dir /etc/openvpn/ccd # Тут будут настройки для каждого филиала

route 192.168.0.0 255.255.255.0 # Маршрут от сервера до филиала 1

route 192.168.1.0 255.255.255.0 # Маршрут от сервера до филиала 2


Создаём каталог, в котором будут хранится индивидуальные настройки клиентов:

mkdir /etc/openvpn/ccd

Теперь необходимо создать ключи и сертификаты для шифрования и авторизации

cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

source ./vars

./clean-all

./build-ca

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

./build-key-server server

Создаём ключ для клиента (если клиентов несколько, процедуру придётся повторить):

./build-key client1

для каждого клиента должно быть указано своё уникальное имя (в данном случае client1).

если новый клиент создаётся спустя некоторое время, процедура будет выглядеть следующим образом:

cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

source ./vars

./build-key client2


Генерируем параметры Диффи-Хеллмана:

./build-dh

Помещаем следующие файлы в директорию /etc/openvpn/

* ca.crt

* server.crt

* dh2024.pem

* server.key

Создаём файл /etc/openvpn/ipp.txt

Конфигурационный файл клиентской машины /etc/openvpn/client.conf у меня получился примерно таким

remote 111.111.111.111 1194

client

dev tun

proto udp

resolv-retry infinite # this is necessary for DynDNS

nobind

user nobody

group nogroup

persist-key

persist-tun

ca /etc/openvpn/ca.crt

cert /etc/openvpn/client1.crt

key /etc/openvpn/client1.key

comp-lzo

verb 4

mute 20

redirect-gateway

#show-net-up

verb 4

Теперь необходимо скопировать с сервера в папку /etc/openvpn/ сгенерированные клиентские ключи и авторитарный сертификат сервера:
* ca.crt

* client1.crt

* client1.key

Если за клиентом скрывается сеть 192.168.1.х то, чтоб сервер видел её нужно добавить на сервер маршрут до неё.

На сервере создаём файл /etc/openvpn/ccd/client1 такого содержания:

iroute 192.168.1.0 255.255.255.0

# роутинг на сеть филиала2, чтоб 2 филиала знали друг друга

#push "route 192.168.100.0 255.255.255.0"

#Заворачиваем весь трафик в OpenVPN

push "redirect-gateway def1"


Вот тут собственно и случилась самая злая проблема у меня.

OpenVPN получив директиву
push "redirect-gateway def1"
(при наличии ‘pull’ в своей конфигурации), клиент не удаляет старый маршрут, а добавляет в таблицу маршрутизации записи вида:
0.0.0.0/1 via 192.168.231.5 dev tun0

128.0.0.0/1 via 192.168.231.5 dev tun0

и если openvpn идёт по ethernet то всё работает и радует админа и пользователей, но великий ppp любит поднимать вот такой маршрут.
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

И вот OpenVPN ругается примерно вот так
Jul 2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system

Решение этой проблемы искалось долго и нудно, хотя оно на поверхности. если в этом «кривом» маршруте ppp указывать шлюз вместо 0.0.0.0 реальный шлюз, то ОpenVPN видит этот маршрут и добавляет свой без проблем.

Поэтому я создал файл
/etc/ppp/ip-up.d/routing

В который прописал небольшой скрипт. (прошу ногами не пинать, я очень ленивый, и полноценный скрипт определения шлюза и правки маршрутов писать не стал, а сделал как простой костыль)
Буду очень рад, если кто-то предложит более логичный, надёжный, и универсальный метод правки маршрутов на лету.

Пока ещё нет уверенности, что всё будет на 100% работать при обрывах ppp, Но жизнь покажет, если что — поправлю топик.

#! /bin/sh

#Определяем выданный шлюз по умолчанию у меня он всегда разный но в сети 222.х.х.х

gw1=`ip route show | grep 222 | awk '{print $1}'`

# Удаляем 0.0.0.0 0.0.0.0

route del default

# Добавляем маршрут с верным шлюзом

route add -net default gw ${gw1} dev ppp0

Делаем его исполняемым
chmod ug+x /etc/ppp/ip-up.d/routing

После чего ребут, спустя некоторое время сервер перестал пинговаться по внешнему ипу, но стал отзываться по внутреннему — 10.10.10.26

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

Например я, сделал это так:
-A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADE

Тут не указана привязка ни к внешнему интерфейсу, ни ip 🙂

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

Заключение

В жизни эта система собирается поэтапно, сначала запускается впн сервер и впн клиент, пингуют друг друга по адресам 10.10.10.х дальше добавляются маршруты до сетей, что стоят за сервером и клиентом, пингуются проверяются, когда всё будет стабильно и надёжно добавляем директиву
push "redirect-gateway def1"

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

Ах да, чуть не забыл, о самом главном — profit

Помимо того, что теперь вся сеть обращается к серверам и сервисам филиалов и центра по внутренним ip адресам, так ещё и финансовая экономия.

Раньше каждый филиал тратил на интернет в среднем по 7 000р. в месяц, сейчас в месяц каждый из них платит по 550р. за доступ к пирингу, интернет не расходуется (кроме центрального), для начала было запущено 7 филиалов, дальше будет больше.

получается, что за год при старой схеме компания тратила бы на интернет 588 000р., а при текущей схеме в год будет потрачено 46 200р.

Что дальше?

А теперь, на этой всей хе… мы попробуем взлететь! я попробую развернуть IP Телефонию, чтоб минимизировать расходы на Телефонные междугородние переговоры между филиалами, связать софтАТС с аппаратными в филиалах, о чём обязательно напишу. Удачи

update1 Много вопросов возникло к термину «Крупная компания» попробую прояснить.

Крупная она в Сибири, центр имеет штат 200 сотрудников, филиалы от 20 до 60, к каждому филиалу ещё крепятся 10-20 объектов. по 5-15 человек. филиалов менее 30ти.

Компания крайне не поворотлива, основной контроль идёт от государства, оборудование, компания делает некие шаги в сторону ИТ развития 🙂

Update2

И так, после тестирования выявилось, что если надолго опустить сервер управы, то клиенты не охотно поднимают openvpn и трафик может пойти прямо в дорогой инет.

Также если принудительно рвётся ADSL канал, то опенвпн вроде и пытается стартануть заново, но что-то у него это не получается, так и ходит по кругу.

пробовал всякие опции и keepalive и ping-restart и прочее… не помогало…

Поэтому пишем небольшой скрипт, который будет проверять состояние дел.
touch /usr/bin/vpn_keepalive.sh

C содержанием.

#! /bin/sh

# Нужна ли нам отладка, рас комментировать нужное

#debug_out=/dev/null

debug_out=/dev/stdout

#NEXTHOP Это хост внутри ВПН сети

# я взял внутренний ип OpenVPN сервера

NEXTHOP=192.168.5.1

# Комманда перезапуска Опенвпн

OPEN_VPN_CMD="sudo /etc/init.d/openvpn restart"

PING=/bin/ping

logger_opts=»-t $0″

if [ «$debug_out» = «/dev/stdout» ]

then

logger_opts=»$logger_opts -s»

fi

pckts_rcvd=`$PING -c 8 -q -W 2 $NEXTHOP | grep transm | awk ‘{print $4}’`

echo «host: $NEXTHOP, pckts_rcvd: $pckts_rcvd» >$debug_out

if [ $pckts_rcvd -eq 0 ]

then

echo «Connection with $NEXTHOP lost, resetting» | logger $logopts

$OPEN_VPN_CMD > $debug_out

else

echo «Connection with $NEXTHOP up, no action» | logger $logopts

fi

Делаем его исполняемым
chmod ug+x /usr/bin/vpn_keepalive.sh

Скрипт пингует хост, и если 0 пакетов вернулось, то выполнит команду рестарта.

после чего всё гарантированно поднимается, вливаются верные маршруты, и трафик идёт через ВПН трафик

Кидаем этот скрипт в крон
crontab -e

например каждые 2 минуты.
0-59/2 * * * * /usr/bin/vpn_keepalive.sh

И всё если дебаг включен, то в логах (syslog) будет отмечено вот так.
logger: Connection with 192.168.5.1 up, no action

Удачи!

OpenVPN, объединяем домашние сети / Хабр

Данная статья посвящена объеденению нескольких домашних локальных сетей с предоставлением прозрачного общего доступа к ресурсам сетей с помощью VPN. За реализацию VPN взята openvpn. Клиенты и сервер openvpn установлены на роутерах домашних сетей, в конкретном случае роутеры семейства asus wl500, но данный мануал вполне применим и другим роутерам где есть досуп к OS и можно поставить openvpn.

Хотя подобных руководств в Интернете пруд пруди, они написаны больше для администраторов, которые имеют большой опыт общения с *nix системами, в то время как пользователями домашних роутеров являются в основном не хакеры, а обычные юзеры, может быть впервые увидевшие коммандную строку Linux на том самом роутере. Я постараюсь писать так чтобы было понятно всем.

Для тех кто не любит много букв, чтобы было понятно о чём речь под катом, привожу картинку

Итак, ещё раз формализую задачу. У нас есть несколько сетей имеющих выход в Интеренет через роутер, нам нужно предоставить доступ к ресурсам сетей друг друга через шифрованный интернет-тунель.

Что там понадобится

1. Роутеры семейства asus wl500
2. Очень желательно снабдить роутеры usb-флешками, так как в роутере очень мало флеш и оперативной памяти, подойдёт совершенно любая, ну кроме уж совсем раритеного старья, то есть меньше 9Mb. Чем не отличный повод порадовать себя новой флешкой? 🙂
3. Хотя бы один из роутеров должен выходить в Интеренет с реальным IP адресом, либо все роутеры должны быть в одном сегменте локальной сети провайдера.
4. Сети за роутерами должны иметь разный диапазон адресов
5. Немного времени и мозга

Настраивать роутеры нужно будет вместе, поэтому желательно иметь к ним доступ одновременно. Бегать из одной квартиры в другую не особо удобно, поэтому можно либо обеспечить доступ из Интернета к компьютерам за роутерами (как это сделал я), либо просто собрать роутеры в одной квартире и прицепить клиентские (ой забежал вперёд) роутеры к сервеному, тогда на месте их постоянной работы нужно будет только изменить адрес openvpn сервера.

Теория

Рассмотрим кратко как будет работать система. Сеть состоит из сервера (на рисунке это роутер Mars) и клиентов Earth и Mercury. Сервер обеспечивает функционирование виртуальной сети, шифрование трафика и маршрутизацию пакетов из одной сети в другой.

Более подробно работа сервера показана на следующем рисунке (рисунок очень условный, он только для общего понимания и не отражает компоненты программы). В клиентском режиме openvpn работает точно также, только не осуществляет маршрутизацию.

Итак у нас есть сеть с диапазоном адресов 192.168.1.1-192.168.1.255 за первым роутером (Mars) и с диапазоном 192.168.2.1-192.168.2.255 за роутером Earth. OpenVPN создаёт специальную виртуальную сетевую карту tun0, и пакеты попавшие туда рашифровываются и отправляются на сервер (на серверном компьютере локально, на клинетском через интеренет), где они расшифровывются и отправляются по нужным тунелям до адресата.

Для примера рассмотрим прохождение пакета от компьютера Phobos до компьютера Moon. Пакет от Phobos отправлется на его гейтвей по умолчанию — Mars, там в таблице маршрутизации сказано, что его надо отправить в тунель tun0, там он попадает в openvpn, который уже знает, что пакеты для сети в которую входит Moon следует отправлять в тунель до Earth. Придя на Earth пакет благополучно будет отправлен на подключенную к лоаклке Moon.

Практика

Прошиваем роутеры прошивкой от Олега и ставим ikpg. Думаю многим пользователям wl500ых эта процедура известна. Она очень подробна написана тут: http://wl500g.info/showthread.php?t=3171. Нам необходимы шаги 1-4, собственно прошивка и 7, установка допонительных пакетов.

После того как всё готово ставим необходмы там пакеты командой ipkg install <имя пакета>

• openvpn — ну это нетрудно догадаться 🙂
• vim — текстовый редактор (тот который встроен в оболочку совершенно ни для чего не годится)
• wget-ssl — понадобится для обновления записей в dns, если у сервера динамический внешний ip.

Пока пакеты устанавливаются мы немного отвлечемся от Линукса и сгенерим ключи для vpn соединения. Как это сделать под Windows (линуксоиды, думаю, уже в теме 🙂 ) уже подробно рассматривалось на хабре, повторятся тут нет смысла, следует только добавить что ca.key надо бы убрать куда нибудь подальше, например записать на ненужную флешку., а флешку положить в сундук под 33 замка, так как зная ca.crt и ca.key можно спокойно подключится к вашей домашней сети, что ясно не входит в наши планы.

Имея под рукой сертификаты их надо положить на роутер который будет сервером, так как это обычные текстовые файлы, то можно просто скопипастить их в текстовый редактор на роутере.

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

C:\>telnet 192.168.1.1

далее:

$vim /opt/etc/openvpn/keys/ca.crt

Потом нажимаем кнопку i, вставляем содержимое файла ca.crt. Тоже самое делаем с файлами dh3048.pem, mars.crt и mars.key.

После этого нужно создать файл конфигурации openvpn, входящий в комплект можно выбросить и вставить этот:

$rm /opt/etc/openvpn/openvpn.conf

$vim /opt/etc/openvpn/openvpn.conf

dev tun

tls-server

server 192.168.255.0 255.255.255.0

ifconfig 192.168.255.1 192.168.255.2

client-config-dir ccd

route 192.168.255.0 255.255.255.0 #IP Range of VPN

route 192.168.2.0 255.255.255.0 #IP Range of Earth

push «route 192.168.1.0 255.255.255.0»

#Say to clients that Mars has 192.168.1.0/24 LAN

#keys

dh /opt/etc/openvpn/keys/dh2024.pem

ca /opt/etc/openvpn/keys/ca.crt

cert /opt/etc/openvpn/keys/home2.crt

key /opt/etc/openvpn/keys/home2.key

#Do not change unless know what you are doing

client-to-client

port 1194

proto udp

user nobody

group nobody

comp-lzo

persist-tun

persist-key

verb 3

log-append /opt/var/log/openvpn/openvpn.log

status /opt/var/log/openvpn/status.log

keepalive 10 60

Создадим директорию в которой будет находится конфигурация для клиентов

$mkdir /opt/etc/openvpn/ccd/

В это директории необходимо создать файлы для тех клиентов за которыми будут находится объединяемые сети. В нашем случае это клиент Earth, создаём файл Earth

$vim /opt/etc/openvpn/ccd/Earth

Он у нас будет состять всего из одной строчки

iroute 192.168.2.0 255.255.255.0

Эта строчка говорит openvpn куда отправлять пакеты для сети 192.168.2.0/24.

Итак, до запука openvpn осталось только подправить скрипт запуска /opt/etc/init.d/S20openvpn и убрать оттуда строчку return 0.

Всё, запускаем openvpn

/opt/etc/init.d/S20openvpn

Если всё ok, то вывод netstat -ul | grep 1194 дожен выдавать сторчку
udp 0 0 *:1194 *:*


а в файле /opt/var/log/openvpn/openvpn.log Появится запись об успешном запуске сервера.

Итак, сервер работает, надо дать возможность пакетам проходить через firewall.

Для этого:
$iptables -I INPUT -p udp --dport 1194 -j ACCEPT

$iptables -I FORWARD -i br0 -o tun0 -j ACCEPT

$iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

$iptables -I INPUT -i tun0 -p tcp --dport 80 -j ACCEPT


Чтобы правила применялись каждый раз их надо добавить в файл /usr/local/sbin/post-firewall, а строчку /opt/etc/init.d/S20openvpn дописать в post-mount, чтобы сервер стартовал каждый раз при запуске роутера ($ обозначает прилашение командной строки, в файлы его вносить не надо!).

(Вы не забыли записать изменения в flashfs?)

На этом настройка сервера практически закончена. Единственное, если сервер имеет динамический ip, то надо позаботится чтобы клиенты знали какой IP сейчас имеет сервер. Для этого есть такая штука как DDNS, то есть динамический DNS. Asus имеет встроенную поддержку некоторых DDNS провайдеров, но не всех, например моего нет. Поэтому я написал простенький скрипт, который обновляет IP на DNS, если IP роутера изменился:

#!/bin/sh

IFACE="ppp0"

TMPFILE="/tmp/oldip.txt"

/sbin/ifconfig $IFACE > /dev/null 2>&1

if [ "$?" -ne "0" ]

then

logger "update_ip.sh: Interface $IFACE is down, exiting..."

exit 1

fi

new=`/sbin/ifconfig $IFACE|grep inet\ addr|sed -e 's/.*\ addr:\([0-9\.]*\).*/\1/'`

if [ -f $TMPFILE ]

then

old=`cat $TMPFILE`

else

touch $TMPFILE

old=" "

fi

if [ "$new" != "$old" ]

then

/opt/bin/wget --no-check-certificate "https://dynamicdns.park-your-domain.com/update?host=mars&domain=yourdomain&password=PASSWORD" > /dev/null 2>&1

logger "update_ip.sh: New ip $new detected"

echo $new > $TMPFILE

fi

Как поставить и настроить cron очень подробно написано тут: wl500g.info/showpost.php?p=52524&postcount=1

И так, теперь переходим к клиенту. Установка клиента абсолютно такая же как и сервера, единственное надо перегнать ключи клиента (нам понадобятся ca.crt, Earth.crt, Earth.key) и нменого другом конфиге. Не забудьте подправить скрипт запуска.

Конфиг клиента, в поле remote нужно вставить адрес сервера

client

dev tun

proto udp

remote mars.yourdomain 1194

resolv-retry infinite

nobind

persist-key

persist-tun

ca /opt/etc/openvpn/keys/ca.crt

cert /opt/etc/openvpn/keys/Earth.crt

key /opt/etc/openvpn/keys/Eartth.key

ns-cert-type server

comp-lzo

verb 3

log-append /opt/var/log/openvpn/openvpn.log

status /opt/var/log/openvpn/status.log


Аналогично применяем правила iptables:
$iptables -I FORWARD -i br0 -o tun0 -j ACCEPT

$iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

$iptables -I INPUT -i tun0 -p tcp --dport 80 -j ACCEPT


Запускаем openvpn на клиенте, он соединеятся с сервером и радуемся жизни. Можно смотреть фильмы, фотографии и рубится в игры как по локалке.

Единственное что я не смог сделать это синхронизировать внутренние DNS сервера, поэтому обращатся к компьютерам между сетями надо по их ip.

Ну, надеюсь это будет кому-то полезно, я что-то устал писать этот эпический мануал.

В качестве домашнего задания подключите компьютер Mercury, чтобы он имел доступ к локальным ресурам из любого места, например по gprs или публичного wifi.

В качестве advanced домашнего задания, отнимите у mercury возможность подсоединятся к сети, изменив только конфигурацию Mars.

(С) Иван Лисенков 2009

Переход с OpenVPN на WireGuard для объединения сетей в одну сеть L2 / Хабр

Хотел бы поделиться опытом объединения сетей в трех географически удаленных квартирах, в каждой из которых в качестве шлюза используются роутеры с OpenWRT, в одну общую сеть. При выборе способа объединения сетей между L3 с маршрутизацией подсетей и L2 с бриджингом, когда все узлы сети будут находиться в одной подсети, было отдано предпочтение второму способу, более сложному в настройке, но дающим бОльшие возможности, так как в создаваемой сети планировалось прозрачное использование технологий Wake-on-Lan и DLNA.

Часть 1: Предыстория

В качестве протокола для реализации этой задачи изначально был выбран OpenVPN, так как, во-первых, он может создавать устройство tap, которое без проблем добавляется в мост, а во-вторых, OpenVPN поддерживает работу по протоколу TCP, что было также немаловажно, ведь ни в одной из квартир не имелось выделенного IP-адреса, а использовать STUN мне не удалось, так как мой провайдер почему-то блокирует входящие подключения по протоколу UDP из своих сетей, в то время как протокол TCP позволял мне пробросить порт VPN-сервера на арендуемый VPS при помощи SSH. Да, такой подход дает большую нагрузку, так как данные шифруются дважды, но вводить VPS в свою частную сеть я не захотел, так как оставался риск получения третьими лицами контроля над ним, следовательно, иметь в домашней сети такое устройство являлось крайне нежелательным и было решено заплатить за безопасность большим оверхедом.

Для проброса порта на роутере, на котором планировалось развернуть сервер, была использована программа sshtunnel. Описывать тонкости ее конфигурации не буду — это делается достаточно легко, просто отмечу, что ее задачей был проброс TCP-порта 1194 с роутера на VPS. Далее был настроен сервер OpenVPN на устройстве tap0, которое заводилось в мост br-lan. Проверив подключение к только что созданному серверу с ноутбука — стало понятно, что идея с пробросом порта себя оправдала и мой ноутбук стал членом сети роутера, хотя физически в ней не находился.

Дело оставалось за малым: нужно было распределить IP-адреса в разных квартирах так, чтобы они не конфликтовали и настроить маршрутизаторы в качестве OpenVPN-клиентов.

Были выбраны такие IP-адреса маршрутизаторов и диапазоны DHCP-серверов:

• 192.168.10.1 с диапазоном 192.168.10.2 — 192.168.10.80 для сервера
• 192.168.10.100 с диапазоном 192.168.10.101 — 192.168.10.149 для маршрутизатора в квартире №2
• 192.168.10.150 с диапазоном 192.168.10.151 — 192.168.10.199 для маршрутизатора в квартире №3

Также было необходимо назначить именно эти адреса для маршрутизаторов-клиентов OpenVPN-сервера, путем добавления в его конфигурацию строчки:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

и добавлением следующих строк в файл /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

где flat1_id и flat2_id — это имена устройств, указываемые при создании сертификатов для подключения к OpenVPN

Далее на роутерах были настроены OpenVPN-клиенты, устройства tap0 на обоих были занесены в мост br-lan. На этом этапе казалось, что все в порядке, так как все три сети видят друг друга и работают как единое целое. Однако, выяснилась не очень приятная деталь: иногда устройства могли получить IP-адрес не от своего маршрутизатора, со всеми вытекающими последствиями. По какой-то причине, маршрутизатор в какой-то из квартир не успевал ответить вовремя на DHCPDISCOVER и устройство получало не свой адрес. Я понял, что мне нужно отфильтровать такие запросы в tap0 на каждом из маршрутизаторов, но, как выяснилось, iptables не может работать с устройством, если оно является частью моста и мне на помощь должен прийти ebtables. К моему сожалению, в моих прошивках его не оказалось и пришлось пересобирать образы для каждого устройства. Сделав это и добавив такие строки в /etc/rc.local каждого маршрутизатора проблема была решена:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

Такая конфигурация просуществовала на протяжении трех лет.

Часть 2: Знакомство с WireGuard

В последнее время в Интернете все чаще стали говорить о WireGuard, восхищаясь простотой его конфигурации, высокой скоростью передачи, низким пингом при сопоставимой безопасности. Поиск дополнительной информации о нем давал понять, что ни работа в качестве члена моста, ни работа по протоколу TCP им не поддерживается, что наводило меня на мысли о том, что альтернатив OpenVPN для меня по-прежнему нет. Так я откладывал знакомство с WireGuard.

Несколько дней назад по ресурсам, так или иначе связанным с IT, пролетела новость о том, что WireGuard наконец будет включен в ядро Linux, начиная с версии 5.6. Новостные статьи, как всегда, хвалили WireGuard. Я вновь погрузился в поиски путей замены старого доброго OpenVPN. На этот раз я напоролся на эту статью. В ней говорилось о создании Ethernet-туннеля поверх L3 при помощи GRE. Эта статья вселила в меня надежду. Оставалось неясно что делать с протоколом UDP. Поиск приводил меня к статьям об использовании socat в связке с SSH-туннелем, для проброса UDP-порта, однако, в них отмечалось, что такой подход работает только в режиме одного соединения, то есть работа нескольких VPN-клиентов оказалась бы невозможной. Мне пришла идея поднять VPN-сервер на VPS, а для клиентов настроить GRE, но, как оказалось, GRE не поддерживает шифрование, что приведет к тому, что в случае получения доступа к серверу третьими лицами, в их руках оказывается весь трафик между моими сетями, что меня не устраивало в принципе.

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

VPN первого уровня:
VPS является сервером с внутренним адресом 192.168.30.1
МС является клиентом VPS с внутренним адресом 192.168.30.2
МК2 является клиентом VPS с внутренним адресом 192.168.30.3
МК3 является клиентом VPS с внутренним адресом 192.168.30.4

VPN второго уровня:
МС является сервером с внешним адресом 192.168.30.2 и внутренним 192.168.31.1
МК2 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.2
МК3 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.3

* МС — маршрутизатор-сервер в квартире 1, МК2 — маршрутизатор в квартире 2, МК3 — маршрутизатор в квартире 3

* Конфигурации устройств опубликованы в спойлере в конце статьи.

И так, пинги между узлами сети 192.168.31.0/24 ходят, пора перейти к настройке GRE-туннеля. Перед этим, дабы не терять доступ к маршрутизаторам, стоит настроить SSH-туннели для проброса 22 порта на VPS, таким образом, что, например, на 10022-ом порту VPS будет доступен маршрутизатор из квартиры 2, а на 11122-порту VPS будет доступен маршрутизатор из квартиры 3. Настройку проброса лучше всего выполнить все тем-же sshtunnel, так как он восстановит туннель в случае его падения.

Туннель настроен, можно подключаться к SSH через проброшенный порт:

ssh root@МОЙ_VPS -p 10022

Далее следует отключить OpenVPN:

/etc/init.d/openvpn stop

Теперь настроим GRE-туннель на маршрутизаторе из квартиры 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

И добавим созданный интерфейс в мост:

brctl addif br-lan grelan0

Аналогичную процедуру выполним на маршрутизаторе-сервере:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

И, также, добавим созданный интерфейс в мост:

brctl addif br-lan grelan0

начиная с этого момента пинги начинают успешно ходить в новую сеть и я, с удовлетворением отправляюсь пить кофе. Затем, чтобы оценить, как работает сеть на другом конце провода, я пытаюсь подключиться по SSH к одному из компьютеров в квартире 2, но ssh-клиент «зависает», не предлагая ввести пароль. Пробую подключиться к этому компьютеру по telnet на 22 порт и вижу строку, из которой можно понять, что соединение устанавливается, SSH-сервер отвечает, просто по какой-то причине не предлагает мне войти.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Пытаюсь подключиться к нему же по VNC и вижу черный экран. Я убеждаю себя, что дело в удаленном компьютере, ведь к маршрутизатору из этой квартиры я спокойно могу подключиться по внутреннему адресу. Однако, я решаю подключиться к SSH этого компьютера через маршрутизатор и с удивлением обнаруживаю, что подключение удается, а удаленный компьютер работает вполне штатно, но при этом также не может подключиться к моему компьютеру.

Я вывожу устройство grelan0 из моста и запускаю OpenVPN на маршрутизаторе в квартире 2 и убеждаюсь, что сеть вновь работает как положено и соединения не обрываются. Поиском натыкаюсь на форумы, где люди жалуются на такие же проблемы, где им советуют поднять MTU. Однако, повысить MTU для VPN первого уровня (wg0) мне не удалось: при MTU выше 1420, который выставляется автоматически, начинаются обрывы, но при этом, VPN второго уровня wg1, работающий поверх wg0, корректно работал с MTU 1600. Этого достаточно для установки MTU в 1500 для устройства gretap, для того чтобы этот интерфейс имел то же значение MTU, что и мост br-lan, в который планировалось добавить gretap. Насколько я понял, мост выставляет MTU равное меньшему из доступных значений на всех устройствах.

Провел аналогичную настройку и на маршрутизаторе из квартиры 3, с той лишь разницей, что на маршрутизаторе сервере добавился второй интерфейс gretap с именем grelan1, который также был добавлен в мост br-lan.

Все работает. Теперь можно поместить сборку gretap в автозагрузку. Для этого:

Поместил эти строки в /etc/rc.local на маршрутизаторе в квартире 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

Добавил это в /etc/rc.local на маршрутизаторе в квартире 3:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

И на маршрутизаторе-сервере:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 1500
ip link set grelan1 up
brctl addif br-lan grelan1

После перезагрузки клиентских роутеров я обнаружил, что они по какой-то причине не подключаются к серверу. Подключившись к их SSH (благо, я предварительно настроил sshtunnel для этого) было обнаружено, что WireGuard зачем-то создает маршрут для endpoint, при этом неверный. Так, для 192.168.30.2 в таблице маршрутов был указан маршрут через интерфейс pppoe-wan, то есть через интернет, хотя маршрут до него должен был быть направлен через интерфейс wg0. После удаления этого маршрута соединение восстановилось. Найти где-то инструкций о том, как заставить WireGuard не создавать этих маршрутов мне не удалось. Более того, я даже не понял, особенность это OpenWRT, либо самого WireGuard. Не став долго разбираться с этой проблемой, я просто добавил на оба роутера в скрипт, зацикленный по таймеру, строку удалявшую этот маршрут:

route del 192.168.30.2

Подводя итоги

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

При использовании OpenVPN:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

При использовании WireGuard:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

На него в большей степени влияет высокий пинг до VPS, который составляет примерно 61.5 мс

Однако, скорость увеличилась значительно. Так, в квартире с маршрутизатором-сервером я имею скорость подключения к Интернету 30 мбит/сек, а в остальных квартирах по 5 мбит/сек. При этом, во время использования OpenVPN мне не удавалось достичь скорости передачи данных между сетями больше 3,8 мбит/сек по показаниями iperf, в то время как WireGuard «прокачал» ее до тех же 5 мбит/сек.

Конфигурация WireGuard на VPS[Interface]

Address = 192.168.30.1/24

ListenPort = 51820

PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer]

PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>

AllowedIPs = 192.168.30.2/32

[Peer]

PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>

AllowedIPs = 192.168.30.3/32

[Peer]

PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>

AllowedIPs = 192.168.30.4/32

Конфигурация WireGuard на МС (добавляется в /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '1600'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

Конфигурация WireGuard на МК2 (добавляется в /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '1600'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

Конфигурация WireGuard на МК3 (добавляется в /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '1600'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

В описанных конфигурациях для VPN второго уровня я указываю клиентам WireGuard порт 51821. По идее это не нужно, так как клиент установит соединение с любого свободного непривилегированного порта, но я сделал так, чтобы можно было запретить все входящие соединения на интерфейсах wg0 всех маршрутизаторов, кроме входящих UDP-соединений на порт 51821.

Надеюсь, что статья будет кому-то полезна.

P.S. Также, хочу поделиться своим скриптом, который шлет мне PUSH-уведомление на телефон в приложение WirePusher, когда в моей сети появляется новое устройство. Вот ссылка на скрипт: github.com/r0ck3r/device_discover.

UPDATE: Конфигурация OpenVPN-сервера и клиентов

OpenVPN-сервер

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN-клиент

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

Для генерации сертификатов использовал easy-rsa

Соединение компьютер-компьютер через интернет с динамическими IP / Хабр

Очень часто мы слышим о том, что установить соединение компьютер-компьютер через интернет с динамическими IP – нереально без внешнего сервера.
А также думал, до определенного времени. Потом у меня закрались подозрения… А после мне стало известно очень многое и тайное.

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

Как? Об этом я и хочу рассказать.

Все совпадения случайны, цифры изначально выдуманы.

На самом деле, без внешнего сервера это действительно нереально. Но есть «хаки» и «моды», которые нам помогут.

Я буду сильно разжевывать. Некоторые мои объяснения могут не сойтись с реальностью, но это делается для того, чтобы было понятно как и что работает, поскольку на практике данных знаний хватит.

Теория

NAT – то, что дает каждому из нас иметь возможность подключаться к интернету, кто сидит с IPv4. Если раздать каждому компьютеру IPv4 адрес, то их не хватит.

NAT позволяет нам скрывать определенные сервисы только для сети… И именно из-за него мы не можем, в большинстве, достучаться до компьютера из интернета.

Представьте, что вы подключаетесь к серверу FTP в пассивном режиме.

Ваш внешний адрес: 43.12.102.14

Ваш внутренний адрес: 192.168.0.2

Адрес вашего NAT: 192.168.0.1

Вы создаете TCP соединение с вашего IP 192.168.0.2, создаете запрос на адрес с 21 портом.

Далее запрос попадает на ваш NAT, который создает в своей небольшой таблице соответствие: TCP-соединение внутренний IP 192.168.0.2, порт 21.

Внешне он создает также порт, например, 54321 со своим адресом.

И переадресует ваш запрос на FTP сервер на 21 порт.

Сервер FTP, получая запрос, видит, что запрос установлен с IP 43.12.102.14 и порта 54321.

Теперь, на время соединения, этот порт является переадресатором на ваш компьютер на порт 21 для TCP соединения.

Как только вы закроете соединение, порт провесит от 3-10 секунд и удалится из таблицы NAT.

Большинство UDP соединений и TCP соединений в программах создаются через данные хаки, постоянно поддерживая подключение.

Практика

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

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

IP и порты этих пользователей в NAT будут выглядеть, например, так:

1 пользователь: 43.12.102.14:56742

2 пользователь: 43.12.102.15:61782

После этого сервер ICQ сообщает каждому клиенту их внешний IP-адрес и внешний порт.

Пользователь 1 делает соединение на этот внешний IP:Port (43.12.102.15:61782) и попадает на внутренний порт 5191.

Пользователь 2 соглашается на соединение с IP:Port пользователя 1 (43.12.102.15:61782), который переадресуется с NAT на пользователя 1 с портом 5191. Далее происходит пересылка файлов и соединение закрывается. Через некоторое время NAT, видя, что внешние и внутренние порты уже не используются и соединение закрыто, удаляет этот порт для того, чтобы использовать для других соединений.

На картинке это будет выглядеть так:

Как реализовать?

Конечно, не каждый из нас на начале своей карьеры имел внешний сервер, который будет говорить каждому пользователю его внешний IP-адрес и порт.

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

В большинстве, они созданы для UDP протокола, который используется в тех же торрентах. Однако существуют и STUNT сервера для реализации TCP протокола.

Создавайте, творите, все в ваших руках.

P.S.: Не все NAT способны обеспечить такое соединение, однако, большинство закрытых NAT, следящих за IP соединений, не используются в предоставлении услуг провайдеров.

UDP: в данном контексте, динамическими IP, называются IP адреса, которые не являются внешними, а выдаются вышестоящим NAT.

Объединение двух локальных сетей при помощи интернет-центров Keenetic, используя Сервер PPTP (для версий NDMS 2.11 и более ранних)

RUS

• RUS

• ENG

• TUR

• UKR

• Модели

• Почему Keenetic

• Поддержка

• Отправить запрос
• Войти

• Отправить запрос
• Войти

• Модели

• Поддержка

• Где купить

• О компании

• Юридическая информация

1. Keenetic

2. Архив документации

3. NDMS v2

Как создать локальную сеть между двумя компьютерами

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

Соединяем компьютеры в сеть

Как становится ясно из вступления, объединить два ПК в «локалку» можно двумя способами – напрямую, с помощью кабеля, и через роутер. Оба эти варианта имеют свои плюсы и минусы. Ниже мы разберем их подробнее и научимся настраивать систему на обмен данными и выход в интернет.

Вариант 1: Прямое соединение

При таком соединении один из компьютеров выступает в роли шлюза для подключения интернета. Это значит, что на нем должны быть как минимум два сетевых порта. Один для глобальной сети, а второй для локальной. Впрочем, если интернет не требуется или он «приходит» без использования проводов, например, через 3G модем, то можно обойтись и одним LAN-портом.

Схема подключения проста: кабель включается в соответствующие разъемы на материнской плате или сетевой карте обеих машин.

Обратите внимание, что для наших целей нужен кабель (патч-корд), который предназначен для прямого соединения компьютеров. Называется такая разновидность «кроссовером». Впрочем, современное оборудование способно самостоятельно определять пары для приема и передачи данных, поэтому обычный патч-корд, скорее всего, также будет нормально работать. Если возникнут неполадки, то кабель придется переделать или найти в магазине нужный, что бывает весьма непросто.

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

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

Настройка

После подключения кабеля требуется настроить сеть на обоих ПК. Для начала необходимо присвоить каждой машине в нашей «локалке» уникальное имя. Это нужно для того, чтобы программное обеспечение могло находить компьютеры.

1. Жмем ПКМ по значку «Компьютер» на рабочем столе и идем в свойства системы.

2. Здесь переходим по ссылке «Изменить параметры».

3. В открывшемся окне нажимаем кнопку «Изменить».

4. Далее вводим имя машины. Имейте в виду, что оно в обязательном порядке должно быть прописано латинскими символами. Рабочую группу можно не трогать, но если измените ее название, то это же необходимо проделать и на втором ПК. После ввода нажимаем ОК. Для вступления изменений в силу нужно перезагрузить машину.

Теперь нужно настроить общий доступ к ресурсам в локальной сети, так как по умолчанию он ограничен. Данные действия также нужно выполнить на всех машинах.

1. Кликаем ПКМ по значку подключения в области уведомлений и открываем «Параметры сети и интернет».

2. Переходим к настройке параметров общего доступа.

3. Для частной сети (см. скриншот) разрешаем обнаружение, включаем общий доступ к файлам и принтерам, и позволяем Windows управлять подключениями.

4. Для гостевой сети также включаем обнаружение и общий доступ.

5. Для всех сетей отключаем общий доступ, настраиваем шифрование 128-битными ключами и отключаем доступ по паролю.

6. Сохраняем настройки.

В Windows 7 и 8 данный блок параметров можно найти так:

1. Правым кликом по значку сети открываем контекстное меню и выбираем пункт, ведущий в «Центр управления сетями».

2. Далее переходим к настройке дополнительных параметров и производим указанные выше действия.

Подробнее: Как настроить локальную сеть на Windows 7

Дальше требуется выполнить настройку адресов для обоих компьютеров.

1. На первом ПК (том, который подключается к интернету) после перехода к параметрам (см. выше) нажимаем на пункт меню «Настройка параметров адаптера».

2. Здесь выбираем «Подключение по локальной сети», кликаем по нему ПКМ и идем в свойства.

3. В списке компонентов находим протокол IPv4 и, в свою очередь, переходим к его свойствам.

4. Переключаемся на ручной ввод и в поле «IP-адрес» вводим такие цифры:

   192.168.0.1

   В поле «Маска подсети» автоматически подставятся нужные значения. Здесь ничего менять не нужно. На этом настройка закончена. Жмем ОК.

5. На втором компьютере в свойствах протокола необходимо прописать такой IP-адрес:

   192.168.0.2

   Маску оставляем по умолчанию, а вот в полях для адресов шлюза и DNS-сервера указываем айпи первого ПК и нажимаем ОК.

   В «семерке» и «восьмерке» следует перейти в «Центр управления сетями» из области уведомлений, а затем кликнуть по ссылке «Изменение параметров адаптера». Дальнейшие манипуляции производятся по тому же сценарию.

Заключительная процедура – разрешение совместного доступа к интернету.

1. Находим среди сетевых подключений (на шлюзовом компьютере) то, через которое мы подключаемся к интернету. Кликаем по нему правой кнопкой мыши и открываем свойства.

2. На вкладке «Доступ» ставим все галки, разрешающие использование и управление подключением всем пользователям «локалки» и жмем ОК.

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

Вариант 2: Соединение через роутер

Для такого подключения нам понадобится, собственно, сам роутер, набор кабелей и, разумеется, соответствующие порты на компьютерах. Тип кабелей для соединения машин с роутером можно назвать «прямым», как противоположность кроссовому, то есть жилы в таком проводе соединены «как есть», напрямую (см. выше). Такие провода с уже смонтированными коннекторами можно без проблем найти в розничной продаже.

Маршрутизатор имеет несколько портов подключения. Один для получения интернета и несколько для подключения компьютеров. Различить их просто: LAN-разъемы (для машин) группируются по цвету и пронумерованы, а порт для входящего сигнала стоит особняком и имеет соответствующее название, обычно написанное на корпусе. Схема подключения в этом случае также довольно несложная – кабель от провайдера или модема подсоединяется в разъем «Internet» или, в некоторых моделях, «Link» или «ADSL», а компьютеры в порты, подписанные как «LAN» или «Ethernet».

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

Читайте также: Как подключить ноутбук к ноутбуку через WiFi

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

Читайте также: Настройка роутера TP-LINK TL-WR702N

Для настройки нужных параметров в Windows при таком подключении никаких действий предпринимать не требуется – все установки производятся в автоматическом режиме. Нужно только проверить способ получения айпи-адресов. В свойствах протокола IPv4 подключения по локальной сети необходимо поставить переключатель в соответствующее положение. Как добраться до настроек параметров, читайте выше.

Разумеется, также нужно не забыть установить разрешения общего доступа и сетевого обнаружения, как и для кабельного соединения.

Далее мы поговорим о том, как обеспечить работу с общими ресурсами – папками и файлами – в нашей «локалке».

Настройка доступа к ресурсам

Общий доступ подразумевает возможность использования каких-либо данных всеми пользователями локальной сети. Для того чтобы «расшарить» имеющуюся на диске папку, необходимо проделать следующее:

1. Кликаем правой кнопкой мыши по папке и выбираем пункт контекстного меню с названием «Предоставить доступ к», а в подменю – «Отдельные люди».

2. Далее выбираем в выпадающем списке всех пользователей и жмем «Добавить».

3. Выставляем разрешения на выполнение операций внутри папки. Рекомендуется выставить значение «Чтение» — это позволит участникам сети просматривать и копировать файлы, но не разрешит их изменять.

4. Сохраняем настройки кнопкой «Поделиться».

Доступ к «расшаренным» директориям осуществляется из области переходов «Проводника» или из папки «Компьютер».

В Windows 7 и 8 названия пунктов меню немного отличаются, но принцип действия такой же.

Подробнее: Включение общего доступа к папкам на компьютере с Windows 7

Заключение

Организация локальной сети между двумя компьютерами – процедура не сложная, но требующая некоторого внимания со стороны пользователя. Оба способа, приведенные в этой статье, имеют свои особенности. Наиболее простым, с точки зрения минимизации настроек, является вариант с роутером. Если же такого устройства в наличии нет, то вполне можно обойтись и кабельным соединением.

Мы рады, что смогли помочь Вам в решении проблемы.

Опишите, что у вас не получилось.
Наши специалисты постараются ответить максимально быстро.

Помогла ли вам эта статья?

ДА НЕТ

VPN-мост в локальную сеть / Хабр

Прочитал топик habrahabr.ru/blogs/linux/67209 и решил выложить сюда свою статью, которая была до этого видна только в закрытой корпоративной Wiki.

Обычно, при создании VPN, используется подключение типа точка-точка к некоторому серверу, либо установка ethernet-туннеля с некоторым сервером, при котором туннелю назначается определённая подсеть. Сервер VPN при этом выполняет функции маршрутизации и фильтрования трафика для доступа к локальной сети через VPN.

Данная статья рассматривает другой подход к созданию виртуальной сети, при котором удалённые системы включаются в уже существующую локальную подсеть, а сервер VPN выполняет роль Ethernet-шлюза. При использовании такого подхода мы всё ещё имеем возможность фильтровать трафик на основании способа подключения (например, использовать для локальной сети и для удалённых пользователей разные фильтры), но исключается необходимость настройки маршрутизации, а удалённые машины включаются прямо в локальную сеть, видят ресурсы, даже способны использовать широковещательные посылки вообще без дополнительной настройки. Через такой VPN у них отображаются все компьютеры локальной сети Windows, все доступные XDMCP-серверы при XDMCP broadcast и т. д.

Структура сети и настройка сервера

Предположим, что имеется офис с локальной сетью, используется IP-подсеть 192.168.168.0/24. В эту локальную сеть мы включим домашних пользователей, то есть они будут иметь адрес из этой же самой подсети. Необходимо убедиться, что у них «дома» не встречается данная подсеть, и что никакие системы в локальной сети не имеют адресов из диапазона, который мы выделим для удалённых пользователей.

Поддержка моста в ядре

Для работы такой техники нам нужны некоторые ядерные драйвера. Это универсальный драйвер виртуальных сетевых интерфейсов tun, и драйвер ethernet-моста bridge. Можно включить их в ядро, или собрать модулями:

    -> Networking
      -> Networking support (NET [=y])
        -> Networking options
          <*> 802.1d Ethenet Bridging (BRIDGE [=y])
    -> Device Drivers
      -> Network device support (NETDEVICES [=y])
        <*> Universal TUN/TAP device driver support (TUN [=y])

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

Программное обеспечение

Для сервера потребуется OpenVPN и утилиты для обслуживания моста. В Gentoo они собираются следующим образом:

  emerge net-misc/bridge-utils net-misc/openvpn

При использовании >=sys-apps/baselayout-1.12.6 этого достаточно, для более старых версий потребуются специальные утилиты для обслуживания tun/tap-устройств:

  emerge sys-apps/usermode-utilities

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

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

  config_eth3=( "192.168.168.254/24" )

Поскольку он будет участвовать в мосте, ему не нужно назначать адреса. Также, в мосте участвует вновь создаваемый виртуальный интерфейс tap0, которому тоже не назначается никакого адреса. Адрес, который использовался eth3, назначается теперь мосту br0:

  config_eth3=( "null" )
  
  tuntap_tap0="tap"
  config_tap0=( "null" )
  
  depend_br0() {
    need net.tap0 net.eth3
  }
  
  # указываем существующие интерфейсы, объединяя их в мост
  bridge_br0="eth3 tap0"
  # либо, можно динамически подключать туда вновь появляющиеся интерфейсы
  #bridge_add_eth3="br0"
  
  config_br0=( "192.168.168.254/24" )

Также нужно создать настроечные скрипты для указанных интерфейсов:

  cd /etc/init.d
  ln -s net.lo net.eth3
  ln -s net.lo net.tap0
  ln -s net.lo net.br0

Достаточно автоматически загружать только интерфейс br0. depend_br0() автоматически поднимет все остальные необходимые ему для работы:

  rc-update add net.br0 default
  /etc/init.d/net.eth3 stop
  /etc/init.d/net.br0 start

Создание ключей OpenVPN

Мы будем авторизовывать клиентов посредством RSA-ключей OpenSSL. Для упрощения процесса, для нас приготовили несколько init-скриптов:

  cd /usr/share/openvpn/easy-rsa/

Там есть файл vars, в который мы занесём общие значения:

  nano vars

Внизу этого файла мы заполняем наши переменные:

  export KEY_COUNTRY="RU"
  export KEY_PROVINCE="Voronezh oblast"
  export KEY_CITY="Boguchar"
  export KEY_ORG="OrganiZationnAme"
  export KEY_EMAIL="[email protected]"

Загружаем переменные из этого файла и строим CA (Certificate Authority):

  source ./vars
  ./clean-all
  ./build-ca

Ключ сервера

Для генерации ключа сервера с именем office, используем следующую команду:

  ./build-key-server office

На вопрос «Common Name» нужно ответить именем сервера (в нашем случае, office). На два вопроса в конце «Sign the certificate? [y/n]» и «1 out of 1 certificate requests certified, commit? [y/n]» отвечаем «y».

При необходимости, можно будет создать дополнительные ключи серверов. Например, это могут быть резервные серверы доступа для повышения надёжности системы. Они создаются той же командой, перед ней нужно выполнить source ./vars.

Параметры Диффи-Хеллмана

Здесь ничего дополнительно делать не придётся, но придётся подождать.

  ./build-dh

Этот файл нужен только на сервере.

Ключи клиентов

Каждому клиенту необходимо выдать свой ключ. Для клиента с именем client ключ создаётся командой

  ./build-key client

На вопрос о «Common Name» отвечаем именем клиента (в данном случае, client). На два вопроса в конце отвечаем согласием.

Сгенерированные ключи и сертификаты передаём клиентам через защищённый канал. При необходимости, можно создавать ещё ключи той же командой. Перед её запуском, необходимо загрузить окружение — выполнить source ./vars.

Настройка и запуск сервиса OpenVPN

Для запуска следует использовать следующую конфигурацию сервера (файл /etc/openvpn/openvpn.conf):

  # Этот порт рекомендован IANA для OpenVPN. Можно перевесить на другой порт, но секретность не повысится - он всё равно первым делом признаётся, что он - OpenPVN.
  port 1194
  
  # OpenVPN может использовать tcp и udp в качестве транспортного протокола, udp - предпочтительнее
  proto udp
  
  # Виртуальный интерфейс, который мы включили в мост, непременно типа tap (через tun нельзя эмулировать Ethernet)
  dev tap0
  
  # Корневой самоподписанный сертификат CA
  ca /etc/openvpn/keys/ca.crt
  
  # Сертификат и секретный ключ сервера. crt должен иметь режимы 644, key - 600
  cert /etc/openvpn/keys/office.crt
  key /etc/openvpn/keys/office.key
  
  # Файл с параметрами Диффи-Хеллмана. Если у вас другая длина ключей, исправьте имя :)
  dh /etc/openvpn/keys/dh2024.pem
  
  # Раздавать удалённым клиентам адреса в этой подсети, из этого диапазона (обратите внимание - подсеть задаётся ВСЯ, как в конфиге сетевухи, а диапазон - часть подсети)
  server-bridge 192.168.168.254 255.255.255.0 192.168.168.128 192.168.168.159
  
  # Разрешить взаимодействие клиентов друг с другом (иначе только с сервером и сегментом сети "за мостом")
  client-to-client
  
  # Это позволит выдать клиенту тот же самый адрес, какой выдавали раньше, если не занят
  ifconfig-pool-persist /etc/openvpn/ipp.txt
  
  # Если вы не хотите через DHCP передавать также и адрес DNS-сервера, можно убрать следующую строку
  push "dhcp-option DNS 192.168.168.254"
  
  # Компрессия
  comp-lzo
  # Максимальное число клиентов - имеет смысл сделать меньше или равно числу адресов в диапазоне server-bridge
  max-clients 32

  # Подробности относительно этих ключей - в документации OpenVPN
  keepalive 10 120

  # Не переинициализировать tun и не перечитывать ключ при переподключениях; если работаем не как root, а как nobody, то нам это и не позволят, поэтому либо все эти опции, либо ни одну из них
  user nobody
  group nobody
  persist-key
  persist-tun

  # Каждую минуту OpenVPN сбрасывает сюда текущее состояние (список клиентов, маршруты и т. д.)
  status /tmp/openvpn-status.log
  
  # Очень шумный лог, нормальная работа - verb 2
  verb 6
  log-append  /var/log/openvpn.log

Ключ office.key должен иметь режим 600 (доступ только владельцу). Файлы office.crt и dh2024.pem имеют режим 644.

Настройка фильтрования

Поскольку мы используем мост, есть несколько особенностей организации фильтрования пакетов. Например, не все проходящие пакеты могут вообще оказаться IPv4. Для настройки работы моста в ядре существует несколько параметров:

Переменные этой группы сохраняются в файлах директории /proc/sys/net/bridge/. Их можно также настраивать в /etc/sysctl.conf, тогда они все получат префикс «net.brigde.»

• bridge-nf-call-arptables
  
  Логическая переменная bridge-nf-call-arptables управляет передачей трафика ARP в цепочку FORWARD пакетного фильтра arptables. Установленное по умолчанию значение 1 разрешает передачу пакетов фильтрам, 0 – запрещает.
• bridge-nf-call-iptables
  
  Логическая переменная bridge-nf-call-iptables управляет передачей проходящего через мост трафика IPv4 в цепочки iptables. Используемое по умолчанию значение 1 разрешает передачу пакетов для фильтрации, 0 – запрещает.
• bridge-nf-call-ip6tables
  
  Действие аналогично предыдущему, только оно настраивает передачу трафика IPv6 для фильтрования в цепочки ip6tables.
• bridge-nf-filter-vlan-tagged
  
  Логическая переменная bridge-nf-filter-vlan-tagged определяет возможность передачи трафика IP/ARP с тегами VLAN программам фильтрации пакетов (arptables/iptables). Значение 1 (установлено по умолчанию) разрешает передачу пакетов с тегами VLAN программам фильтрации, 0 – запрещает.

Для фильтрования пакетов, проходящих через мост, используется соответствие physdev, которое различает, с какого и на какой порт моста следует пакет. Включаем его в ядре:

-> Networking
  -> Networking support (NET [=y])
    -> Networking options
      -> Network packet filtering framework (Netfilter) (NETFILTER [=y])
        -> Core Netfilter Configuration
          -> Netfilter Xtables support (required for ip_tables) (NETFILTER_XTABLES [=y])
            -> "physdev" match support (NETFILTER_XT_MATCH_PHYSDEV [=y])

Кроме этого, конфигурация ядра должна разрешать передачу пакетов на фильтрацию iptables, т.е. bridge-nf-call-iptables=1 и bridge-nf-call-ip6tables=1 (если вы используете IPv6).

После можете использовать, например, такие правила для фильтрования:

  iptables -A FORWARD -p tcp --dport 22 -m physdev --physdev-in eth2 --physdev-out eth0 -j ACCEPT

Поподробнее про настройку фильтрации между портами поста можно почитать в статье Building bridges with Linux

Если вы не хотите делать никаких различий между пользователями LAN и пользователями bridged VPN, вы можете просто выключить эти параметры в ядре (они включены по умолчанию):

  echo "net.bridge.bridge-nf-call-iptables = 0" >> /etc/sysctl.conf
  echo "net.bridge.bridge-nf-call-ip6tables = 0" >> /etc/sysctl.conf

Клиенты

На клиенте необходимо создать конфигурационный файл OpenVPN следующего содержания:

  client
  nobind
  dev tap
  proto udp
  # Куда подключаться. Можно указать несколько опций remote - будет использоваться первый доступный сервер. Если для server.example.net имеется несколько A-записей, между ними выбор производится случайно.
  remote server.example.net 1194
  # Никогда не сдаваться, пытаться подключаться бесконечно.
  resolv-retry infinite
  # Либо все опции вместе, либо ни одна из них
  persist-key
  persist-tun
  user nobody
  group nogroup
  comp-lzo
  ns-cert-type server
  ca ca.crt
  cert client.crt
  key client.key

Если сервер подключен через несколько провайдеров, можно повысить устойчивость сети к отказам. Для этого клиенту нужно прописать несколько опций remote, по одной на сервер, в порядке «сначала предпочтительные».

Имена файлов, указанные в параметрах ca, cert и key — это файлы, переданные через защищённый канал. Права доступа к файлу key должны быть установлены в 600.

Linux

Необходим universal tun/tap driver в ядре, либо модулем, но загруженный.

Gentoo

При установке net-misc/openvpn создаётся скрипт /etc/init.d/openvpn. Этот скрипт запускает openvpn с конфигурационным файлом /etc/openvpn/openvpn.conf. Мы, однако, можем поддерживать несколько конфигураций OpenVPN одновременно, если сделаем симлинки вида /etc/init.d/openvpn.network-name -> /etc/init.d/openvpn — каждый такой скрипт запускает OpenVPN с конфигурационным файлом /etc/openvpn/network-name.conf.

Соответственно, помещаем туда вышеприведённый конфиг, создаём симлинк и кладём скрипты в поддиректорию в /etc/openvpn/. В конфиге прописываем полный путь к ключу и сертификатам. Следите, чтобы имена файлов в конфиге не пересекались, во избежание неприятных эффектов!

Запуск и останов сети производятся через управление сервисом /etc/openvpn.network-name.

Windows

Конфигурационный файл помещается в директорию «C:\Program Files\OpenVPN\config\» с именем вроде «office.ovpn», туда же помещаются остальные файлы — ключи и сертификаты. Если мы их помещаем в поддиректорию (например, хотим использовать несколько виртуальных сетей и все они предоставили файлы с одинаковым именем ca.crt), указываем полные пути к файлам.

Для запуска сетей можно либо запустить сервис OpenVPN (тогда будут запущены все конфигурации *.ovpn, найденные в config\), либо по отдельности — щёлкаем по файлу .ovpn правой кнопкой и выбираем «Запустить OpenVPN с этой конфигурацией».

Возможные проблемы

Проверить доступность сервера, если он запущен на TCP, можно обычным telnetом.

Windows

Нет свободного виртуального адаптера TAP

Wed Dec 31 10:43:51 2008 TCP connection established with 88.83.201.253:1194 
Wed Dec 31 10:43:51 2008 TCPv4_CLIENT link local: [undef] 
Wed Dec 31 10:43:51 2008 TCPv4_CLIENT link remote: 88.83.201.253:1194 
Wed Dec 31 10:44:51 2008 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 
Wed Dec 31 10:44:51 2008 TLS Error: TLS handshake failed 
Wed Dec 31 10:44:51 2008 Fatal TLS error (check_tls_errors_co), restarting 
Wed Dec 31 10:44:51 2008 SIGUSR1[soft,tls-error] received, process restarting 
Wed Dec 31 10:44:56 2008 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port. 
Wed Dec 31 10:44:56 2008 Re-using SSL/TLS context 
Wed Dec 31 10:44:56 2008 LZO compression initialized 
Wed Dec 31 10:44:56 2008 Attempting to establish TCP connection with 88.83.201.253:1194 
Wed Dec 31 10:44:56 2008 TCP connection established with 88.83.201.253:1194 
Wed Dec 31 10:44:56 2008 TCPv4_CLIENT link local: [undef] 
Wed Dec 31 10:44:56 2008 TCPv4_CLIENT link remote: 88.83.201.253:1194 
Wed Dec 31 10:45:11 2008 [office] Peer Connection Initiated with 88.83.201.253:1194 
Wed Dec 31 10:45:13 2008 All TAP-Win32 adapters on this system are currently in use. 
Wed Dec 31 10:45:13 2008 Exiting 
Press any key to continue...

По логу OpenVPN видно, что клиент успешно присоединился к серверу, авторизовался, но не смог привязать виртуальную сеть к виртуальному адаптеру. Скорее всего, какие-то другие процессы уже задествовали все имеющиеся в системе адаптеры TAP-Win32. Это мог быть и сам OpenVPN, повисший и не отдавший адаптер.

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

Ссылки

При написании данной статьи, использовались следующие источники:

1. Gentoo Linux Wiki — HOWTO OpenVPN Server for Ethenet Bridging with Server Certificates (Есть копия этой страницы, по адресу: http://www.gentoo-wiki.info/HOWTO_OpenVPN_Server_for_Ethernet_Bridging_with_Server_Certificates. Спасибо hexes за ссылку!)
2. Gentoo Linux Wiki — HOWTO OpenVPN Linux Server Windows Client
3. OpenVPN Documentation — HOWTO
4. Энциклопедия сетевых протоколов — параметры sysctl для стека IP
5. Building bridges with Linux

P.S. Некоторые источники почили. Ссылки я убирать не буду, но стоит иметь ввиду.

Политика соединения для Интернет-сетей

.

Разница между сетью и Интернетом

• Домашняя страница

• Тестирование

  • • Назад
    • Гибкое тестирование
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • JTL3000
    • J27 Тестирование
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр контроля качества (ALM)
    • RPA 9000 Test4 Управление
    • TestLink

• SAP

  • • Назад
    • ABAP 9 0004
    • APO
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • QM4
    • 000 HRM
    • Заработная плата
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • Учебники SAP
  • Apache
    • AngularJS
    • ASP.Net
    • C
    • C #
    • C ++
    • CodeIgniter
    • СУБД
    • JavaScript
    • Назад
    • Java
    • JSP
    • Kotlin
    • Linux
    • Linux
    • Kotlin
    • Linux

    js

    • Perl
    • Назад
    • PHP
    • PL / SQL
    • PostgreSQL
    • Python
    • ReactJS
    • Ruby & Rails
    • Scala
    • SQL

    000

    • SQL

    000

    0003 SQL

    000

    0003 SQL

    000

    • UML
    • VB.Net
    • VBScript
    • Веб-службы
    • WPF

  • Обязательно учите!

    • • Назад
      • Бухгалтерский учет
      • Алгоритмы
      • Android
      • Блокчейн
      • Business Analyst
      • Создание веб-сайта
      • CCNA
      • Облачные вычисления
      • 00030003 COBOL 9000 Compiler
        9000 Встроенные системы
        • 00030002 9000 Compiler 9000
        • Ethical Hacking
        • Учебники по Excel
        • Программирование на Go
        • IoT
        • ITIL
        • Jenkins
        • MIS
        • Сеть
        • Операционная система
        • Назад
        • Управление проектами Обзоры
        • Salesforce
        • SEO
        • Разработка программного обеспечения
        • VB A

    • Big Data

      • • Назад
        • AWS
        • BigData
        • Cassandra
        • Cognos
        • Хранилище данных

        0003

        • HBOps

        0003

        • HBOps

        0003

        • MicroStrategy

    .

    типов сетей связи | Studytonight

    Коммуникационные сети могут быть следующих 5 типов:

    1. Локальная сеть (LAN)
    2. Городская сеть (MAN)
    3. Глобальная сеть (WAN)
    4. Беспроводной
    5. Межсетевое соединение (Интернет)

    ---

    Локальная сеть (LAN)

    Он также называется LAN и предназначен для небольших физических помещений, таких как офис, группа зданий или завод.ЛВС широко используются, поскольку их легко проектировать и устранять неполадки. Персональные компьютеры и рабочие станции связаны друг с другом через локальные сети. Мы можем использовать различные типы топологий через LAN, это звезда, кольцо, шина, дерево и т. Д.

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

    Сети LAN

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

    ---

    Характеристики LAN

    • LAN — это частные сети, на которые не действуют тарифы или другие нормативные требования.

    Локальные сети

    • работают на относительно высокой скорости по сравнению с типичной глобальной сетью.
    • Существуют различные типы методов управления доступом к среде в локальной сети, наиболее заметными из которых являются Ethernet, Token Ring.
    • Он соединяет компьютеры в одном здании, блоке или кампусе, то есть они работают в ограниченной географической зоне.

    ---

    Приложения LAN

    • Один из компьютеров в сети может стать сервером, обслуживающим все остальные компьютеры, называемые клиентами. Программное обеспечение может храниться на сервере и использоваться остальными клиентами.
    • Локальное соединение всех рабочих станций в здании, чтобы они могли общаться друг с другом локально без доступа в Интернет.
    • Совместное использование общих ресурсов, таких как принтеры и т. Д., Являются одними из распространенных приложений LAN.

    ---

    Преимущества LAN

    • Совместное использование ресурсов: Ресурсы компьютера, такие как принтеры, модемы, приводы DVD-ROM и жесткие диски, могут использоваться совместно с помощью локальных сетей.Это снижает стоимость и покупку оборудования.
    • Совместное использование программных приложений: Дешевле использовать одно и то же программное обеспечение по сети, чем покупать отдельное лицензионное программное обеспечение для каждого клиента в сети.
    • Простая и дешевая связь: Данные и сообщения могут легко передаваться через подключенные к сети компьютеры.
    • Централизованные данные: Данные всех пользователей сети могут быть сохранены на жестком диске серверного компьютера. Это поможет пользователям использовать любую рабочую станцию ​​в сети для доступа к своим данным.Потому что данные не хранятся на рабочих станциях локально.
    • Безопасность данных: Поскольку данные хранятся на сервере централизованно, будет легко управлять данными только в одном месте, а также данные будут более безопасными.
    • Общий доступ в Интернет: Локальная сеть обеспечивает возможность совместного использования одного подключения к Интернету среди всех пользователей локальной сети. В Net Cafes единая система совместного использования интернет-соединения снижает расходы на интернет.

    ---

    Недостатки LAN

    • Высокая стоимость установки: Хотя локальная сеть со временем снизит затраты благодаря общим ресурсам компьютера, но первоначальные затраты на установку локальных сетей высоки.
    • Нарушение конфиденциальности: Администратор локальной сети имеет право проверять файлы личных данных каждого пользователя локальной сети. Кроме того, он может проверить историю Интернета и историю использования компьютера пользователем локальной сети.
    • Безопасность данных Threa

    .

    компьютерная сеть | Определение и типы

    Компьютерная сеть , два или более компьютера, которые связаны друг с другом с целью передачи данных в электронном виде. Помимо физического соединения компьютера и устройств связи, сетевая система выполняет важную функцию по созданию единой архитектуры, которая позволяет различным типам оборудования передавать информацию практически беспрепятственно. Две популярные архитектуры — это ISO Open Systems Interconnection (OSI) и системная сетевая архитектура IBM (SNA).

    Подробнее по этой теме

    компьютер: сеть

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

    Два основных типа сетей — это локальные сети (LAN) и глобальные сети (WAN). ЛВС соединяют компьютеры и периферийные устройства в ограниченном физическом пространстве, таком как офис, лаборатория или университетский городок, с помощью каналов (провода, кабели Ethernet, оптоволокно, Wi-Fi), которые быстро передают данные.Типичная локальная сеть состоит из двух или более персональных компьютеров, принтеров и дисковых запоминающих устройств большой емкости, называемых файловыми серверами, которые позволяют каждому компьютеру в сети получать доступ к общему набору файлов. Программное обеспечение операционной системы LAN, которое интерпретирует ввод и инструктирует сетевые устройства, позволяет пользователям общаться друг с другом; разделяйте принтеры и складское оборудование; и одновременно получить доступ к центрально расположенным процессорам, данным или программам (наборам команд). Пользователи LAN могут также получить доступ к другим LAN или подключиться к WAN.Локальные сети с аналогичной архитектурой связаны «мостами», которые действуют как точки передачи. ЛВС с разной архитектурой связаны «шлюзами», которые преобразуют данные по мере их передачи между системами.

    WAN соединяют компьютеры и небольшие сети с более крупными сетями в больших географических областях, включая разные континенты. Они могут связывать компьютеры с помощью кабелей, оптических волокон или спутников, но их пользователи обычно получают доступ к сетям через модем (устройство, которое позволяет компьютерам общаться по телефонным линиям).Самая большая глобальная сеть — это Интернет, совокупность сетей и шлюзов, связывающих миллиарды пользователей компьютеров на всех континентах.

    .

    No related posts.