Full mesh vpn что это

Территориально-распределенные VPN-сети

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

Аренда каналов у провайдера: Распространенный и надежный вариант. Провайдер предоставляет в аренду выделенные физические или логические каналы связи. Такие каналы часто называют «точка-точка»

Достоинства:

1. Простота подключения и использования – обслуживание оборудования и каналов полностью возлагается на провайдера;
2. Гарантированная ширина канала – скорость передачи данных всегда соответствует заявленной провайдером;

1. Безопасность и контроль – компания не может контролировать оборудование на стороне провайдера.

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

Достоинства:

1. Гибкость – возможность развертывания каналов, отвечающих всем необходимым требованиям;
2. Безопасность и контроль – полный контроль канала, поскольку он принадлежит компании;

1. Развертывание – построение таких частных каналов трудоемкое и затратное решение. Прокладка километров оптики по столбам может встать в круглую сумму. Даже если не брать в расчет получение разрешений всех гос. инстанций;
2. Обслуживание – обслуживание канала полностью возлагается на компанию, поэтому в штате должны быть высококвалифицированные специалисты для обеспечения его работоспособности;
3. Низкая отказоустойчивость – внешние оптические линии связи часто подвергаются неумышленным повреждениям (строительная техника, коммунальные службы, итд). Время обнаружения и исправления оптической линии связи может занять несколько недель.
4. Ограничено одной локацией – прокладывать внешние оптические линии связи актуально только в случае, если объекты расположены в пределах нескольких десятков километров. Тянуть связь в другой город на сотни и тысячи километров не представляется возможным из соображений здравого смысла.

Построение защищенного канала через Интернет (VPN): Такое решение является относительно бюджетным и гибким. Для объединения удаленных офисов достаточно подключения к Интернету и сетевого оборудования с возможностью создания VPN соединений

Достоинства:

1. Низкая стоимость – компания платит только за доступ в Интернет;
2. Масштабируемость – для подключения нового офиса необходимо наличие Интернета и маршрутизатора;

1. Пропускная способность канала – скорость передачи данных может варьироваться (нет гарантированной полосы пропускания);

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

Уникальные преимущества территориально распределенных VPN-сетей

Защита передаваемого трафика: передавать трафик по VPN туннелю безопасно при использовании криптостойких протоколов шифрования (3DES, AES). Помимо шифрования обеспечивается проверка целостности данных и подлинности отправителя, исключая возможность подмены информации и подключения злоумышленника.

Надежность соединения: ведущие производители оборудования совершенствуют технологии VPN подключений, обеспечивая автоматическое восстановление VPN туннелей в случае кратковременного выхода из строя соединения к публичной сети.
Мобильность и удобство подключения: к локальной сети компании можно подключиться из любой точки мира и практически с любого современного устройства (смартфон, планшетный компьютер, ноутбук), при этом соединение будет защищено. Большинство производителей мультимедийных устройств добавили поддержку VPN в свою продукцию.

Резервирование и балансировка нагрузки: если вы используете двух провайдеров при подключении к сети Интернет (для балансировки/отказоустойчивости), то возможна балансировка трафика VPN туннелей между провайдерами. В случае выхода из строя одного из провайдеров, туннель будет использовать резервное соединение.

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

VPN-сети в бизнесе

Единая сеть

Объединение территориально распределенных локальных сетей компании в единую сеть (подключение филиалов к главному офису) значительно упрощает взаимодействие и обмен данными внутри компании, снижая затраты на обслуживание. Любые корпоративные системы требуют единого сетевого пространства для работы сотрудников. Это может быть IP телефония, системы бухгалтерского и финансового учета, CRM, видеоконференцсвязь, и т.д.

Мобильный доступ

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

Объединение сетей разных компаний

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

Удаленное управление IT-инфраструктурой

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

Качество обслуживания

Трафик видеоконференций, IP-телефонии и некоторых других приложений требует гарантированную ширину канала. Благодаря использованию QoS в VPN туннелях например можно объединить IP-телефонию локальной сети компании и удаленного офиса.

Сферы применения распределенных VPN-сетей и корпоративных сетей передачи данных (КСПД)

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

Решения для малого бизнеса. Зачастую требования для такого решения – это возможность подключения удаленных пользователей (до 10) к внутренней сети и/или объединение сетей нескольких офисов. Такие решения являются простыми и быстрыми в развертывании. Для такой сети рекомендуется наличие резервного канала со скоростью ниже либо такой же как у основного. Резервный канал является пассивным и используется только в случае отключения основного (VPN туннель автоматически строится по резервному каналу). Резервирование пограничного оборудования для таких решений применяется редко и зачастую необоснованно.

