
## Overview

Our configuration client allows you to easily deploy the OpenPGP app on YubiKey and share its public key information with Isecway.

This process is absolutely secure, and the private key is not stored. Each key is created in an independent session, and all files related to gpg are immediately deleted after the operation is completed or fails. Only the public PGP and SSH keys are uploaded to Isecway for your access at any time.

## Installation Instructions

We currently offer .rpm and .deb packages for Linux systems and a Docker image. In addition, the configuration client can also be compiled and run on Windows and MacOS systems.

Please note that if you choose to use Docker, make sure your Docker container can access the host's device, otherwise you may receive an error message of `key not detected`.

## Configuration Guide

You can view the description of all configuration options with the following command:

```bash
iseckey -h
```

### Command Line Interface (CLI) Options and Configuration

Configuration can be set through command line options, environment variables, or a `.env` file.

| Name              | Description                                                  | Required | CLI Option             | Environment Variable  | Default Value                |
|-------------------|--------------------------------------------------------------|----------|------------------------|-----------------------|------------------------------|
| Configurer ID     | Displayed in the Isecway user interface                      | Yes      | --id                   | WORKER_ID             | YubikeyProvisioner           |
| Log Level         | Set the log recording level                                  | No       | --log-level            | LOG_LEVEL             | info                         |
| GRPC Endpoint     | URL pointing to your Isecway instance GRPC endpoint. Make sure to include **`http`** or **`https`**! | Yes | --grpc             | GRPC_URL              | http://127.0.0.1:60666       |
| GRPC CA File      | CA file path. If you want GRPC to use TLS encryption, you need this file.<br><br>If this file is provided, there is no need to change http in the endpoint. | No | --ca-file          | GRPC_CA               |                              |
| Authorization Token | The authorization token found on the configurator page in the Isecway user interface. | Yes  | --token               | ISECWAY_TOKEN         |                              |
| Detection Retry Count | The number of attempts by the configurator to detect the presence of YubiKey in the system, after which it will give up. | No   | --smartcard-retries   | YUBIKEY_RETRIES       | 1                            |
| Retry Interval    | Waiting time (seconds) between each retry.                   | No       | --smartcard-retry-interval | YUBIKEY_RETRY_INTERVAL | 15               |
| GPG Debug Level   | Set the debug level of the gpg command during gpg operations.| No       | --gpg-debug-level     | GPG_DEBUG_LEVEL       | none                         |

## Sample Command

The following command shows how to run the configurator with "example" as the ID, and pointing to the local 60666 GRPC endpoint.

```bash
iseckey --id example --token <TOKEN> --grpc http://localhost:60666
```

## Getting Client Access Token

When registering a new configuration client, you need an access token provided by your instance. You can find it on the information card on the “Configurator” page.

## Use Case

This path explains how an administrator can configure keys for users. Users can also configure keys for themselves through the same configuration mode on their personal profile page, provided that there are available configurators on the instance.

Under the “Configurator” tab in the Isecway web application, you can see all available configuration clients.


The steps to configure the key are as follows:

1. Select a user on the “Users” page of the Isecway web application (or if you are configuring a key for yourself, go to “My Profile”).

2. Insert the YubiKey into the machine running the configuration client.
3. Select the “Add YubiKey” operation for the selected user in the user list.

4. 

Select your configurator and click the “Configure YubiKey” button.


The service will prepare and configure your key in a short time. After the process is completed, the popup will close, and you will receive a notification in the corner of the screen.

## Frequently Asked Questions

#### The client did not detect YubiKey

If the client does not detect YubiKey, try pulling it out of the machine and reinserting it. If you are using Linux, consider restarting the pcscd service. If using a Docker image, make sure the container can access the host device.

#### Configuration failure / IO error in logs

This is usually similar to the problem of not detecting YubiKey. If running under a virtual machine (VM) without direct access to the host USB device, the configurator or gpg program may not be able to correctly send commands to the YubiKey smart card. In this case, make sure that gpg can access and operate the smart card from the virtual machine without barriers, refer to the guide by yubico [guide](https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP).

#### Configurator registration failed

This error is usually because your configurator encountered a problem while trying to connect to the Isecway GRPC endpoint. Make sure:

* To include `http://` in the GRPC URL.
* If using a Docker container, run Docker on the host network with the `--privileged` option.
* Ensure that the host machine running the configurator can connect to the Isecway GRPC endpoint.

***


## 概览

我们的配置客户端可以让您轻松地在 YubiKey 上部署 OpenPGP 应用，并将其公钥信息分享至 Isecway。

此过程绝对安全，私钥不会被存储。每个密钥都在独立的会话中创建，且与 gpg 相关的所有文件都会在操作完成或失败后立即删除。仅公开的 PGP 和 SSH 密钥会被上传至 Isecway，以便您随时访问。

## 安装说明

我们目前提供 Linux 系统的 .rpm 和 .deb 安装包及 Docker 镜像。此外，配置客户端也可以在 Windows 和 MacOS 系统上编译和运行。

请注意，若选择使用 Docker，请确保您的 Docker 容器能够访问主机的设备，否则可能会出现 `未检测到密钥` 的错误提示。

## 配置指南

您可以通过以下命令查看所有配置选项的说明：

```bash
iseckey -h
```

### 命令行界面（CLI）选项及配置

配置可以通过命令行选项、环境变量或 `.env` 文件来设置。

| 名称            | 描述                                                            | 必须 | CLI 选项              | 环境变量            | 默认值                        |
|---------------|---------------------------------------------------------------|-----|-------------------|------------------|----------------------------|
| 配置者 ID       | 在 Isecway 用户界面中显示                                         | 是   | --id             | WORKER_ID        | YubikeyProvisioner         |
| 日志级别         | 设置日志记录级别                                                   | 否   | --log-level      | LOG_LEVEL        | info                       |
| GRPC 端点       | 指向您的 Isecway 实例 GRPC 端点的 URL。请确保包含 **`http`** 或 **`https`**！ | 是   | --grpc           | GRPC_URL         | http://127.0.0.1:60666     |
| GRPC CA 文件    | CA 文件路径。如果您希望 GRPC 使用 TLS 加密，则需要此文件。<br><br>如果提供了此文件，不需要更改端点中的 http。| 否   | --ca-file        | GRPC_CA          |                            |
| 授权令牌        | 在 Isecway 用户界面的配置者页面找到的授权令牌。                          | 是   | --token          | ISECWAY_TOKEN    |                            |
| 检测重试次数      | 配置器尝试检测系统中 YubiKey 存在次数，超过此次数后将放弃。                | 否   | --smartcard-retries | YUBIKEY_RETRIES  | 1                          |
| 重试间隔        | 每次重试之间的等待时间（秒）。                                          | 否   | --smartcard-retry-interval | YUBIKEY_RETRY_INTERVAL | 15               |
| GPG 调试级别    | 在执行 gpg 操作时设置 gpg 命令的调试级别。                               | 否   | --gpg-debug-level | GPG_DEBUG_LEVEL | none                     |

## 示例命令

如下命令展示了如何运行配置器，其中以 "example" 为 ID，并指向本地的 60666 GRPC 端点。

```bash
iseckey --id example --token <TOKEN> --grpc http://localhost:60666
```

## 获取客户端访问令牌

注册新的配置客户端时，您需要一个由您的实例提供的访问令牌。您可以在 “配置者” 页面的信息卡片中找到它。

## 使用案例

此路径说明了管理员如何为用户配置密钥。用户也可以通过其个人资料页面上的相同配置模式为自己配置密钥，前提是实例上有可用的配置器。

在 Isecway 网页应用的 “配置器” 标签下，您可以看到所有可用的配置客户端。


配置密钥的步骤如下：

1. 在 Isecway 网页应用的 “用户” 页面选择一个用户（或者如果您是为自己配置密钥，转到 “我的个人资料”）。

2. 将 YubiKey 插入运行配置客户端的机器。
3. 在用户列表中为选定的用户选择 “添加 YubiKey” 操作。

4. 

选择您的配置器并点击 “配置 YubiKey” 按钮。


服务将在短时间内准备并配置您的密钥。过程完成后，弹窗将关闭，您将在屏幕角落收到通知。

## 常见问题解答

#### 客户端未检测到 YubiKey

如果客户端未检测到 YubiKey，尝试将其从机器上拔出并重新插入。如果您使用 Linux，考虑重启 pcscd 服务。若使用 Docker 镜像，请确保容器能够访问宿主机设备。

#### 配置失败 / 日志出现 IO 错误

这通常与未检测到 YubiKey 问题类似。如果在没有直接访问宿主 USB 设备的虚拟机 (VM) 下运行，配置器或 gpg 程序可能无法正确向 YubiKey 智能卡发送命令。在这种情况下，请确保 gpg 能够从虚拟机无障碍地访问智能卡并对其进行操作，具体操作可参考 yubico 的[指南](https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP)。

#### 注册配置器失败

这个错误通常是因为您的配置器在尝试连接到 Isecway GRPC 端点时出现问题。请确保：

