Windows 10 gre tunnel

Уже месяц прошел с того момента, как была анонсирована Windows 10 Technical Preview и как был представлен Windows Server Technical Preview. Для того, чтобы увидеть произошедшие изменения, даже не нужно глубоко копаться в системах – интерфейс уже другой – вернулась кнопка пуск, нет стартового меню… На самом деле, в нашем блоге уже рассказывали об изменениях и в Windows 10, и в Windows Server Technical Preview, и даже в System Center. Я же сегодня хочу рассказать о тех изменениях, которые ожидают нас в работе с сетью. К сожалению, не все обещанные возможности можно проверить на работоспособность в технической версии – но на то это и Technical Preview. Заинтересовавшихся жду под катом.

Изменения и дополнения, которые появились в Windows Server Technical Preview и касаются работы с сетью, касаются следующих компонентов сервера:

1. DHCP
2. DNS
3. GRE Tunneling
4. IPAM
5. Network Controller

Официальные источники (читай: блоги разработчиков и форумы) сообщают, что в Windows Server Technical Preview не работают новые возможности IPAM, а также нельзя полностью настроить и протестировать Network Controller. Зато об изменениях в работе DHCP, DNS и VPN туннелей можно не просто почитать, но еще и самостоятельно с этими службами поэкспериментировать (эксперименты лучше ставить в тестовой среде). Давайте посмотрим на все изменения по порядку.

1 DHCP

В новой версии сервера DHCP больше не поддерживает Network Access Protection (NAP). Поддержка NAP была реализована в Windows XP Service Pack 3, Windows Vista и Windows Server 2008, но уже в Windows Server 2012 R2 эта функция была отнесена к устаревшим, и вот в Windows Server Technical Preview удалена уже насовсем. Изменения мы можем увидеть в Group Policy Management:

Теперь, DHCP сервер не будет применять политики NAP, а защита доступа к сети для DHCP зон будет выключена. Как же будет происходить взаимодействие с другими версиями, которые NAP поддерживают? DHCP-клиент, поддерживающий NAP, будет отправлять сведения о состоянии работоспособности (Statement of Health, SoH). Если DHCP сервер будет запущен на сервере под управлением Windows Server Technical Preview, то эти запросы будут обрабатываться так, как будто сведений о состоянии работоспособности нет и в этом случае будет предоставляться нормальная аренда DHCP. Кроме того, Windows Server Technical Preview может быть установлен на сервер, выполняющий роль RADIUS прокси и перенаправляющий запросы об аутентификации на сервер политики сети (Network Policy Server, NPS). Если сервер политики сети будет поддерживать NAP, то в этом случае NAP-клиенты будут считаться NAP несовместимыми.

2 DNS

Изменения в работе DNS касаются как клиентской, так и серверной части. Изменения, касающиеся клиентской службы DNS, которые были заявлены в Windows 10 Technical Preview, также актуальны и для компьютеров с установленной Windows Server Technical Preview.
Что же изменилось в серверной части DNS? Тут нововведения делятся на две группы. Первая часть коснулась журнала событий и диагностики. Более того, с этими изменениями можно познакомиться и в Windows Server 2012 R2, если перед этим установить соответствующий hotfix. Но в Windows Server Technical Preview все возможности доступны без каких-либо дополнительных установок.

Для DNS сервера расширена функциональность записи событий в журнал событий и диагностики, а именно включены события аудита и аналитики. Для того, чтобы эту функциональность включить, необходимо открыть Event Viewer, в ней перейти в Application and Services Logs\Microsoft\Windows\DNS—Server. Щёлкнув правой кнопкой мышки по DNS-Server, выберите View, а затем Show Analytic and Debug Logs. В результате будут отображен лог Analytical; щелкнув по нему, выбираем свойства. В появившемся окне необходимо выбрать пункт Do not overwrite events (Clear logs manually) в пункте When maximum event log size is reached, выбрать чекбокс Enable logging и нажать ОК.

В чем интересные особенности этого решения. Во-первых, расширение возможностей ведения журнала событий и диагностики мало сказываются на производительности, уменьшая нагрузку на сервер. Во-вторых, логи DNS совместимы с клиентскими приложениями ETW (logman, tracelog, message analyzer). Используя эти приложения, вы можете получать, например, трейсы всех аналитических и аудит-событий, и анализировать уже собранные логи с помощью журнала событий и диагностики
Ко второму глобальному нововведению в DNS сервере можно отнести новую функцию, получившую название «DNS политики» (DNS Policies). C помощью DNS политик у системного администратора появляется возможность сконфигурировать DNS сервера так, чтобы можно было контролировать ответы на DNS запросы. Ответы могут быть основаны на общем IP адресе DNS клиента, времени суток, и нескольких других параметрах. Кроме того, политики DNS позволяют определять местоположение DNS, управлять траффиком, балансировать нагрузки, а также обещают реализовывать некоторые другие сценарии. Однако более конкретной информации пока нет; надеемся, что она появится ближе к финальной версии.