Передаваемый по туннелю трафик – трафик внутренних приложений (почта, веб, документы), голосовой трафик.

Потребность в резервировании канала: средняя

Потребность в резервировании оборудования: низкая

Решения для среднего бизнеса. Наряду с подключением удаленных сотрудников (до 100), сетевая инфраструктура должна обеспечивать подключение нескольких удаленных офисов. Для таких решений резервирование Интернет канала обязательно, при этом пропускная способность резервного канала должна быть сопоставима со скоростью основного канала. Во многих случаях резервный канал активный (осуществляется балансировка нагрузки между каналами). Рекомендуется резервировать оборудование критически важных узлов сети (прим. пограничный роутер центрального офиса). Топология VPN сети – звезда или partial mesh.

Передаваемый по туннелю трафик – трафик внутренних приложений (почта, веб, документы), голосовой трафик, трафик видеоконференций.

Потребность в резервировании канала: высокая

Потребность в резервировании оборудования: средняя

Решения для крупного бизнеса, распределённая сеть филиалов. Такие сети достаточно больших масштабов сложны в развертывании и поддержке. Топология такой сети с точки зрения организации VPN туннелей может быть: звезда, partial mesh, full mesh (на схеме приведен вариант full mesh). Резервирование канала обязательно (можно больше 2х провайдеров), как и резервирование оборудования критических важных узлов сети. Все, либо несколько каналов активны. В сетях такого уровня нередко применяются выделенные физические каналы (leased lines) или VPN предоставляемый провайдерами. В такой сети необходимо предусмотреть максимальную надежность и отказоустойчивость с целью минимизирования простоя бизнеса. Оборудование для таких сетей – флагманская линейка энтерпрайз класса или провайдерское оборудование.

Передаваемый по туннелю трафик – трафик внутренних приложений (почта, веб, документы), голосовой трафик, трафик видеоконференций.

Потребность в резервировании канала: высокая

Потребность в резервировании оборудования: высокая

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

Медицинские учреждения. Для медицинских учреждений стоит острый вопрос надежности и высокой отказоустойчивости каналов связи и оборудования. Во всех филиалах территориально распределённой сети используются резервируемое каналообразующее оборудование и несколько провайдеров.

Решения для ритейла (сети магазинов). Сети магазинов отличаются массовостью локаций (это могут быть тысячи магазинов), и относительно не высоким трафиком до главного офиса (ЦОД). Резервирование оборудования в магазинах чаще всего не целесообразно. Достаточно зарезервировать подключение к провайдеру (в формате «второй провайдер на подхвате»). Однако требования к оборудованию, которое стоит в ЦОД (главном офисе) высокие. Так как эта точка терминирует на себе тысячи VPN туннелей. Необходим постоянный мониторинг каналов, системы отчетности, соблюдение политик безопасности, и т.д.

Внедрение распределенных VPN-сетей и корпоративных сетей передачи данных (КСПД)

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

Примеры некоторых проектов по внедрению КСПД и VPN, реализованных компанией ЛанКей

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

Производитель оборудования: Cisco
Решение: Объединение по защищенному туннелю корпоративной сети и облачных серверов для предоставления сотрудникам различных сервисов (почта, документооборот, телефония). Помимо этого решение позволяло подключаться к корпоративной сети и использовать облачные сервисы удаленным сотрудникам.

Производитель оборудования:Juniper
Решение: осуществлено подключение к сети интернет и построение VPN тунелей в офисах, находящихся в Москве и Женеве.