* 在 GRPC URL 中包含 `http://`。
* 如果使用 Docker 容器，请以 `--privileged` 选项在宿主网络上运行 Docker。
* 确保运行配置器的宿主机能够连接到 Isecway GRPC 端点。

**SSH Authentication**
======================

**Overview**
------------

Isecway allows you to configure SSH authentication on your servers to use public SSH keys stored in your instance's database. This is possible by using the `AuthorizedKeysCommand` option in the OpenSSH daemon configuration file.

> **Warning:** For the time being, each user can only have one SSH key added. It can be done by provisioning a YubiKey. Allowing users to add arbitrary public keys to their accounts is already on the roadmap. Once implemented, the changes should not impact the guide below.

The specific API endpoint used for this is `/api/v1/ssh_authorized_keys`. It returns a list of public keys, each on a new line. It allows you to filter your query by specifying a username, a group, or a combination of both.

**Setup**
---------

There's no specific configuration to be performed in Isecway itself (aside from adding SSH keys for users, of course). All the steps below are performed on the server you want to SSH into using Isecway-supplied public keys:

1. Add a script that fetches SSH keys from your Isecway instance:

```bash
#!/bin/sh

curl https://isecway.example.com/api/v1/ssh_authorized_keys?username="${1}"
```

2. Make it executable, set correct ownership, and permissions:

```bash
sudo chown root:root /usr/local/bin/get_ssh_keys.sh
sudo chmod 0755 /usr/local/bin/get_ssh_keys.sh
```

3. Update the OpenSSH daemon config (`/etc/ssh/sshd_config`) to include the following lines:

```
AuthorizedKeysCommand /usr/local/bin/get_ssh_keys.sh
AuthorizedKeysCommandUser nobody
```

4. Restart the OpenSSH daemon:

```bash
sudo systemctl restart sshd
```

With this setup, when a user `someuser` tries to log in with SSH to your server, the script will make a `GET` request to your Isecway instance and fetch a list of keys assigned to `someuser` (if such a user exists). This list is then used to verify the keys presented by the client.

### **Other Examples**

Here are some other script examples that can be useful in different server setups:

- Only allow users in the `admin` group to log in with SSH:

```bash
#!/bin/sh

curl https://isecway.example.com/api/v1/ssh_authorized_keys?group=admin&username="${1}"
```

- Allow all users in the `admin` group to log in, but only to the `adminuser` account:

```bash
#!/bin/sh

test $# -ne 1 -o "${1}" != 'adminuser' && exit 1

curl https://isecway.example.com/api/v1/ssh_authorized_keys?group=admin
```

**SSH认证**
======================

**概览**
------------

Isecway允许您在服务器上配置SSH认证，以使用存储在实例数据库中的公共SSH密钥。这可以通过在OpenSSH守护进程配置文件中使用`AuthorizedKeysCommand`选项来实现。

> **警告：**目前，每个用户只能添加一个SSH密钥。这可以通过配置YubiKey来完成。允许用户向其账户添加任意公共密钥已在路线图上。一旦实施，这些更改不应影响下面的指南。

用于此目的的特定API端点是`/api/v1/ssh_authorized_keys`。它返回一行一个的公共密钥列表。它允许您通过指定用户名、组或两者的组合来过滤查询。

**设置**
---------

在Isecway本身中没有特定的配置要执行（当然，除了为用户添加SSH密钥）。下面的所有步骤都在您想要使用Isecway提供的公共密钥进行SSH登录的服务器上执行：

1. 添加一个从您的Isecway实例获取SSH密钥的脚本：

```bash
#!/bin/sh

curl https://isecway.example.com/api/v1/ssh_authorized_keys?username="${1}"
```

2. 使其可执行，设置正确的所有权和权限：

```bash
sudo chown root:root /usr/local/bin/get_ssh_keys.sh
sudo chmod 0755 /usr/local/bin/get_ssh_keys.sh
```

3. 更新OpenSSH守护进程配置(`/etc/ssh/sshd_config`)，以包含以下行：

```
AuthorizedKeysCommand /usr/local/bin/get_ssh_keys.sh
AuthorizedKeysCommandUser nobody
```

4. 重启OpenSSH守护进程：

```bash
sudo systemctl restart sshd
```

通过这种设置，当用户`someuser`尝试使用SSH登录到您的服务器时，脚本将向您的Isecway实例发出`GET`请求，并获取分配给`someuser`的密钥列表（如果该用户存在）。然后使用此列表来验证客户端提供的密钥。

### **其他示例**

这里是一些在不同服务器设置中可能有用的其他脚本示例：

- 仅允许`admin`组中的用户使用SSH登录：

```bash
#!/bin/sh

curl https://isecway.example.com/api/v1/ssh_authorized_keys?group=admin&username="${1}"
```

- 允许`admin`组中的所有用户登录，但仅限于`adminuser`账户：

```bash
#!/bin/sh

test $# -ne 1 -o "${1}" != 'adminuser' && exit 1

curl https://isecway.example.com/api/v1/ssh_authorized_keys?group=admin
```

Here's the modified and reformatted version with corrections and polishing:

**How to Configure the Connection Between iSecWay and LDAP**

**Configuration**

**Setup**

1. First, navigate to the settings page and select the LDAP tab.


2. Now, change the fields according to your LDAP instance.

> **Note:** You can find brief explanations for these settings on the same page.

3. After you save your LDAP settings, you can check if your Isecway instance can connect and authenticate with your LDAP server by clicking the "Test" button.

> **Warning:** Testing your connection doesn't guarantee that the entire configuration is correct. Currently, Isecway only verifies if a connection can be established and if the provided credentials are valid. This behavior is likely to change in future versions of Isecway.

**如何配置iSecWay与LDAP之间的连接**

**配置**

**设置**

1. 首先,导航到设置页面并选择LDAP选项卡。


2. 现在,根据您的LDAP实例更改字段。

> **注意:** 您可以在同一页面上找到这些设置的简要说明。

3. 保存LDAP设置后,您可以通过单击"测试"按钮来检查您的Isecway实例是否可以连接并验证您的LDAP服务器。

> **警告:** 测试连接并不能保证整个配置正确无误。目前,Isecway只验证是否可以建立连接以及提供的凭据是否有效。这种行为在Isecway的未来版本中可能会有所更改。


earthicon.svg

Exploring the Feasibility and Strategies for Concurrent Use of ISecWay and Other Network Tunneling Services:

In the realm of digital network security, the idea of simultaneously utilizing ISecWay alongside other Network Tunneling services has sparked widespread interest and discussion. Generally, the concurrent operation of multiple Network Tunneling services appears to be a technical challenge. This stems from the fact that the majority of Network Tunneling services enforce stringent network firewall rules to ensure all internet traffic is routed through their servers, thereby implicitly blocking traffic from other Network Tunneling. However, under certain conditions, ISecWay demonstrates its unique flexibility; it is designed to proxy specific traffic (e.g., data directed to the 100.x.y.z address range) while leaving the rest for other VPN services to handle. Despite this, achieving harmonious coexistence between the two remains challenging in practice unless the other VPN services adopt non-mandatory network rules.

For iOS device users, an additional constraint is faced due to Apple's policy in iOS systems that restricts the activation of only one Network Tunneling service at a time. Although we are actively discussing the possibility of collaboration with other Network Tunneling providers to achieve parallel operation of ISecWay and other Network Tunneling services, so far, no concrete solution or implementation timeline has been identified.

As we seek solutions, "Split Tunneling" technology might offer a temporary workaround. This technology allows users to set rules to bypass Network Tunneling traffic control for specific applications or IP address ranges. For those Network Tunneling services that support split tunneling, users might attempt to add certain IP address ranges (such as 100.64.0.0/10 and fd7a:115c:a1e0::/48) to the split tunneling rules, thus allowing ISecWay's traffic to bypass these Network Tunneling' controls. If subnet routing is enabled, the corresponding routing configurations should also be included in the split tunneling rules.

However, it is important to note that when ISecWay's exit node feature is activated, the split tunneling strategy becomes inapplicable. In exit node mode, ISecWay forcibly routes all traffic to the specified exit node, conflicting with the operational mechanisms of other Network Tunneling services. Thus, in this mode, ISecWay can only work in conjunction with one Network Tunneling service.

In summary, although there are technical difficulties in achieving the parallel use of two Network Tunneling services, we will continue to explore and experiment to find better solutions, aiming for improved service compatibility.

探索ISecWay与其他网络隧道服务并行使用的可行性及策略：

在数字网络安全领域，将ISecWay与其他网络隧道服务同时运用的想法引起了广泛的关注和讨论。通常来说，多个网络隧道服务并行运行似乎是一个技术上的挑战。这是因为绝大多数网络隧道服务会施加严格的网络防火墙规则，以确保所有的网络流量必须通过其服务器进行转发，从而隐式地阻断了其他VPN服务的流量。不过，在特定条件下，ISecWay展示了其独特的灵活性，它设计上能够代理指定的流量（例如，定向至100.x.y.z地址范围的数据），而将剩余流量留给其他VPN服务处理。尽管如此，除非其他VPN服务采取了非强制性的网络规则，否则在实际应用中实现两者的和谐共存仍然充满挑战。