3 GRE Tunneling

В Windows Server Technical Preview представлено дополнение, которое позволяет использовать возможности протокола GRE (Generic Routing Encapsulation) для Windows Server Gateway. Теперь GRE можно использовать в интерфейсе S2S (site-to-site). Данный интерфейс используется для установки соединения между вашей локальной и виртуальной сетью. В предыдущих версиях, при создании соединения S2S можно было установить безопасное соединение. Не всегда это решение было самым удобным – необходимость создания отдельных туннелей для подсетей, невозможность создания маршрутизируемых интерфейсов, и т.д.
Использование протокола GRE позволяет эти проблемы решить. С одной стороны, GRE менее безопасен, но его можно использовать совместно с защищенным протоколом. С другой стороны, при использовании GRE туннеля, вы не ограничены типом трафика, который может быть по туннелю передан. Также GRE позволяет маршрутизировать несколько сетей, не требуя при этом создавать несколько туннелей.
Для GRE протокола были дополнены командлеты Windows PowerShell, работающие с протоколом S2S (Add-VpnS2SInterface, Set-VpnS2SInterface и Get-VpnS2SInterface. Далее приведу примеры использования этих командлетов.

Шлюз на стороне облака

Создание нового туннеля

Add-VpnS2SInterface –Name GreCloudToEnt1 –Destination <Destination IP> -IPv4Subnet “10.1.1.0/24:1000” –GRETunnel –GREKey “12345” –SourceIP: <public interface IP> -RoutingDomain Rd1

Изменение существующего туннеля

Get-VpnS2SInterface –Name GreCloudToEnt1 | Set-VpnS2SInterface –EnableQos Disabled –GRETunnel –RoutingDomain Rd1

Удаление GRE туннеля

Get-VpnS2SInterface –Name GreCloudToEnt1 | Set-VpnS2SInterface –AdminStatus $false – GRETunnel –RoutingDomain Rd1

Шлюз на стороне предприятия

Создание нового туннеля

Add-VpnS2SInterface –Name GreEnt1ToCloud –Destination <Destination IP> -IPv4Subnet “10.1.2.0/24:1000” –GRETunnel –GREKey “12345” –SourceIP: <Enterprise_IP>

Изменение существующего туннеля

Get-VpnS2SInterface –Name GreEnt1ToCloud | Set-VpnS2SInterface –EnableQos Disabled – GRETunnel

Удаление GRE туннеля

Get-VpnS2SInterface –Name GreEnt1ToCloud | Set-VpnS2SInterface –AdminStatus $false -GRETunnel

Вот тут конкретика более или менее заканчивается. К сожалению, возможности IPAM и новой роли Network Controller пока не протестируешь. Превращать этот пост в еще больший обзор я не хочу, поэтому очень поверхностную информацию про IPAM и Network Controller я спрячу под спойлеры ниже – кому интересно, посмотрите:

Что ж, надеюсь, что вы нашли в этой статье для себя что-то полезное. Я продолжаю ждать новой информации о Windows Server Technical Preview (хочется уже конкретики и, желательно, целиком и полностью, работающей) и желаю вам удачных экспериментов, в которых вам помогут уже имеющиеся материалы на Хабре:

1. Первый взгляд на Windows Server Technical Preview
2. Как попробовать новый Windows Server Technical Preview без установки
3. Первый взгляд на System Center Virtual Machine Manager Technical Preview

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

• Попробовать Azure бесплатно на 30 дней!
  • Центр разработки Microsoft Azure (azurehub.ru) – сценарии, руководства, примеры, рекомендации по разработке
  • Twitter.com/windowsazure_ru — последние новости Microsoft Azure
  • Сообществе Microsoft Azure на Facebook – эксперты, вопросы

• Изучить курсы виртуальной академии Microsoft по облачным и другим технологиям
  • Бизнес и облако: лучшие практики решений
  • Windows 8.1 Update для крупных организаций. Начало работы
  • Гибридное облако Microsoft: Руководство по типовым решениям
  • Набор средств для подготовки пользователей к Windows 8.1
  • Введение в графическую библиотеку Win2D

• Загрузить бесплатную или пробную Visual Studio
• Стать разработчиком универсальных приложений Windows

This guide assumes somewhat advanced networking knowledge and at-least some knowledge in Linux and Windows servers. This is not the recommended method for setting up tunnels / GRE on Windows. See instead our .exe based single application system that does not require virtualization.

Requirements:

• This can be run on a KVM virtualized Windows installation, although it is recommended that it is performed on a Physical Dedicated Server in production.
• At least 512MB RAM, at-least 150MB ram should be free to run the Virtual Machine.
• A Windows Server with at-least 2 public IP Addresses (NAT + DMZ can be used but is not covered in this tutorial).
• Virtualization software is installed (VMWare or VirtualBox recommended).
• A SSH client (e.g PuTTY) installed

Warning

This guide involves network changes, it should not be performed on a production server. Any changes made are at your own risk. We (X4B and its associates) are not liable for any damage that results due to correct or incorrect following of this guide.

While every intention has been made to ensure this guide is accurate, every system and network configuration is different. These changes should be made by a networking professional. We also recommend that a KVM or physical access is available for recovery.

Part 1: Virtual Machine Setup

You may either use the appliance generated by us, or build your own.

Appliance

Download (OVF):

Root Login: root
Root Password: weakpassword

Change the root password (with passwd command) as soon as you log in.

Build the Virtual Machine yourself

Requirements:
This guide assumes you have an installed copy of Virtual Machine software (VMWare or VirtualBox recommended).

Step 1: Download Operating System

Download the latest copy of Debian. For the appliance we have used Debian Wheezy.

Step 2: Install Operating System

Create a Virtual Machine. We recommend allocating at-least 128MB of ram for the virtualized system, the appliance is optimized for less and at a later date you can do the same with your image.

Complete the setup, use reasonable settings. Install the minimum packages necessary. A desktop environment will require significantly more resources and is NOT recommended.

Step 4: Update and do Upgrades

Login to your virtual machine using SSH or via the virtual screen.

Upgrade your system with:

apt-get update
apt-get upgrade

Step 3: Install a new Kernel

A newer kernel version is required due to routing bugs in the version provided.

Edit /etc/apt/sources.list, add:

deb http://ftp.us.debian.org/debian/ wheezy-backports main

Update Repository information, execute:

apt-get update

Install kernel 3.12, execute:

apt-get install linux-image-3.12-0.bpo.1-amd64 -t wheezy-backports

Part 2: Tunnel Setup

This guide assumes that you have already configured your tunnel on the X4B interface and that you have the necessary ports configured for your service. We recommend for testing purposes that you have a HTTP server running on your Windows machine (such as XAMPP)

Step 1: Log In

If you have not done so already, log in to your Virtual Machine.

Step 2: Edit Script

Edit the tunnel script to enable Windows GRE mode.

WINDOWS_VM_GRE_ENABLED=1

Get the IP address of the windows side of the Host Only Network.

In Network > Network Adapters right click on [NETWORK ADAPTER] and goto Status. On the Status page click the Details button. The IP Address is the IPv4 Address field.

Картинка с сайта: www.x4b.net

Set the Windows Host Only Network IP Address in the script.

WINDOWS_VM_GRE_WINGATEWAY="192.168.245.1"

Step 3: Upload Tunnel Script

Upload your tunnel script. This can be done via SFTP or by pasting it into a server text editor such as nano.

nano /etc/tunnel.sh

Make the script executable:

chmod +x /etc/tunnel.sh

Step 4: Test

Run the script.

bash /etc/tunnel.sh

Test that the tunnel is online by pinging the gateway IP. If pingable, proceed. Else proceed to troubleshooting.

Step 5: Run on boot

In /etc/rc.local before exit 0 add:

/etc/tunnel.sh

The tunnel will now be created on boot.

Part 3: Windows Setup

• Default Gateway
• Interface Metric (high)

How this works

For an overview of the process, see Figure 1. More in-depth details are available in the later figures.

Figure 1: Network Overview

Картинка с сайта: www.x4b.net

Process:

1. Connecting Client sends packet to Filtered IP Address. The filtering server marks this packet as clean and to be passed on to the backend server.
2. The filtering server encapsulates the packet in GRE and sends it to the Backend Server’s (Customer Server) Linux VM assigned IP. This is the IP assigned to the bridged interface.
3. The Linux VM de-encapsulates the payload from the GRE packet.
4. The packet is delivered at the Windows Host Machine via the Host-Only Network. The packet is addressed to the Windows Host-Only address (i.e. 192.168.56.1) and any process listening on that port can reply.

Note:
In this diagram the Windows VM has a network address of 1.1.1.1 that is not used for filtering, this is intentional and to allow for continued access to services such as RDP.

Figure 2: Client Packet Rewrite Process (Filter -> Backend)

Картинка с сайта: www.x4b.net

Process:

1. The IP packet from the public client is received at the filtering location. It is accepted as clean traffic to be forwarded to the backend.
2. The destination address of the packet is re-written so that it will be sent over the GRE tunnel between the Filtered Service and the Backend Linux Virtual Machine.
3. The IP packet is encapsulated (in GRE) and sent to the Linux Virtual Machine
4. The Linux Virtual Machine receives the GRE packet and de-encapsulates it.
5. The Destination Address of the IP packet is re-written to reflect the address of the Windows PC on the Host-Only-Network that this packet will be delivered to. The packet is then hence delivered to the Windows PC, via the Host-Only-Network adapter.

Figure 3: Client Packet Reverse Rewrite Process (Backend -> Filter)

Картинка с сайта: www.x4b.net

Process:

1. A packet is sent from the Windows Virtual Machine addressed to an address on the internet over the Host-Only-Network. This may be a response to an incoming packet from the client or a new connection made via the Tunnel (e.g a game server registering itself with a service like Steam).
2. The packet is received by the Linux Virtual Machine. The source address is re-written to match a packet that is being sent on the GRE tunnel, originating from the VM endpoint itself.
3. The encapsulated packet is sent to the filtered IP.
4. The encapsulated packet is received at the filtering server and de-encapsulated.
5. The packet is Source address is re-written to reflect a packet originating from the filter itself.
6. The packet is then delivered to the intended destination (such as the connecting client or internet server).

Figure 4: Reverse Path Routing Table

Картинка с сайта: www.x4b.net

The routing table ensures that all traffic originates from the windows Host-Only-Network adapter is sent over the GRE tunnel. Without this traffic would be sent over the default route and rejected at upstream routers.

1. Background

One time, a frontline reporter reported that when a user logged into the VPN on the cloud desktop, a connection error occurred and an error was reported: The computer and VPN server were not configured to allow Basic Routing (GRE) protocol packets to pass through.

Картинка с сайта: programmersought.com

2. Debugging process

1. GRE (Generic Routing Encapsulation): Generic Routing Encapsulation Protocol (GRE) is a commonly used tunnel mechanism protocol. It uses IP as the transmission protocol. This tunnel provides the transmission of certain protocol data in another protocol. Packaging mechanism. For example: encapsulating datagrams of certain network layer protocols (such as IP and IPX) so that these encapsulated datagrams can be transmitted in another network layer protocol (such as IP). The protocol being carried is calledPassenger Agreement, GRE can be used to carry different passenger protocols. A tunnel appears as a virtual point-to-point link (PPTP) with two endpoints, each identified by a tunnel source address and a tunnel destination address. GRE is the third layer tunnel protocol of VPN (Virtual Private Network) and is not encrypted during transmission.

The following figure shows the encapsulation process of a GRE packet as it traverses the router and enters the tunnel interface:

Картинка с сайта: programmersought.com

2. Configure GRE tunnel on network equipment

Configuring a GRE tunnel involves creating a tunnel interface, which is a logical interface. The tunnel endpoint must then also be configured for the tunnel interface. The following figure is an example of configuring a simple GRE tunnel:

Картинка с сайта: programmersought.com

In the picture above, both tunnel interfaces are part of the 172.16.1.0/24 network.

1) The first step is to create our tunnel interfaces on R1 and R2:

Since GRE is an encapsulation protocol, we adjust the maximum transmission unit (mtu) to 1400 bytes and the maximum segment size (mss) to 1360 bytes. Because most transfer MTUs are 1500 bytes, and we have added overhead because of GRE, we have to reduce the MTU to account for the additional overhead. Setting 1400 is a common practice to ensure that unnecessary packet fragmentation is kept to a minimum.

Once configured, the two tunnel endpoints can see each other and authenticate using icmp echo from one end.

2) Configure the other party’s routing information:

Workstations on either network still cannot reach the other end unless routing is configured on each router. Here we will configure static routes on both routers.

R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.1.2

R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.1.1

This way, both networks (192.168.1.0/24 and 192.168.2.0/24) can communicate freely with each other through the GRE tunnel.

3. IP filter (filter packet) inspection

IP routing is enabled on the public network interface. If no IP filter is configured, any communication accepted on the interface will be routed, which may cause unnecessary external communication to be forwarded to the internal network and cause security issues. For a PPTP-based VPN, all communications other than PPTP should be restricted. This requires configuring a PPTP-based inbound and outbound filter on the public network interface to ensure that only PPTP communications pass through the interface.

There are a total of 3 inbound filters for PPTP communication; there are also 3 outbound filters, and the source and destination are exactly reversed. PPTP filters are only secure if all filters are set correctly. The configuration example is as follows:

Картинка с сайта: programmersought.com

PPTP uses TCP port number1723asConnect control channel, the IP identification number is 47 asdata channel, PPTP requires tcp port 1723 and GRE to complete the work together, both are indispensable. Setting the port to 0 means any channel.
4. win10 client VPN configuration

The VPN configuration in Windows 10 is as follows:

Картинка с сайта: programmersought.com

Картинка с сайта: programmersought.com

Картинка с сайта: programmersought.com

Verify the desktop network to the VPN-server network:
Telnet vpnserver_ip 1723, the test is normal.

Модераторы: Trinity admin`s, Free-lance moderator`s