• Сетевые решения
  • Беспроводные сети (Wi-Fi)
  • ЛВС
  • VPN
  • AVAYA
  • Cisco
  • Ericsson-LG
  • Panasonic
  • Агат-РТ
  • Nec
  • Ericsson
  • Audiocodes
  • Как выбирать АТС
  • AVAYA Unified Communication
  • Call-центры на основе АТС Panasonic
  • Создание единой корпоративной телефонной сети
  • DECT-системы, микросотовые сети
  • ВКС ВидеоМост
  • AVAYA Radvision
  • Polycom
  • Jabra

  Understanding mesh VPNs

  A mesh network is a type of networking topology in which different nodes dynamically connect to each other in order to improve the overall efficiency of data transmission. Similarly, mesh VPNs use a peer-to-peer architecture to offer greater resiliency, scalability, and performance than conventional VPNs. This article explores the features, benefits, and use cases of mesh VPNs.

  Written by James Konik

  On This Page

  What is a Mesh VPN Network?

  Mesh VPNs use a peer-to-peer (P2P) model to create a secure shared environment for their users. They consist of nodes that send traffic between themselves rather than through a central server.

  This is in contrast to the traditional hub-and-spoke model, which sends everything through a main server, creating a bottleneck. As nodes are added, scaling issues can limit performance. In addition, users that are distant from the VPN gateway will experience sluggishness due to latency, even when the server is not busy. It also leaves the VPN gateway exposed, and authenticated users often have access to the whole network, which creates risk.

  As there is no central mesh server, a mesh VPN network frees you from these issues, increasing security and scaling efficiently. You can add nodes without overloading the network, and connections use the shortest path available, which minimizes latency.

  In this article, you’ll learn more about how a mesh VPN works, along with best practices for getting the most out of it. You’ll also learn what options you have if you’re thinking of using a mesh VPN for your own network.

  Mesh VPN networking explained

  In a mesh VPN, nodes do most of the work that would otherwise be done by a central managing server. In a regular VPN, all the data goes through this central server, whereas in a mesh VPN, nodes send data to each other, spreading the burden throughout the system. In this section, we’ll cover some of the basics of how a mesh VPN works.

  How nodes communicate in a mesh network

  The nodes within a mesh VPN maintain lists of other nodes, which they connect to as needed. The pattern of connections between them forms a mesh, which frequently changes — nodes can connect and disconnect to each other at any time, affecting the network structure. The fundamental architecture, however, remains the same.

  Nodes may drop, and in some systems the best routes through the system are dynamic, but the network is always a set of interconnected peers. Once connected, nodes may get information from other nodes, keeping each other updated as things change.

  As mentioned, mesh VPNs rely on a P2P model. Some, like the open source project tinc, use the mesh to handle everything. However, this is unusual as most mesh VPNs aren’t fully P2P: They use a central server of some kind for coordination. The coordination aspect is often called the control plane, whereas the secured traffic between nodes is often called the data plane.

  Mesh VPN design

  The nodes in the VPN can vary in nature. Wireless routers, phones, desktop computers, or servers can all act as nodes.

  Although the structure of mesh VPNs lends itself to better scaling than a hub-and-spoke configuration, mesh VPNs can still have issues with scaling. For example, individual mesh nodes may have less capacity than one large hub would. Each connection to another node has some overhead, and mesh VPNs that relay traffic between nodes (versus only making direct connections) can lead to network traffic and congestion on the relay nodes.

  Mesh VPNs can also be challenging to manage. Figuring out the shortest routes around a network with relays is a complex problem, and the algorithm used by the mesh VPN is a key factor in the network’s overall performance. Mesh VPNs that do not use relays have the problem of making direct connections between devices that may be behind NAT (which impedes direct connections as a side effect) and firewalls (which exist primarily to prevent unauthorized connections).

  Mesh VPN features

  Mesh VPNs have several distinctive features that differentiate them from other types of VPNs.

  The core feature of a mesh VPN is its distributed nature. Avoiding the use of a central server (aside from adding nodes) reduces latency and makes the network far more scalable. Other mesh VPN features are consequences of this architecture.

  Shared internet access

  Members of a mesh VPN can share each other’s internet access. There may be one or several points that are connected to the internet, and requests are sent there over the mesh. Internet traffic is then routed back to the node that requested it.

  VPN connections to a mesh network may not give you all the features you expect. Mesh VPNs are typically used to provide secured communication between devices owned by an individual or organization, rather than for anonymizing internet traffic. In fact, all devices that can communicate within the mesh typically know your internal ID. It’s like having a local network that isn’t a physical local network.

  If the network uses a common resource to provide nodes with internet access, sites you connect to will see a common IP address and may be able to track it. So while information you exchange between nodes isn’t visible to the outside world, your internet connection or location aren’t necessarily masked as in a privacy VPN marketed to individuals for anonymizing their internet browsing.

  Self-discovery and healing

  Mesh VPN algorithms allow nodes to continually decide how to best pipe traffic through the system. These algorithms mean that the network can be self-discovering and self-configuring, and precise routes from node to node are determined dynamically.

  The best mesh VPNs are also self-healing: The nodes are constantly figuring out the best route to send traffic, and if one of them goes down, they simply pick another route. That means you’re less vulnerable to outages and network issues.

  Note that depending on a particular mesh VPN’s architecture, your control layer could be a possible point of failure, though existing nodes should be able to carry on without it. If the control layer fails, however, new nodes won’t be able to connect until it’s restored.

  Better value

  Another benefit of the mesh architecture is that the nodes do much of the work of managing the network, meaning less central processing and bandwidth is required.

  With nodes moving data around, you don’t need to spend as much on your infrastructure. For VPN providers and customers, that means those services can provide better value. Mesh networks work out to be cheaper.

  For example, Tailscale is free for individual use despite including most of the features you’d want in a paid VPN. Besides secure connections and HTTPS, you get things like single sign-on and multifactor authentication (MFA), which builds on top of WireGuard®.

  Mesh VPN use cases

  Here are a few use cases where mesh VPNs shine.

  Direct peer-to-peer connections

  In mesh VPNs, nodes connect directly to their peers. You can therefore create a remote network exclusively for a certain group of users, such as employees of your company. A mesh VPN also allows you to connect employees in different departments or offices and give them a common set of internal services.

  Faster access to common resources

  Mesh VPNs are ideal for companies that want to connect multiple sites in different locations. People are connected via the VPN, and from a user’s perspective, everyone is working on the same network. The mesh VPN achieves this without needing an intermediary to manage all its traffic.

  Common resources can be shared without having to pipe all the traffic through a central location. This makes things faster and prevents bottlenecks. Traffic is free to take the fastest available route from A to B.

  Experimenting with new services

  Rolling out new features on a network can be risky. A new service is untested and vulnerable to attack. You may also be vulnerable if you’re making small changes to your system on a regular basis as you may not have had the time to put everything through a security audit.

  The private nature of a VPN means you can test services without exposing them to the wider world, which minimizes the impact of mistakes. No one outside your community has access to the system. This means hackers are less likely to exploit weaknesses, and errors are unlikely to be spotted.

  You can even create a local network just for your developers and use it for experimentation before adding new services to the main VPN.

  Private networks are completely under your control and free from outside interference. The consequences of mistakes are limited, making them ideal for trying out new features.

  Mesh network basics and configuration

  In this section, we’ll suggest how to get started setting up and initializing your mesh network, explain how node connections work, and provide some key considerations around your firewalls and control plane.

  Despite their advantages, mesh VPNs can be complicated. Each node needs to manage its own routing independently, and information on peers needs to be exchanged.

  The choices you make when setting up a network will define its effectiveness. This is even more important as you scale up, because more nodes mean more complexity and longer routes to calculate.

  Getting started with mesh network configuration

  There are many existing solutions to help you get started. One simple solution is Tailscale, which handles mesh network configuration for you. It connects the nodes securely and creates a central control plane to coordinate everything. This saves you time: You can quickly start using the network without developer effort in setting it up. You won’t have to go back to fix errors, either.

  Tailscale’s client is open source, so you can check out how everything works and change whatever you need to. The Tailscale coordination server is a closed source SaaS product but is free for personal use.

  Initializing a Tailscale mesh VPN

  When first connecting to the mesh VPN, the node contacts the coordination server and registers its public key. It also tells the server where it is — in other words, its IP address, which port number to use, and which relay server it can be reached through.

  The node then downloads information about the other nodes in its domain. That way it knows the addresses and public keys of its peers. With this information, the node is now free to connect to other nodes without further reference to the central server.

  The coordination server keeps all the required information on the various nodes, such as their IP addresses, for sharing with other nodes.

  Node connections

  Nodes use key pairs to connect securely. Each node generates a public and private key pair for itself. The public key is associated with its identity.

  In public-key cryptography, the public key is shared and used to encrypt data that requires the private key to access. The private key always stays with the central node and is never shared.

  This keeps everything secure as the public keys are useless without the private key. Both are needed to connect to other nodes securely.

  Firewall management

  Managing firewalls in a mesh network is a huge challenge, not least because some nodes may have limited control over the firewalls they need to go through. Opening firewall ports isn’t always possible for nodes connecting via networks where you do not have administrator access, including cafe or hotel Wi-Fi. Better options are needed.

  Tailscale can also help in this regard because it uses advanced NAT traversal techniques. These essentially allow connections to avoid many of the restrictions a firewall creates. This means you can work over connections even when you can’t change those connections’ firewall settings.

  Control plane features

  Besides handling initial coordination, control planes let you set company-wide rules. You can decide things like which devices and users are allowed to access which resources, then upload those security policies in the control plane for all the nodes to download and follow. This way, you can make sure all the nodes on the network are enforcing the same security policies.

  Mesh network security

  Now let’s look at some broader security considerations when setting up a mesh VPN.

  Security is critical for a mesh VPN. You need to make sure the data you share is not readable by third parties. Tailscale, for example, uses the open source WireGuard protocol to create encrypted tunnels between computers on the network, making it unreadable to eavesdroppers.

  There are several other things you can do to keep your network safe.

  Use a zero trust approach

  The default policy for good security is zero trust. That means you give minimum possible permissions to every node. Security checks are carried out every time a transaction is made. Specifically, when permissions need to be granted, an authorization check is carried out. Permissions are granted temporarily and revoked as soon as the transaction is finished.

  MFA is a complementary practice to a zero trust approach. If credentials are lost or stolen, MFA provides another layer of protection to prevent unauthorized users from gaining access your network.

  MFA typically involves sending a code to a device, but it can also use biometric data or physical tokens. By requiring the use of a specific device or other means of authentication, you prevent hackers from breaking into your system simply by stealing a password.

  Implement role-based access control

  When granting remote access to different resources, you need a system to decide who can do what. Developing policies to assign users permissions makes your network more secure.

  Role-based access control, or RBAC, lets you assign permissions to nodes on the network depending on the associated user’s role. If permission is granted to the role, then all individuals who have that role get access automatically, saving considerable admin time. Managers can then decide what role to give team members when they’re first granted access to the network. Of course, team members’ roles can change if required.

  The control plane can handle distribution of permissions during initialization. Using RBAC means you don’t have to assign users permissions individually and makes it easier to ensure everyone has the permissions they should have. RBAC also allows you to make changes that affect large numbers of users together. In a large organization, this makes it much easier to implement a business-wide decision regarding who can access any particular resource.

  Conversely, if permissions are granted on a case-by-case basis, it’s easy to forget when someone should lose access to a resource. Over time, your system becomes less secure as users have permission to access resources long after they’ve changed roles. In a worst-case scenario, users can be left with permissions after they leave your company. That can be a vehicle for malicious attacks.

  Change security settings as needed

  Company security policies can also be stored on the central control plane. This is accessed by nodes when they enter the network. For example, some networks allow full access between nodes, while others are more restricted.

  In a mesh VPN, having these policies stored in a central location makes them easy to change. Admins can and should update security policies to reflect the evolution of the network. Updates to software, emerging threats, or changing user profiles can all lead to making changes that better reflect your needs.

  Secure key rotation

  Nodes need to know each other’s IP address and encryption keys to exchange data. You need to exchange keys between them securely. Tailscale handles this by recording in the coordination server which encryption keys are in use and supplying those details to all of the nodes.

  The architecture of this control plane for initializing nodes is the same as in the hub-and-spoke configuration, but the impact on performance is minimal because it’s only used briefly when nodes connect to their peers. After that, the traffic passing between the nodes is routed through the mesh.

  Conclusion

  A mesh VPN spreads the work around, letting your nodes handle network traffic and avoiding the need for an overburdened central server to manage everything. It’s performant, scalable, and secure. It also lets geographically distributed companies work together using a common network.

  Deploying a mesh VPN effectively can be difficult, however. There are firewall issues to worry about, configuration challenges, and complex algorithms to pick from. Choosing a solution that can handle these issues lets you get started quickly without having to set up everything yourself. It means you get security and performance right from the start.

  If implementing a mesh VPN seems overwhelming, have a look at Tailscale. It’s simple and fast, and it requires no configuration. You don’t even need a credit card to get started. With it, your devs will have you up and running in no time.

  Get started with Tailscale today.

  Список Full-Mesh VPN решений

  Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

  Со своими серверами (преимущественно для игр):

  Tunngle
  Basic и Premium. Только Windows.

  VPN для игр, аналог Hamachi. Zero-config через сервер программы. Чат с возможностью передачи файлов, голосовой чат на основе Ventrillo и Mumble. Имеется мини-файрволл.
  В бесплатной версии можно создавать комнату до 32 человек, которая удаляется
  после 3 дней неактивности. Нельзя настравать мини-файрволл, он блокирует порты
  1-1024 и все протоколы, кроме tcp, udp и icmp. Пробивает NAT.
  Premium дает возможность создавать комнаты до 255 человек, скрывать комнаты из
  каталога, изменять ник, использовать QoS, настраивать мини-файрволл,
  использовать ник вместо ip (dns).

  Social VPN
  Open Source. Windows и Linux. C#.

  Zero-config с XMPP в качестве бекенда, интеграция с Gtalk. Пробивает NAT, соединяется напрямую, или использует свои сервера, если это невозможно. Есть DNS.

  Remobo
  Free. Windows, Linux и MacOS.

  Аналог Hamachi, zero-config через сервер программы. Имеется встроенный чат. Возможно использовать другие компьютеры в качестве прокси. Пробивает NAT.
  Есть PRO-версия, которая отличается наличием демона с CLI.

  Без своих серверов:

  NeoRouter
  Free. Windows, Linux, MacOS, FreeBSD, Android.

  Есть portable-версия и веб-клиент. Поддержка IPv6, пробивает NAT.

  Zero-config через Gtalk и Gmail. VPN, VNC, Шаринг, синхронизация и бекап файлов.
  Генерация превью к картинкам, создание каталогов, стриминг аудио и видео (используется web-интерфейс).
  Пробивает NAT, сервер-нода отсутствует.

  P2PVPN
  Open Source. Windows и Linux. Java.

  VPN и чат между пирами. Используется BitTorrent (а конкретно трекер OpenBitTorrent) для поиска пиров вашей сети. NAT не пробивает, требует открытого порта хотя бы у одного участника сети, сервер-нода отсутствует.
  Проект немного заглох, последяя версия вышла в 2010.

  Wippien
  Open Source. Windows и Linux.

  Использует XMPP в качестве бекенда, интеграция с Gtalk. Пробивает NAT.

  Для серверного использования:

  tinc
  Open Source. Windows, Linux, *BSD, MacOS, Solaris, iPhone.

  Старый проект, легкое конфигурирование, сервер-ноды нет. Поддержка IPv6, пробивает NAT.

  PeerVPN
  Open Source, Linux и FreeBSD. Неофициальные порты для MacOS и Windows.

  Поддержка IPv6, пробивает NAT.

  tinc-boot — full-mesh сеть без боли

  

  Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью «пробивки» NAT — это возможно?

  • да, с болью, если вы используете tinc.
  • да, легко, если вы используете tinc + tinc-boot

  Ссылка на пропуск вводной части

  Описание tinc

  К сожалению, информации о Tinc VPN на Хабре публиковалось немного, но пару релевантных статей все же можно найти:

  • Наш рецепт отказоустойчивого VPN-сервера на базе tinc, OpenVPN, Linux от компании Флант
  • Список Full-Mesh VPN решений от уважаемого ValdikSS

  Из англоязычных статей можно выделить:

  • How To Install Tinc and Set Up a Basic VPN on Ubuntu 14.04 от компании Digital Ocean
  • How to Set up tinc, a Peer-to-Peer VPN от компании Linode

  Первоисточником лучше считать оригинальную документацию Tinc man

  Итак (вольная перепечатка с официального сайта), Tinc VPN это сервис (демон tincd ) обеспечивающий функционирование приватной сети за счет тунелирования и шифрования трафика между узлами. Исходный код открыт и доступен под лицензией GPL2. Подобно классическим (OpenVPN) решением, созданная виртуальная сеть доступна на уровне IP (OSI 3), а значит, в общем случае, внесение изменений в приложения не потребуется.

  • шифрование, аутентификация и сжатие трафика;
  • полностью автоматическое full-mesh решение, включающее в себя построение связей к узлам сети в режиме «все-со-всеми» или, если это неприменимо, пересылку сообщений между промежуточными хостами;
  • «пробивка» NAT;
  • возможность соединять изолированные сети на уровне ethernet (виртуальный switch);
  • поддержка множества ОС: Linux, FreeBSD, OS X, Solaris, Windows и т.д.

  Существует две ветки развития tinc: 1.0.x (почти во всех репозиториях) и 1.1 (вечная бета). В статье везде используется версия 1.0.x.

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

  

  Рассмотрим ситуацию тремя серверами (Китай, РФ, Сингапур) и тремя клиентами (РФ, Китай и Филиппины):

  • сервера имеют публичный адрес, клиенты за NAT’ом;
  • РКН во время очередного бана вероятных прокси Телеграмма заблокировал всех хостеров кроме «дружественного» Китая;
  • сетевая граница Китай РФ является нестабильной и может падать (из-за РКН и/или из-за Китайского цензора);
  • соединения до Сингапура условно стабильные (личный опыт);
  • Манила (Филиппины) ни для кого угрозой не является, а потому разрешена для всех (по причине удаленности от всех и всего).

  На примере обмена трафиком между Шанхаем и Москвой рассмотрим сценарии работы Tinc (примерно):

  1. Штатная ситуация: Москва russia-srv china-srv Шанхай
  2. РКН закрыл соединение до Китая: Москва russia-srv Манила Сингапур Шанхай
  3. (после 2) при отказе сервера в Сингапуре, трафик перекидывается на сервер в Китае и наоборот.

  При возможности, Tinc пытается организовать прямое соединение между двумя узлами за NAT за счет «пробивки».

  Краткая вводная в конфигурирование tinc

  Tinc позиционируется как легкий в настройки сервис. Однако, что-то пошло не так — для создания нового узла минимально необходимо:

  • описать настройку узла (тип, имя) ( tinc.conf );
  • описать файл конфигурации (обслуживаемые подсети, публичные адреса) ( hosts/ );
  • создать ключ;
  • создать скрипт, задающий адрес узла и сопутствующие параметры ( tinc-up );
  • желательно создать скрипт, очищающий созданные параметры после остановки ( tinc-down ).

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

  Т.е: для второго узла

  

  

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

  Надо отдать должное разработчикам Tinc — для включения в сеть достаточно обменяться ключами
  только с одним из узлов (bootnode). После запуска сервиса и подключения к участнику, tinc получит топологию
  сети и сможет работать со всеми абонентами.

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

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

  Причины создания tinc-boot

  Если обобщить описанные выше проблемы, и сформулировать их как задачи, то мы получим:

  1. необходима возможность создания нового узла с минимальными усилиями;
     • потенциально, необходимо сделать так, чтобы можно было дать среднему специалисту (эникею) одну небольшую строку для создания новой ноды и подключения к сети;
  2. необходимо обеспечить автоматическое распределение ключей между всеми активными узлами;
  3. необходимо обеспечить упрощенную процедуру обмена ключами между bootnod’ой и новым клиентом.

  bootnode — узел с публичным адресом (см. выше);

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

  Именно эти задачи и выполняет tinc-boot.

  tinc-boot — это самодостаточное, не считая tinc , приложение с открытым исходным кодом, обеспечивающее:

  • простое создание нового узла;
  • автоматическое подключение к существующей сети;
  • задание большинства параметров по-умолчанию;
  • распределение ключей меду узлами.

  Архитектура

  Исполняемый файл tinc-boot состоит из четырех компонент: сервера начальной загрузки (bootnode), сервера управления распределением ключей и RPC команд управления к нему, а также модуль генерации узла.

  Модуль генерации узла

  Модуль генерации узла ( tinc-boot gen ) создает все необходимые файлы для успешного запуска tinc.

  Упрощенно, его алгоритм можно описать так:

  1. Определить имя узла, сеть, параметры IP, порт, маску подсети и т.п.
  2. Нормализовать их (tinc имеет ограничение на некоторые значения) и создать недостающие
  3. Проверить параметры
  4. Если необходимо — установить tinc-boot в систему (отключаемо)
  5. Создать скрипты tinc-up , tinc-down , subnet-up , subnet-down
  6. Создать файл конфигурации tinc.conf
  7. Создать файл узла hosts/
  8. Выполнить генерацию ключа
  9. Произвести обмен ключами с bootnode
     1. Зашифровать и подписать собственный файл узла с публичным ключом, случайный вектор инициализации (nounce) и имя узла при помощи xchacha20poly1305, где ключом шифрование является итог функции sha256 от токена
     2. Выполнить отправку данных по HTTP протоколу на bootnode
     3. Полученный ответ и заголовок X-Node , содержащий имя загрузочного узла, расшифровать, используя оригинальный nounce и по такому же алгоритму
     4. В случае успеха, сохранить полученный ключ в hosts/ и добавить запись ConnectTo в файл конфигурации (т.е. рекомендация куда подключаться)
     5. Иначе — воспользоваться следующим в списке адресом загрузочной ноды и повторить с п. 2

     Преобразование через SHA-256 служит только для нормализации ключа до 32 байт

     Для самого первого узла (т.е. когда нечего указывать в качестве загрузочного адреса), п.9 пропускается. Флаг —standalone .

     Пример 1 — создание первого публичного узла

     Публичный адрес — 1.2.3.4

     sudo tinc-boot gen —standalone -a 1.2.3.4

     • флаг -a позволяет указывать публично доступные адреса

     Пример 1 — добавление не-публичного узла к сети

     Загрузочный узел будет взят из примера выше. На узле необходимо иметь запущенный tinc-boot bootnode (далее описано).

     sudo tinc-boot gen —token «MY TOKEN» http://1.2.3.4:8655

     • флаг —token задает токен авторизации

     Модуль начальной загрузки

     Модуль начальной загрузки ( tinc-boot bootnode ) поднимает HTTP сервер с API для первичного обмена ключами с новыми клиентами.

     По-умолчанию, используется порт 8655 .

     Упрощенно, алгоритм можно описать так:

     1. Принять запрос от клиента
     2. Расшифровать и проверить запрос при помощи xchacha20poly1305, используя вектор инициализации, переданный при запросе, и где ключом шифрование является итог функции sha256 от токена
     3. Проверить имя
     4. Сохранить файл, если файла с таким именем еще нет
     5. Зашифровать и подписать собственный файл узла и имя, используя алгоритм, описанный выше
     6. Вернуться на п.1

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

     

     Пример 1 — запуск узла загрузки

     Предполагается, что первоначальная инициализация узла была проведена ( tinc-boot gen )

     tinc-boot bootnode —token «MY TOKEN»

     • флаг —token задает токен авторизации. Он должен быть одинаковым у клиентов, подключающихся к узлу.

     Пример 2 — запуск узла загрузки как сервис

     tinc-boot bootnode —service —token «MY TOKEN»

     • флаг —service указывает создать systemd сервис (по умолчанию, для данного примера tinc-boot-dnet.service )
     • флаг —token задает токен авторизации. Он должен быть одинаковым у клиентов, подключающихся к узлу.

     Модуль распределения ключей

     Модуль распределения ключей ( tinc-boot monitor ) поднимает HTTP сервер с API для обмена ключами с другими узлами внутри VPN. Он закрепляется на выданный сетью адрес (порт по-умолчанию — 1655 , конфликтов с несколькими сетями не будет, так как каждая сеть имеет/должна иметь свой адрес).

     Модуль запускается и работает полностью автоматически: работа с ним в ручном режиме не нужна.

     Этот модуль запускается автоматически при поднятии сети (в скрипте tinc-up ) и автоматически останавливается при остановке (в скрипте tinc-down ).

     • GET / — отдать свой файл узла
     • POST /rpc/watch?node=<>&subnet=<> — забрать файл от другого узла, предполагая наличие на нем запущенного аналогичного сервиса. По-умолчанию, попытки идут с таймаутом в 10 секунд, каждые 30 секунд вплоть до успеха или отмены.
     • POST /rpc/forget?node=<> — оставить попытки (если они еще есть) забрать файл от другого узла
     • POST /rpc/kill — завершает работу сервиса

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

     Модуль распределения ключей (управление)

     Команды на запрос ( tinc-boot watch ) и отмену запроса ( tinc-boot forget ) файла конфигурации от других узлов выполняются автоматически при обнаружении нового узла (скрипт subnet-up ) и остановке (скрипт subnet-down ) соответственно.

     В процессе остановке сервиса, исполняется скрипт tinc-down в котором исполняется команда tinc-boot kill останавливающий модуль распределения ключей.

     Вместо итого

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

     Основными идеями в процессе разработки были:

     • если что-то может быть автоматизированно, оно должно быть автоматизировано;
     • значения по-умолчанию должны покрывать как минимум 80% использования (принцип Парето);
     • любое значение можно переопределить как при помощи флагов, так и при помощи переменных окружения;
     • утилита должна помогать, а не вызывать желание призвать все кары небесные на создателя;
     • использование токена авторизации для начальной инициализации — очевидный риск, однако, по мере возможности, он был сведен до минимума за счет тотальной криптографии и аутентификации (даже имя узла в ответном заголовке невозможно подменить).
     • Первый раз я воспользовался tinc более 4-ех лет назад. Изучил значительный объем материала. Настроил идеальную (в моем представлении) сеть
     • Спустя пол-года, tinc был заменен в пользу zerotier, как более удобное/гибкое средство
     • 2 года назад, я сделал Ansible playbook для развертывания tinc
     • Через месяц мой скрипт сломался на инкрементальном развертывании (т.е. когда нельзя получить доступ ко всем узлам сети, а значит распределить ключи)
     • Две недели назад, я написал bash-script скрипт, который явился прототипом для tinc-boot
     • 3 дня назад после второй итерации, родилась первая (0.0.1 если быть точным) версия утилиты
     • 1 день назад я свел установку новой ноды до одной строки: curl -L https://github.com/reddec/tinc-boot/releases/latest/download/tinc-boot_linux_amd64.tar.gz | sudo tar -xz -C /usr/local/bin/ tinc-boot
     • В скором времени, будет добавлена возможность еще более простого подключения к сети (не в ущерб безопасности)

     Во время разработки я активно тестировал на реальных серверах и клиентах (картинка из описания работы tinc выше взята из реальной жизни). Сейчас система работает без нареканий, а все сторонние VPN сервисы теперь отключены.

     Код приложения написан на GO и открыт под лицензией MPL 2.0. Лицензия (вольный перевод) позволяет коммерческое (если вдруг кому-то надо) использование без открытия исходного продукта. Единственное требование — вносимые изменения обязаны быть переданы проекту.

     Полезные ссылки

     • Репозиторий
     • Документация по tinc
     Читать:

     Как подключиться к роутеру asus удаленно через интернет