对于iOS设备用户来说，他们面临着额外的制约，因为苹果公司在iOS系统中实施了一项策略，限制了同时只能激活一个VPN服务。虽然我们正积极与其他VPN供应商探讨合作的可能性，以期实现ISecWay与其他VPN服务的并行运行，但到目前为止，还没有找到一个确切的解决方案和具体的实施时间表。

在寻找解决方案的过程中，"分流"（Split Tunneling）技术可能是一个临时的解决办法。这项技术允许用户设置规则，以绕过VPN对特定应用程序或IP地址范围的流量控制。对于那些支持分流功能的VPN服务，用户可以尝试将特定的IP地址范围（如100.64.0.0/10及fd7a:115c:a1e0::/48）加入到分流规则中，从而允许ISecWay的流量绕过这些VPN的管控。如果启用了子网路由功能，相应的路由配置也应当被包含在分流规则之中。

然而，需要注意的是，当ISecWay的出口节点功能被启用时，分流策略将不再适用。在出口节点模式下，ISecWay将会把所有流量强制路由至指定的出口节点，这与其他VPN服务的运行机制存在冲突。因此，在这种模式下，ISecWay只能和一个网络隧道服务协同工作。

综上所述，虽然在技术上实现两个网络隧道服务的并行使用存在一定的难度，我们仍将持续探索与实验，以寻找更优的解决方案，以期达到更好的服务兼容性。

# FAQs about IPv4 vs IPv6

This article attempts to answer some common questions and concerns regarding IPv6, the next generation internet protocol. 

## What is IPv6?

IPv6 (Internet Protocol Version 6) is the next generation internet protocol, designed to be the successor to IPv4. According to historical records from the American Registry for Internet Numbers (ARIN), the design of IPv6 began in the mid-1990s, with the first draft standard published in 1998. The first IPv6 addresses were allocated in 1999, officially kicking off the deployment process.

The most significant advantage of IPv6 over IPv4 is its vastly larger address space. IPv4 has a total of only around 4.3 billion addresses, far from enough for future needs and even less than the current world population. In contrast, IPv6 has 2^128 addresses, an extremely large number estimated to be enough to assign 100 addresses to every atom on Earth.

In addition to expanding the address space, IPv6 made improvements to the header structure, extension mechanisms, and multicast support. The headers are easier for machines to parse, extension mechanisms are simpler and more direct, and multicast schemes are more mature.

However, IPv6 also has some downsides, such as a more complex address structure, difficulty in memorizing the long addresses, and a deployment process that has been much slower than initially expected - nearly 30 years after the initial design, IPv6 is still not fully deployed.

Our CEO explored the design goals of IPv6 and the differing values reflected in IPv4 and IPv6 in an article, which interested readers can refer to.

## Is IPv6 faster than IPv4?

In most cases, the performance difference between IPv4 and IPv6 is not significant. However, there are a few factors that can cause a noticeable or measurable impact on their speeds:

- Performance overhead from Network Address Translation (NAT) traversal  
- Performance differences due to Maximum Transmission Unit (MTU) and packet sizes
- Differences in global routing optimization between IPv4 and IPv6 networks

Contrary to some rumors, the performance impact of NAT devices is usually negligible in terms of throughput or latency. Most modern router hardware can handle NAT at line speed. If anyone claims that NAT slows down speeds, we recommend that you test and verify it yourself.

The minimum IPv6 header size is 40 bytes, 20 bytes longer than the 20-byte IPv4 header. Given a typical Ethernet MTU of 1500 bytes, this theoretically means that IPv6 would be about 1.3% slower than IPv4 on the same network. However, such a small difference is difficult to measure in practice.

The biggest difference between IPv4 and IPv6 lies in global routing optimization. Influenced by various factors, Internet Service Providers (ISPs) have deployed completely different routing for their IPv4 and IPv6 networks, potentially traversing different cables, countries, or even continents.

Statistically, some ISPs have better optimized IPv4 routing, while others have better IPv6 routing. You may find that using one protocol is faster depending on the remote ISP. As it is impossible to predict which routing will be better, some software like Happy Eyeballs (RFC 6555) automatically selects the "better" protocol when establishing a connection.

To encourage migration from IPv4 to IPv6, Happy Eyeballs and its improved version Happy Eyeballs v2 (RFC 8305) will prefer IPv6 when its performance is not significantly worse than IPv4, although the specific implementations differ.

## Does IPv6 have built-in IPsec encryption?

No, this is a common misconception. Although the IPsec (Internet Protocol Security) suite was designed alongside IPv6 to provide security for it, IPsec remains an optional feature that is rarely used outside of VPN tunnel scenarios.

The original IPsec design included "opportunistic encryption," where encryption would automatically be negotiated if the remote end also supported IPsec. However, this was found to have security vulnerabilities and was ultimately not adopted.

## Is IPv6 a failure?

There is significant disagreement among network engineers on this question.

From a factual standpoint, IPv6 achieved some of its design goals to a certain extent, but its deployment has been much slower than initially expected. Moreover, IPv6 has not completely replaced IPv4 as originally envisioned – maintaining IPv4 compatibility will be necessary in the long run.

Nevertheless, IPv6 deployment continues to progress, and in some important areas, it has already surpassed IPv4.

## Why is IPv6 not more popular?

There are various explanations, including political factors, capitalist drivers, fear of change, and the complexity of IPv6's design.

At ISecWay, we believe the main reason is that in the mixed co-existence model with IPv4, IPv6 did not provide a clear enough value proposition for enterprises. The initial plan was to eventually phase out IPv4 after fully deploying IPv6, thereby simplifying network management and reducing costs. However, this value could only be realized after IPv6 achieved full coverage. This made it difficult for enterprises to recoup their IPv6 investment costs within a foreseeable timeframe, hindering investment decisions.

## Where has IPv6 seen its greatest success?

The primary purpose of IPv6 was to expand the limited address space of IPv4. The areas most starved for addresses were private networks.

RFC 1918 reserved some IPv4 address ranges for private networks, but the total was less than 18 million, which some large data centers already exceeded. Such a limited number of addresses also made it difficult to subdivide and route subnets. Address overlaps between private networks were almost inevitable, causing problems when merging networks.

IPv6 completely solved these issues for large data centers and private networks. With the vast address space, subnets could be randomly assigned without worrying about overlaps.

Data centers could use pure IPv6 internally and map the traffic to IPv4 at the egress points since servers are typically behind load balancers. This allowed data centers to deploy IPv6 even if clients and ISPs only supported IPv4.

Unfortunately, home networks rarely use IPv6, mainly due to concerns about application compatibility and a preference for the more memorable IPv4 addresses.

## Can IPv6 provide free permanent static IPs?

No, it cannot. The IPv6 addresses you receive depend on your ISP's network routing configurations. If you switch ISPs or your ISP re-architects its network, you will get a brand new set of IPv6 addresses. In this regard, IPv6 is similar to the dynamic IPv4 address allocation of the past.

You can certainly apply for your own IPv6 address block and configure the routing yourself, effectively becoming an ISP. However, this involves costs and management complexity that most organizations would not undertake.

## Does IPv6 support mobile IP or multi-homing scenarios?

Yes, but with similar limitations as IPv4.

When you roam between different networks, your IP address will change. For multi-homing, each connection requires a separate IP address. TCP connections will be disrupted when the IP changes.

Mobile IP support was discussed during the IPv6 standardization process but was not resolved, with plans to address it after completing the initial deployment.

## Will IPv6 ever be fully deployed?

It is unlikely that every single device will support IPv6 within our lifetimes. Some form of IPv4 compatibility will likely still be required.

However, many devices, especially mobile phones, now only support IPv6 out of the box. They can access IPv4 devices through NAT and proxies.

So it is possible for all client devices to eventually support IPv6. In fact, some ISPs have already become IPv6-only networks, while mainstream ISPs support a dual-stack (IPv4+IPv6) approach.

## Should my server support IPv6?

Supporting IPv6 on your server may provide benefits if more clients support IPv6. Otherwise, the impact on the current situation may be limited.

Thanks to NAT, IPv6-only clients can access IPv4-only servers, but not vice versa – IPv4-only clients cannot access IPv6-only servers.

In theory, eliminating the need for NAT could potentially improve performance. However, in practice, the performance impact of modern NAT is negligible.

## What can I do to drive IPv6 deployment?

After more than 20 years of effort, calls and complaints seem to have had limited effect.

Running an IPv6-only server could force clients to adopt IPv6 to access it, but no popular mainstream service has successfully done so yet.

One thing you can do is to prioritize IPv6 when setting up new private networks. This not only prepares for IPv6 but also simplifies network management.

## Have all IPv4 addresses really been exhausted?

Yes, all available IPv4 addresses have now been allocated.

However, there is still a marketplace for trading IPv4 addresses. In 2021, Amazon purchased millions of IPv4 addresses at a price of around $40 per address. With technologies like TLS SNI, load balancing, and NAT, a single IPv4 address can be greatly extended in its usage. So organizations can still afford to purchase sufficient IPv4 addresses, albeit at rising prices.

We expect more and more IPv4 addresses to be purchased for server use, while clients increasingly use Carrier-Grade NAT (CGNAT). Meanwhile, IPv4 address prices may continue to rise, driving the emergence of various address-saving techniques.

## Does IPv6 make P2P applications easier?

To a certain extent, yes.

The initial vision of IPv6 was to enable direct device-to-device connections, without intermediary devices. However, this turned out to be unrealistic, and firewalls and NAT traversal techniques are still necessary. That said, NAT traversal would be simpler in an IPv6 environment, with fewer edge cases.

However, since not all endpoints support IPv6, applications need to support both IPv4 and IPv6, increasing complexity. IPv6 code is also often undertested.

With ISecWay, devices within the isecnet are assigned IPv6 addresses and can access each other via IPv6. When necessary, ISecWay can also tunnel IPv6 packets over IPv4.

## If IPv6 is fully deployed, can NAT be eliminated?

Not necessarily. IPv4 may never completely disappear, so IPv4-to-IPv6 NAT would still be required.

In fact, various forms of NAT serve useful purposes in network management. For example, mobile IP schemes involve NAT to maintain a consistent IP address as devices roam between networks. In mesh topologies, NAT can route data packets through mesh nodes for easier return paths.

IPv6 did not provide an easy way to delegate subnets to devices within a local network. Typically, the subnet is delegated to the local router, which then uses NAT to represent other devices for routing – the ISecWay exit node is an example of this.

## Can IPv6 eliminate Carrier-Grade NAT (CGNAT)?

No, it cannot. When IPv6-only devices access IPv4-only servers, CGNAT will still be required.

## Can IPv6 solve the double NAT problem?

Usually not. If NAT is required in an IPv6 scenario, double NAT situations may still occur, just as with IPv4.

The "double NAT problem" is often overstated. Throughput and latency are rarely significantly affected. The main issue is the incompatibility of certain protocols like UPnP in double NAT environments. We hope future standards will support double NAT scenarios.

Modern NAT traversal techniques like ISecWay can typically handle double NAT situations, but some applications, especially games, may still have issues.

## Does NAT improve security?

This claim is not entirely accurate. There is a view that NAT improves security by making it difficult to send packets directly to devices hidden behind a NAT. However, once a session is established, incoming packets from the outside can still attack the internal devices.

Additionally, by enabling static port forwarding on the router, external devices can bypass the NAT and directly access internal devices, eliminating any protection offered by the NAT.

Without NAT, a stateless firewall can also block unsolicited inbound traffic, providing similar protection as a NAT, as long as the firewall is properly configured. One could argue that with a properly configured firewall, the security of IPv6 without NAT would not be affected.

What can be said is that stateful firewalls greatly improve network security.

## Does NAT improve privacy?

There are differing views on this.

On one hand, having multiple devices hidden behind a single NAT, especially CGNAT, makes it more difficult to attribute network traffic to specific devices, thereby enhancing privacy.

On the other hand, IPv6's privacy extensions allow for periodically rotating the IP addresses used, achieving a similar effect of hiding device identities.

Critics argue that modern tracking techniques go beyond just relying on IP addresses, such as cookies, login states, browser fingerprinting, and more.

Most experts recommend that for true anonymity, dedicated anonymous communication tools like Tor are still required. However, NAT and IPv6 privacy extensions can serve as additional layers of protection to enhance privacy to some degree.

## Could the IPv6 design have progressed faster?

This is a difficult hypothetical question to answer. Hindsight is always 20/20, but it's challenging to predict during the actual design process.

Perhaps a more focused approach and maintaining backward compatibility could have helped, but what exactly that design would look like is unknown to us.

Extending IPv4 addresses while maintaining backward compatibility would have its own set of challenges:

- Simply adding more address bits would still face deployment and compatibility challenges similar to IPv6's parallel deployment.
- Extending the IPv4 header length to accommodate longer addresses might have been feasible, with routers not requiring upgrades and deployment being simpler. But an approach similar to tunneling IPv6 over IPv4 could still face some compatibility issues.
- In a sense, NAT was an accidental form of address extension – only client routers needed to understand it, while servers were unaffected. However, it lacked the ability for backward initialization.

Perhaps extending NAT to allow clients to indicate the target IPv4 address could have helped drive adoption, but this would require upgrades on both client and server sides, making adoption difficult.

Some more radical ideas, like using DNS SRV records or non-standard ports to extend the IPv4 address space to 48 bits, or leveraging the HTTP Host header to provide near-infinite address space, have been proposed. However, with IPv4 address prices still relatively low, these ideas haven't gained much traction yet.

## Does ISecWay support IPv6?

Yes, ISecWay supports IPv6. It can perform peer-to-peer routing through mixed IPv4 and IPv6 tunnels, regardless of whether the path involves NAT, multiple levels of NAT, or CGNAT. Within the tunnel, each node is assigned private IPv4 and IPv6 addresses. Even if the tunnel path itself is IPv4, your IPv6 address can still be successfully used.

# IPv4与IPv6常见问题解答

本文旨在回答一些关于下一代互联网协议IPv6的常见疑虑。

## 什么是IPv6?

IPv6(Internet Protocol Version 6)是下一代互联网协议,被设计为IPv4的继任者。根据美国互联网号码分配机构(ARIN)的历史记载,IPv6的设计工作始于1990年代中期,第一版IPv6标准草案于1998年发布。第一批IPv6地址的分配是在1999年,正式拉开了IPv6部署的序幕。

相较于IPv4,IPv6最显著的优势在于拥有大得多的地址空间。IPv4总共只有约42亿个地址,远远不足以满足未来需求,甚至少于当前地球人口数量。而IPv6则拥有2的128次方个地址,是一个极其庞大的数字,估计足以为地球上每一个原子分配100个地址而永不枯竭。

除了扩大地址空间,IPv6还在头信息结构、扩展机制、多播支持等方面做出了改进。头信息更容易被机器解析,扩展机制更简单直接,多播方案也更加成熟。

然而,IPv6也存在一些缺陷,比如地址结构更复杂、地址长度难以记忆,以及部署进程缓慢——距离最初设计已经过去近30年,IPv6至今仍未完全部署到位,进展比预期慢了20多年。

我们的CEO在一篇文章中探讨了IPv6的设计目标,以及IPv4和IPv6所反映出的不同价值观。有兴趣的读者可以阅读一下。

## IPv6是否比IPv4更快?

大多数情况下,IPv4和IPv6在性能表现上差异不太明显。但是,有一些因素可能会对它们的速度产生可感知或可测量的影响:

- 网络地址转换(NAT)带来的性能损耗
- 最大传输单元(MTU)和数据包大小导致的性能差异
- IPv4和IPv6在全球路由优化上的差距

与一些传言相反,NAT设备对网络性能的影响通常可以忽略不计,无论是吞吐量还是延迟。大多数现代路由器在硬件NAT方面的性能都可以达到线路

的最大速率。如果有人声称NAT会拖慢网速,我们建议你自己进行测试来验证。

IPv6头部最小长度是40字节,比IPv4头部的20字节多出20字节。以典型的以太网MTU 1500字节为例,这意味着在相同网络条件下,IPv6的理论传输速度会比IPv4慢约1.3%。然而,这样微小的差距在实际测试中很难被发现。

IPv4和IPv6之间最大的差异在于全球路由优化情况。受到各种因素的影响,互联网服务提供商对IPv4和IPv6网络采用了完全不同的路由规划,数据包可能会经过不同的电缆、国家乃至洲。

根据统计数据,有些ISP的IPv4路由更优,有些ISP的IPv6路由更优。你可能会发现,根据远端ISP的不同,使用某种协议的速度会更快。由于无法预测哪种路由方式更佳,一些软件如Happy Eyeballs (RFC6555)会在建立连接时自动选择"更好"的协议。

为了鼓励从IPv4向IPv6的迁移,Happy Eyeballs和其改进版Happy Eyeballs v2 (RFC8305)在IPv6性能没有明显低于IPv4时,会优先选择IPv6连接,但具体实现细节有所不同。

## IPv6是否内置了IPsec加密?

不,这是一个常见的误解。虽然IPsec(Internet Protocol Security)安全协议同时期被设计出来,旨在为IPv6提供安全保障,但它仍然是一个可选功能,很少在除VPN隧道之外的场景下使用。

IPsec原本被设计为支持"主动式加密",即在检测到对端也支持IPsec时自动协商并建立加密连接。但由于这一机制被发现存在安全隐患,因此最终没有被采纳。

## IPv6算失败吗?

对于这个问题,网络工程师们存在较大分歧。

从事实上来看,IPv6在一定程度上实现了其设计目标,但部署速度却比最初预期慢得多。而且,IPv6也没有像最初设想的那样完全取代IPv4。从长远来看,保留IPv4兼容性是必须的。

尽管如此,IPv6部署仍在继续推进,并且在某些重要领域已经优于IPv4。

## 为什么IPv6不更流行?

对此有多种解释,包括政治因素、资本主义驱动、对变革的恐惧情绪,以及IPv6设计过于复杂等。

在ISecWay,我们认为主要原因在于,在与IPv4共存的混合模式下,IPv6没有为企业提供足够明确的价值主张。最初的计划是在IPv6完全部署之后再逐步抛弃IPv4,届时可以简化网络管理,节省成本。但这种价值要等到IPv6完全覆盖后才能真正体现。这导致企业无法在可预见的未来内收回IPv6投资,因而难以做出投资决策。

## IPv6取得最大成功的地方是哪里?

IPv6的主要目的是扩大IPv4有限的地址空间。而地址空间最为紧缺的地方,正是那些私有网络。

RFC1918为私有网络预留了一些IPv4地址范围,但总量不到1800万,一些大型数据中心就需要超过这个数量的地址。如此有限的地址也很难划分子网和路由。另外,私网地址重叠的情况也几乎无法避免,会导致在合并网络时出现问题。

IPv6彻底解决了大型数据中心和私有网络的这些烦恼。由于地址空间巨大,可以随机分配子网而不用担心重叠。

数据中心内部可以使用纯IPv6,在出口处将流量映射为IPv4,因为服务器都是位于负载均衡器之后。这使得即使客户端和ISP只支持IPv4,数据中心也可以部署IPv6。

不过不幸的是,家庭网络很少使用IPv6,主要出于对应用兼容性的担忧,同时也更偏好易于记忆的IPv4地址。

## IPv6是否可以免费提供永久静态IP?

不可以。你从ISP获得的IPv6地址取决于其网络路由设置。如果你切换ISP或ISP重新规划网络,你会获得全新的IPv6地址。在这一点上,IPv6与过去IPv4动态地址分配的情况类似。

你当然可以申请自己的IPv6地址段并自行配置路由,实际上成为一个ISP。但这需要一定的成本和管理复杂度,大多数组织不会这样做。

## IPv6是否兼容移动IP或多宿主场景?

是的,但与IPv4一样,也存在局限性。

当你在不同网络之间漫游时,IP地址会发生改变。对于多宿主场景,每个连接都需要单独的IP地址。TCP连接在IP切换时将中断。

在IPv6标准化过程中,移动IP的支持曾被讨论过,但最终没有解决这一问题。当时的计划是先完成IPv6部署,之后再处理移动性问题。

## IPv6是否会最终完全部署?

在我们有生之年,看到每一台设备都支持IPv6的可能性不大。某种形式的IPv4兼容性仍将需要保留。

但是,当下许多设备尤其是手机已经开始只支持IPv6了。它们可以通过NAT和代理访问IPv4设备。

所以,未来所有客户端设备都支持IPv6这一情况是有可能发生的。事实上,一些ISP已经成为纯IPv6(IPv6 only)网络。主流ISP目前则支持双协议栈(IPv4+IPv6)。

## 我的服务器是否应支持IPv6?

如果更多客户端支持IPv6,那么为服务器启用IPv6支持将会有所助益。否则,对现状帮助不大。

由于存在NAT,纯IPv6客户端可以访问纯IPv4服务器,但反过来纯IPv4客户端则无法访问纯IPv6服务器。

理论上,不再需要NAT可能会提升性能。但实际上,现代NAT对性能影响很小。

## 我可以做什么来推进IPv6部署?

经过20多年的努力,单纯呼吁和抱怨的作用似乎有限。

运行纯IPv6服务器可以迫使客户端采用IPv6才能访问。但目前还没有流行的主流服务这样做过。

你可以做的一件事,是在新建私有网络时优先采用IPv6。这无疑是为IPv6做好了准备,同时也简化了网络管理。

## IPv4地址真的已经用光了吗?

是的,所有可分配的IPv4地址现在都已经分配完毕。

不过,IPv4地址仍有一个交易市场。2021年,亚马逊就以每个约40美元的价格购买了数百万个IPv4地址。利用TLS SNI、负载均衡和NAT等技术,一个IPv4地址可以被拓展使用于更多场合。所以,即使价格在上涨,大型组织仍可以负担购买足够的IPv4地址。

我们预计,会有越来越多的IPv4地址被购买用于服务器端,而客户端则越来越多地使用载体级NAT(CGNAT)。与此同时,IPv4地址价格可能会继续上涨,从而促使各种节约地址的技术手段出现。

## IPv6是否使P2P应用更简单?

在一定程度上是这样的。

IPv6最初的设计梦想是能够实现设备直接对等连接,无需中间设备。但这种想法是不现实的,防火墙和NAT穿透技术依然是必需的。不过,在IPv6环境下,NAT穿透会更简单,减少边界情况。

但由于不能假设所有对端都支持IPv6,所以应用程序需要同时支持IPv4和IPv6,这增加了复杂度。另外,IPv6代码常常缺乏充分的测试。

使用ISecWay,设备在isecnet内部都会分配到IPv6地址,可以通过IPv6相互访问。在必要时,ISecWay也可以通过IPv4隧道传输IPv6数据包。

## 如果IPv6完全部署,是否可以消除NAT?

不一定。IPv4可能永远不会完全消失,届时IPv4到IPv6的网络地址转换仍将是必需的。

事实上,在网络管理层面,各种形式的NAT都有其用处。比如移动IP方案就需要NAT来保持设备在网络间漫游时IP地址不变。在网状拓扑结构中,可以通过NAT将数据包路由经过网状节点,以方便返回。

IPv6设计中没有提供一种便捷的方式将子网授权给局域网内的设备。通常子网被授权给本地路由器,然后该路由器通过NAT代表其他设备进行路由,ISecWay出口节点就是一个例子。

## IPv6是否可以消除载体级NAT(CGNAT)?

不可以。当纯IPv6设备访问纯IPv4服务器时,仍需要CGNAT。

## IPv6是否可以解决双NAT问题? 

通常不能。如果IPv6场景下需要NAT,与IPv4一样,也可能遇到双NAT的情况。

"双NAT问题"实际上往往被夸大了。吞吐量和延迟很少会受到明显影响。主要问题在于一些协议如UPnP在双NAT环境下的不兼容性。我们期待未来的新标准能够支持双NAT场景。

现代NAT穿越技术如ISecWay通常可以处理双NAT情况,但对某些应用程序,尤其是游戏,仍可能存在问题。

## NAT是否提高了安全性?

这种说法不完全正确。有观点认为NAT使得难以直接向隐藏在NAT之后的内部设备发送数据包,从而提高了安全性。但是,一旦会话建立,来自外部的数据包仍然可以攻击内部设备。

另外,通过在路由器上启用静态端口映射,外部设备也可以绕过NAT直接访问内部设备,NAT在这种情况下就无法提供保护。

没有NAT的情况下,无状态防火墙也可以拦截未经请求的入站流量,从而提供与NAT类似的保护功能,前提是防火墙配置得当。可以说,如果防火墙配置合理,IPv6在无NAT的情况下安全性不会受到影响。

可以肯定的是,有状态防火墙大大提高了网络安全性。

## NAT是否提高了隐私?

对于这个问题存在不同观点。

一方面,多个设备隐藏在一个NAT之后,尤其是载体级NAT(CGNAT),会使得网络流量难以归属到特定设备,从这个角度来说,NAT增强了隐私。

另一方面,IPv6设计中的隐私扩展功能允许定期旋转使用的IP地址,从而隐藏设备身份,达到类似的隐私保护效果。

不过,批评者指出,现代网络跟踪技术已经不再完全依赖IP地址,比如Cookies、登录状态、浏览器指纹等手段。

大多数专家建议,如果要实现真正的匿名上网,还是需要使用Tor等专用匿名通信工具。但NAT和IPv6隐私扩展作为多层防护的一部分,在一定程度上确实有助于提高隐私。

## IPv6设计是否可以更快推进?

这是一个难以回答的假设性问题。事后总是容易指责,真正设计时却难以预见。

或许更加聚焦、向下兼容会有所帮助,但具体会是什么样的设计方案,我们无从得知。

如果要在保持与IPv4的向下兼容的同时扩展地址空间,恐怕也面临不小的挑战:

- 如果只是简单增加地址位数,仍会面临与IPv6类似的并行部署、兼容性挑战。
- 扩展IPv4头部长度以容纳更长地址或许是一种可行方案,路由器无需升级,部署会更简单。但类似于通过IPv4隧道传输IPv6的方式,也可能存在部分兼容性问题。
- 从某种角度来说,NAT实际上是一种意外的地址扩展方案 - 只需客户端路由器能识别,服务器端则无需任何改动。但它缺乏反向初始化功能。

也许通过扩展NAT,让客户端能指示服务器目标IPv4地址,有助于推进部署进度。但这需要客户端和服务器同时升级,采纳难度较大。

另一些想法则更激进,比如利用DNS SRV记录或非标准端口号,将IPv4地址空间扩展到48位;或借助于HTTP Host头字段,提供近乎无限的地址空间。由于IPv4地址价格仍然较低,这些设想暂时还没有流行开来。

## ISecWay是否支持IPv6?

是的,ISecWay支持IPv6。它可以通过IPv4和IPv6混合的隧道进行点对点路由,无论路径上是否存在NAT、多层NAT或载体级NAT。在隧道内部,每个节点都分配有私有的IPv4和IPv6地址。即使隧道路径本身是IPv4,你的IPv6地址也可以被成功使用。


ISecWay uses end-to-end encryption to protect all connections between devices, ensuring that your data is encrypted before leaving the sending device and only decrypted upon reaching the intended receiving device. During transmission, your data is unreadable to any third party, including ISecWay servers, maximizing protection against data exposure.  

Whether devices can establish connections is determined by access control lists (ACLs) set up in advance by network administrators. By default, any connection attempt is denied unless explicitly allowed by the ACL rules. Users can only view devices that are permitted to connect based on the ACL rules. This "network graph pruning" prevents you from seeing devices outside of your network.

Whenever possible, ISecWay establishes direct peer-to-peer connections between devices without routing through servers, further reducing data exposure risks.

## If I use ISecWay on my work device, can my colleagues see my personal devices?

ISecWay uses completely separate namespaces to isolate work and personal networks. Your work network colleagues can only see and connect to other devices within the same work network, restricted by the ACLs. Unless you explicitly share, they cannot see or access any personal devices in your personal ISecWay network. Your personal network functions independently, completely hidden from the work network.

## How can I limit access to my devices?  

As an end-user, you can limit incoming connections to your devices by disabling LAN access and disabling public IP sharing in the ISecWay settings. Work network administrators can limit access to your work devices by setting strict ACLs to only allow specific devices to connect. You can discuss your access control requirements with them.

Regardless, be sure to enable end-to-end encryption in the settings for protected, secure connections. ISecWay cannot access your decrypted data traffic. You can also use ISecWay's gateway/proxy functionality to filter and inspect all traffic entering and leaving your devices for more granular access control.

If you need me to explain any part of ISecWay's security and privacy control features in more detail, please let me know! I'd be happy to provide you with more relevant information.

ISecWay利用端到端加密来保护设备之间的所有连接,确保您的数据在离开发送设备之前就已经被加密,只有在到达预期接收设备时才会被解密。在传输过程中,您的数据对任何第三方,包括ISecWay服务器在内,都是不可读的,从而最大程度上防止了数据泄露。

设备之间能否建立连接,是由网络管理员事先设置的访问控制列表(ACL)来决定的。默认情况下,任何连接尝试都会被拒绝,只有当ACL规则明确允许时,两台设备才能相互连接。用户仅能查看根据ACL规则被允许连接的设备,这种"网络图修剪"机制可以避免您看到不属于您所在网络的其他设备。

在可能的情况下,ISecWay会直接建立设备之间的点对点连接,而不经过服务器路由转发,从而进一步减少了数据暴露的风险。

## 如果我在工作设备上使用ISecWay,同事能看到我的个人设备吗?

ISecWay采用了完全独立的命名空间,将工作网络和个人网络隔离开来。您工作网络中的同事只能看到并连接到同属于该工作网络的其他设备,这受到ACL的限制。除非您明确共享,否则他们无法看到或访问您个人ISecWay网络中的任何个人设备。您的个人网络功能独立运作,对工作网络完全隐藏。

## 我该如何限制对我设备的访问?

作为最终用户,您可以在ISecWay设置中禁用局域网访问和关闭公网IP共享,从而限制进入您设备的连接。工作网络管理员则可以通过设置严格的ACL,只允许特定设备连接,来限制对您工作设备的访问。您可以与他们讨论您的访问控制要求。

无论如何,请确保在设置中启用端到端加密,以实现受保护的安全连接。ISecWay无法访问您解密后的数据流量。您还可以使用ISecWay的网关/代理功能,对进出您设备的所有流量进行过滤和检查,从而实现更精细化的访问控制。

如果您需要我详细解释ISecWay的安全和隐私控制功能的任何部分,欢迎随时告知,我很乐意为您提供更多相关信息。

As described in our blog post on how ISecWay works, the coordinator server is the centralized management component in the ISecWay architecture. It is responsible for distributing public keys, firewall rules, and other configurations to all ISecWay devices in your network. However, if the coordinator server goes down, most of your ISecWay network can still continue to function normally:

- ISecWay does not route any traffic through the coordinator server. Instead, it attempts to establish direct peer-to-peer connections between each pair of communicating devices. If a direct connection cannot be established, devices will forward traffic through multiple warpedge servers located in different regions around the world.

- Device keys are stored locally. As long as the keys haven't expired, devices can continue to communicate with each other. Note that the expiration time is based on when the device last authenticated with the coordinator server, so different devices may have different expiration times.

- Firewall rules are cached on each device and enforced by the devices themselves, meaning your current rules and access control lists will remain in effect.

On the other hand, with the coordinator server down, the following operations will not be possible:

- Adding new users and devices to the network.

- Refreshing and exchanging keys, which will gradually cause existing devices to lose access to each other.

- Updating firewall rules.

- Revoking keys for existing users.

In summary, coordinator server downtime will prevent new devices and users from joining the network and cause existing device connections to gradually fail after some time, but most existing rules and established connections will continue to function in the short term. Therefore, you would need to restore the coordinator server as soon as possible to avoid complete network dysfunction. Let me know if you need me to explain or illustrate any part in more detail.

正如我们在ISecWay工作原理的博客文章中所描述的,协调服务器是ISecWay架构中的集中管理组件。它负责向您网络中的所有ISecWay设备分发公钥、防火墙规则以及其他配置信息。然而,如果协调服务器发生宕机,您的ISecWay网络大部分功能仍然可以继续正常运行:

- ISecWay不会将任何流量路由经过协调服务器。相反,它会尽最大努力在每对正在通信的设备之间建立直接的点对点连接。如果无法建立直连,设备将通过分布于世界各地不同区域的多个WarpRelay服务器转发流量。

- 设备上的密钥信息是本地存储的。只要密钥没有过期,设备之间就可以继续互相通信。需要注意的是,密钥过期时间是根据设备上次与协调服务器认证的时间来确定的,因此不同设备的过期时间可能不尽相同。

- 防火墙规则会被缓存在每台设备上并由设备本身执行,这意味着您当前已有的规则和访问控制列表将继续生效。

另一方面,在协调服务器宕机的情况下,以下操作将无法进行:

- 无法向网络中添加新的用户和设备。

- 无法刷新和交换密钥,这将导致现有设备逐渐失去相互访问的权限。

- 无法更新和修改防火墙规则。

- 无法撤销现有用户的密钥。

总的来说,协调服务器宕机会阻止新设备和用户加入网络,并导致现有设备之间的连接在一段时间后逐渐失效,但大部分现有规则和已建立的连接在短期内仍可继续运行。因此,您需要尽快恢复协调服务器以避免网络功能完全瘫痪。如果您需要我详细解释或举例说明任何部分,欢迎随时告知。

The use of ISecWay typically begins with users experimenting with it for personal networks, remote access, and connectivity, subsequently applying the experience to solve similar problems in the work environment. However, as an enterprise scales, the demand for advanced integration, compliance, support, and access control increases. This article aims to explore the process of smoothly introducing ISecWay into the work environment and discuss the subtle differences in applying ISecWay across different scales of users and devices, ranging from a few to thousands.

## Deploying ISecWay in an Enterprise Environment

The deployment of ISecWay in the workplace is directly supported by integrating with your applications through OIDC.

### Steps to Start Using ISecWay:

- Download and install ISecWay on devices that need to join the ISecWay network (isecnet). ISecWay supports most operating systems, including Windows, Android, Linux, Mac, and iOS.
- Install ISecWay on resources that need to join isecnet, or use the subnet router functionality for quick, large-scale access of resources (if ISecWay cannot be directly installed).
- Edit the Access Control Lists (ACL) for users and devices.
- Apply ACL tags when adding servers, decoupling servers from personal identities, which is especially important if the server configurators leave the organization.

Compared to traditional company Network Tunneling, ISecWay provides mesh network capabilities, meaning its connections are peer-to-peer rather than through a central location's tunnel. ISecWay's mesh network functionality avoids creating speed bottlenecks compared to traditional Network Tunneling architectures.

### Limitations of Traditional Network Tunneling:

- Vulnerable to lateral attacks
- Performance bottlenecks
- Limited Single Sign-On/Multi-Factor Authentication integration
- Frequent re-authentication requirements
- Additional hops leading to higher latency
- IT support and maintenance needs
- Limited operating system support

### Advantages of ISecWay SASE:

- Device-level access control
- Reduced bottlenecks
- Authentication and users managed by Identity Providers (IdP)
- Peer-to-peer connections
- Lower latency
- Key and certificate management
- Extensive operating system support: Android, iOS, MacOS, Windows, Linux

With ISecWay, you can securely share private company resources with your team without exposing the resources to the public internet. For example, after installing ISecWay on an API server, your team can access that server from any location. You can also access the API server by tags such as "API server" rather than its ISecWay IP address.

# Key Features to Master When Introducing ISecWay

## Lock Feature

Prevent new potentially malicious nodes from joining your isecnet by requiring them to be signed by an already trusted node. When isecnet lock is enabled, new devices cannot be added to your isecnet even if the ISecWay infrastructure is attacked.

## ACL

Manage access permissions with ISecWay ACL policy files, allowing administrators to flexibly define access permissions for users, groups, and tags.

## ISecWay for Development and Production Environments

Teams need secure remote access to development and production environments, including databases, servers, devices, VMs, containers, internal applications, etc., to complete tasks efficiently. IT and security operations functions need to manage access to these environments and infrastructure quickly and securely.

## Aligning IT and Security Teams' Priorities

ISecWay helps align the priorities of IT and security teams by integrating connectivity and security. IT teams focus on connectivity (adding users and devices), while security teams focus on security (restricting the number and access permissions of users and devices). ISecWay facilitates collaborative work between these two teams, as the simplest way to add new users or devices to isecnet is also a very secure solution, providing identity recognition and explicit access control through ACLs. These teams do not have to promote their solutions separately but can jointly use ISecWay.

## ISecWay Compatibility with Nearly Any Tech Stack

Teams can use ISecWay seamlessly on their current tech stack.

# ISecWay's Security Features

ISecWay utilizes the Noise Protocol Framework® to implement end-to-end encrypted connections. The Noise Protocol Framework is a SASE designed for usability, performance, and security, providing end-to-end encrypted connections between devices using cutting-edge encryption technology. The protocols of the Noise Protocol Framework have been reviewed by cryptographers, and its code has been audited, identifying and fixing a few issues.

# Key Security Features of ISecWay

## Single Sign-On and Multi-Factor Authentication

ISecWay relies on your existing identity provider for user authentication and automatically adopts authentication settings such as MFA.

## Access Control Lists

ACLs allow you to define which users can connect to which devices in the network.

## End-to-End Encryption

ISecWay is built on the Noise Protocol Framework that provides end-to-end encryption between devices. ISecWay only handles your metadata, not the data itself.

## SOC 2

ISecWay has implemented procedures and policies in compliance with AICPA Trust Services Criteria.

## Latacora Security Audit

ISecWay has partnered with the information security company Latacora for a security audit.

## Security Bulletins

ISecWay publishes security bulletins to publicly disclose security issues in the product.

# Learn More

Please visit our [website](https://isecway.com) and check the ISecWay security page for more details.

ISecWay的使用通常始于用户在个人网络、远程访问和连接方面进行初步尝试，随后在工作环境中应用解决相似问题的经验。然而，随着企业规模扩大，对高级集成、合规性、支持和访问控制的需求随之增加。本文旨在探索将ISecWay顺利引入工作环境的过程，并讨论在不同规模用户和设备上应用ISecWay时的微妙差别，范围从几个到数千个。

## 在企业环境中部署ISecWay

工作场所中ISecWay的部署，ISecWay直接支持通过OIDC与你的应用程序集成。

### 开始使用ISecWay的步骤：

- 在需要加入ISecWay网络（isecnet）的设备上下载并安装ISecWay。ISecWay支持大多数操作系统，包括Windows、Android、Linux、Mac和iOS。
- 在需要加入isecnet的资源上安装ISecWay，或者使用子网路由器功能实现资源的快速大规模接入（如果无法直接安装ISecWay）。
- 编辑用户和设备的访问控制列表（ACL）。
- 在添加服务器时应用ACL标签，通过此方式可以将服务器与个人身份解耦，若服务器配置人员离开组织，该措施显得尤为重要。

与传统公司网络隧道相比，ISecWay提供了网状网络能力，意味着其连接是点对点的，而非通过中心位置的隧道传输。与传统网络隧道架构相比，ISecWay的网状网络功能避免了创建速度瓶颈。

### 传统网络隧道的限制：

- 易受横向攻击
- 性能瓶颈
- 受限的单点登录/多因素认证集成
- 频繁的重新认证需求
- 额外的跳转导致更高延迟
- IT支持和维护需求
- 有限的操作系统支持

### ISecWay SASE的优势：

- 设备级访问控制
- 减少瓶颈
- 由身份提供商(IdP)管理的身份验证和用户
- 点对点连接
- 更低的延迟
- 密钥和证书管理
- 广泛的操作系统支持：Android、iOS、MacOS、Windows、Linux

通过ISecWay，您可以安全地与团队共享私有公司资源，无需将资源暴露于公网。例如，在API服务器上安装ISecWay后，您的团队可以从任何位置访问该服务器。您还可以通过“API服务器”等标签访问API服务器，而非其ISecWay IP地址。

# 引入ISecWay时需掌握的关键功能

## 锁功能

通过先由已信任节点签名，阻止新的潜在恶意节点加入您的isecnet。当启用isecnet锁定时，即便ISecWay基础设施受到攻击，也无法向您的isecnet中添加新设备。


## ACL

通过ISecWay ACL策略文件管理访问权限，允许管理员以灵活方式定义用户、组和标签的访问权限。

## 适用于开发和生产环境的ISecWay

团队需要安全地远程访问开发环境和生产环境，包括数据库、服务器、设备、VM、容器、内部应用程序等，以高效完成任务。IT和安全运营功能需要快速、安全地管理对这些环境和基础设施的访问权限。

## 调整IT和安全团队的优先事项

ISecWay通过整合连接性和安全性，帮助调整IT和安全团队的优先事项。IT团队关注连接性（增加用户和设备），而安全团队关注安全性（限制用户和设备的数量及其访问权限）。ISecWay促进

了这两个团队的协同工作，因为向isecnet添加新用户或设备的最简单方法也是非常安全的方案，提供了身份识别和通过ACLs的明确访问控制等。这两个团队不必各自推广他们的解决方案，而可以共同使用ISecWay。

## 与几乎任何技术堆栈兼容的ISecWay

团队可以在其当前的技术堆栈上无缝使用ISecWay。

# ISecWay的安全特性

ISecWay利用Noise Protocol Framework®实现端到端加密连接。Noise Protocol Framework是为可用性、性能和安全性设计的SASE，采用前沿加密技术，在设备之间提供端到端加密连接。Noise Protocol Framework的协议经过密码学家审查，其代码也经过审计，发现并修复了少量问题。

# ISecWay的关键安全功能

## 单点登录和多因素认证

ISecWay依赖您现有的身份提供商进行用户验证，并自动采用MFA等身份验证设置。

## 访问控制列表

ACL使您能够定义哪些用户可以连接到网络中的哪些设备。

## 端到端加密

ISecWay建立在提供设备间端到端加密的Noise Protocol Framework之上。ISecWay仅处理您的元数据，而非数据本身。

## SOC 2

ISecWay已实施符合AICPA信任服务标准的程序和政策。

## Latacora安全审计

ISecWay与专注于信息安全的公司Latacora合作进行安全审计。

## 安全公告

ISecWay发布安全公告，以公开产品中的安全问题。

# 了解更多信息

请访问我们的[网站](https://isecway.com)，查看ISecWay安全页面以获取更多细节。


eye.svg

In the era of prevalent hybrid work models, enhancing digital security has become a top priority. Identity and Access Management (IAM) is a set of policies and practices aimed at helping secure an organization's resources and information security. This article aims to explore the benefits of adopting IAM, as well as some best practices in implementing IAM.

Identity refers to the unique identifier of entities such as users, applications, services, or devices in an online environment. This identity can be expressed in various ways, such as social media accounts, work emails, personal emails, or usernames. The authentication process aims to confirm whether the identity of the entity attempting to access resources matches the identity recorded in the database. This usually involves one or more of the following authentication factors:

- Knowledge factors: Verification using information known to the user, such as passwords, PINs, answers to security questions, and passphrases.
- Possession factors: Verification using devices previously registered by the user, such as smartphones or hardware keys.
- Biometric factors: Verification using biometric information, such as fingerprints or voices.

Once the identity is verified by the identity management system, access management ensures that users can only access the resources they are authorized to. For example, an employee may only need access to basic human resources platforms, while an administrator may require additional permissions. The task of access management is to determine appropriate access rights, using identity information to verify whether users are entitled to access specific resources.

IAM controls access rights through tools such as user roles and security policies. For example, employees can be assigned the "Employee" role to gain basic access rights, while administrators may be granted the "HRAdmin" role, enjoying more privileges. Security policies can set restrictions, such as allowing access only during work hours or from registered devices.

With organizations increasingly managing digital infrastructures and implementing remote work, the importance of IAM is growing. Stolen credentials are a major attack vector. Weak policies provide opportunities for criminals to exploit stolen identities, manipulate or leak data. Reports indicate that incidents involving stolen credentials take an average of over 200 days to be discovered.

Key functions of IAM help address security needs, including:

- Password management to ensure strong and unique passwords.
- Secure authorization access for APIs and microservices.
- Single sign-on to simplify access across systems with a single identity.
- Adaptive authentication to grant access based on context.
- Role-based access control to assign resource access rights.
- Automatically revoking access rights when employees leave.

Adopting best practices such as multi-factor authentication, zero trust models, privileged access management, the principle of least privilege, logging, and automation helps strengthen IAM security.

IAM is crucial for secure and convenient access to resources. As cyber attacks continue to rise, reinforcing IAM becomes particularly critical. Combining the use of VPNs and identity providers, like iSecWay, can further enhance security. iSecWay ensures that only authorized devices and users can access resources.

I have focused on streamlining wording, removing redundant content, and improving the text's fluency and organizational structure.

FAQs

Here are some common questions about IAM and their answers.

What is "identity" in Identity and Access Management?

Identity refers to the unique digital identifier of users, applications, services, or devices. Authentication is the process of verifying the identity of an entity attempting to access resources by matching the provided credentials with records from a trusted authorization authority.

What components does IAM include?

IAM mainly includes two components:

1. Identity management: Verifying identity through the authentication process, i.e., confirming if a user is who they claim to be. This involves comparing the provided credentials with an identity database.
2. Access management: Authorizing access by determining if the verified user has the right to access the requested resources or data. This is based on policies and user roles.

What are the advantages of IAM?

The main advantages of IAM include:

- Enhancing user experience through features like single sign-on.
- Simplifying password management through password policies and tools.
- Improving security posture through measures like implementing multi-factor authentication.
- Automating management of user access.
- Increasing visibility and control over user data and activities.

身份和访问管理

在当前Hybrid工作模式盛行的时代，加强数字安全保护已经成为首要任务。身份和访问管理（IAM）是一套策略和实践，旨在帮助保护组织的资源和信息安全。本文旨在探讨采用IAM所带来的好处，以及实现IAM过程中的一些最佳实践。

身份是指用户、应用、服务或设备等实体在在线环境中的唯一标识。这种身份可以通过多种方式表达，如社交媒体账号、工作邮箱、个人邮箱或用户名等。认证过程旨在确认尝试访问资源的实体的身份是否与数据库中已记录的身份相匹配。这通常涉及以下一个或多个验证要素：

- 知识要素：利用用户已知的信息进行验证，例如密码、PIN码、安全问题答案和口令。
- 持有要素：验证用户拥有的事先注册的设备，如智能手机或硬件密钥。
- 生物特征要素：利用生物识别信息，如指纹或声音，进行验证。

一旦身份得到身份管理系统的验证，访问管理便确保用户仅能够访问他们被授权的资源。举例来说，一名员工可能只需要访问基本的人力资源平台，而管理员则需要额外的权限。访问管理的任务是确定适当的访问权限，它利用身份信息来核查用户是否有权访问特定资源。

IAM通过提供如用户角色和安全策略等工具来控制访问权限。例如，员工可以被分配为“员工”角色，以获得基本访问权限，而管理员则可能被授予“HRAdmin”角色，享有更多权限。安全策略可以设定限制，如仅允许在工作时间或从已注册的设备上访问特定角色。

随着组织越来越多地管理数字基础设施和实施远程工作，IAM的重要性日益增加。被窃取的凭证是主要的攻击途径。薄弱的策略为犯罪分子利用被盗身份、操纵或泄露数据提供了机会。据报告显示，涉及被盗凭证的违规事件平均需要超过200天才能被发现。

IAM的关键功能有助于解决安全需求，包括：

- 密码管理，以确保强大且独一无二的密码。
- API和微服务的安全授权访问。
- 单点登录，通过跨系统的单一身份简化访问。
- 自适应认证，在考虑上下文的基础上授予访问权限。
- 基于角色的访问控制，以分配资源访问权限。
- 在员工离职时自动撤销访问权限。

采用多重认证、零信任模型、特权访问管理、最小权限原则、日志记录和自动化等最佳实践，有助于加强IAM的安全性。

IAM对于安全且便捷的资源访问至关重要。随着网络攻击的不断增加，强化IAM变得尤为关键。结合使用VPN和身份提供商，如iSecWay，可以进一步提高安全性。iSecWay确保只有授权的设备和用户才能访问资源。

我已经专注于精简措辞，删除重复内容，并改进了文本的流畅性和组织结构。

常见问题解答

以下是一些关于IAM的常见问题及其解答。

什么是身份和访问管理中的“身份”？

身份是指用户、应用、服务或设备的唯一数字标识。认证是通过与可信授权机构的记录匹配提供的凭据来验证尝试访问资源的实体的身份。

IAM包括哪些组成部分？

IAM主要包括两个组成部分：

1. 身份管理：通过认证过程验证身份，即确认用户是否为其所声称的那个人。这涉及将提供的凭据与身份数据库进行比对。
2. 访问管理：授权访问，通过确定已验证的用户是否有权访问所请求的资源或数据。这是根据策略和用户角色来进行的。

IAM的优势有哪些？

IAM的主要优势包括：

- 通过单点登录等功能提升用户体验。
- 通过密码策略和工具简化密码管理。
- 通过实施多重认证等措施改善安全状况。
- 实现用户访问的自动化管理。
- 提高对用户数据和活动的可见性及控制力。

logo.svg

thumbnail_1709789487565.jpg

1709789487565.jpg

作为一家拥有多个数据中心的金融公司,我们需要一个安全可靠的方式在不同站点之间传输敏感数据。过去,我们曾尝试使用MPLS和网络隧道等传统解决方案,但它们既昂贵又复杂,而且难以扩展。直到我们发现了iSecWay,情况才发生了改变。

通过iSecWay,我们可以轻松建立多个数据中心之间的点到点连接。我们只需将iSecWay节点部署到每个数据中心,它们就能自动建立安全的专用通道进行数据传输。整个过程简单到令人难以置信,不需要任何复杂的配置,只需几次点击。

所有数据传输均受到iSecWay的端到端加密保护,确保安全性。即使发生网络入侵,黑客也无法解密或窃取数据。同时,iSecWay采用了业界顶尖的加密算法,确保了极高的加密性能,不会因网络延迟而影响关键应用的运行。

借助iSecWay的这种轻量级站点互联架构,我们还可以轻松添加新的数据中心或云环境,无需担心网络拓扑变复杂。无论网络规模如何增长,部署和管理都同样简单。这为我们未来的扩展留有充足空间。

最棒的是,作为一款纯软件解决方案,iSecWay的部署和运营成本要比传统硬件方案低得多。我们无需购买专用网关或路由器,只需简单地订阅服务。这项投资回报率极高,因为iSecWay可以妥善保护我们的关键数据资产。

总的来说,iSecWay为我们提供了一种前所未有的简单、安全、高效且经济实惠的方式,将多个数据中心串联起来。它完美满足了我们对站点互联的所有需求,成为了我们数字化转型过程中的重要一环。如果您也在寻找类似的解决方案,一定要考虑iSecWay。

As a financial company with multiple data centers, we needed a secure and reliable way to transfer sensitive data across different sites. Previously, we had tried traditional solutions like MPLS and Network Tunneling, but they were expensive, complex, and difficult to scale. Everything changed when we discovered iSecWay.  

With iSecWay, we could easily establish point-to-point connections between our data centers. We just needed to deploy iSecWay nodes at each data center location, and they would automatically establish secure dedicated tunnels for data transmission. The entire process was incredibly simple, requiring no complex configurations – just a few clicks.

All data transmissions were protected by iSecWay's end-to-end encryption, ensuring security. Even in the event of a network breach, hackers would be unable to decrypt or intercept the data. At the same time, iSecWay utilized industry-leading encryption algorithms to ensure top-notch encryption performance without impacting mission-critical applications due to network latency.

With this lightweight site-to-site interconnection architecture from iSecWay, we could also effortlessly add new data centers or cloud environments without worrying about increased network topology complexity. No matter how much the network scaled, deployment and management remained just as simple, leaving ample room for future expansion.

Best of all, as a pure software solution, iSecWay's deployment and operational costs were significantly lower than traditional hardware-based approaches. We didn't need to purchase dedicated gateways or routers; we only needed to subscribe to the service. This investment provided an outstanding return since iSecWay could properly safeguard our critical data assets.

Overall, iSecWay provided us with an unprecedentedly simple, secure, efficient, and cost-effective way to interconnect our multiple data centers. It perfectly met all our site-to-site interconnection needs and became an essential part of our digital transformation journey. If you're also looking for a similar solution, iSecWay is definitely worth considering.  

赵景行