Tale of how we supported the domestic manufacturer

If you suffer for a long time - something will turn out!
(c) folk wisdom

It is time for fascinating stories,%% username!
')
At once I will make a reservation that the story described below never happened. All matches are random, all characters are fictional.

Due to our professional activities, we have to work with different telecom operators. Almost all of them are at the federal level, or their subsidiaries in the CIS countries. One of these companies is ... Let it be Z.
The history of relations with him is long-standing and colleagues will probably tell a lot of interesting things. But this somehow later, but for now I will tell my story.
The security requirements of this company are serious - the provision obliges (And another 152-FZ "On the protection of personal data"). And if earlier the requirements were draconian (in the spirit of “Mission Impossible”: an isolated room, a retina scanner, submachine gunners ...), now they are simply strict: individual records and encrypted communication channels between us and the customer. Encryption - GOST, no bourgeois overseas IPSec. The market for such solutions is small, suppliers - once or twice and ran out. The implementation ... well, not Checkpoint and not Cisco, but tolerable.

But it was a saying, but for a fairy tale I ask for the cut!

1. Do you remember how it all began?

The partner’s secure network is built on the basis of the ViPNet solution from a domestic manufacturer, Infotex. Until recently, individual ViPNet client clients were used with named keys. However, we have a lot of employees, but only ten keys, the partner does not give them anymore. Somehow coped, but it was terribly inconvenient, so we decided to install a dedicated gateway.

After negotiations with the manager of Infotex and the partner’s experts, we stopped at the ViPNet Coordinator HW1000 PAK based on the Aquarius server. The import substitution is Inside this PACK - the usual debian-based Linux with its own shell (you can go to bash) and the installed software ViPNet Coordinator (the test version can be downloaded as a package).

Since Since the market for such solutions is extremely small, standardization does not smell there. You have to buy a piece of iron from the same manufacturer as your partner, otherwise it will not work. Hence, the level of service - no NBD to you (although the cost of support is far from a penny), although the support responds fairly quickly, it is worth noting what, sometimes, you cannot say about the managers.

The first “discovery” after receiving the equipment was that the management software requires a 16-bit MS-DOS subsystem for its work (!). Given that there are two programs (“Network Control Center” and “Verification and Key Centers”), they use shared folders (although the documentation describes their separation into different workstations), the installation of a virtual machine with Win2003 x32 was the least hemorrhoid variant. 2015 year speak? x86-64? No, not heard. The version of the software supporting 64-bit OS is currently undergoing certification by the authorities - was the answer of the support.

The user manual is detailed and multi-page, and the description of the ready-made schemes takes up a dozen and a half pages and consists of half of the drawings. If it were not for the help of colleagues who have already launched similar PAK (Sasha, thank you!), Then the process of setting up and mastering the documentation would be delayed, I think, for a month or two. Infotex itself strongly recommends taking five-day courses (of course, paid, but relatively cheap), or use the services of an integrator. But we are not looking for easy ways, right? :) By the way, I sent a short instruction for support, nevertheless, to me.

2. Let's go!

It all starts with the installation of the administrator's software: the Network Management Center (NOC), the Verification and Key Center (UCC) and ViPNet Client, with which we will check our channel. To work will require a license (comes with PAK). We are not running the client yet, we still need to make keys for it. The license file is copied to C: \ Program files \ InfoTecs \ {NCC, KC}. We rebuy.

Run the NOC.

NOC interface

We accept the default settings. Open Services -> Address Administration -> ViPNet Network Structure .
Create a server router (CM). In most cases, it will need one, even if you have a cluster configuration. In the SM create a subscriber point (AP) admin.


ViPNet network structure

Check with the command " Issue routing table ".
Further, all in the same menu " Services ":
Group registration of nodes in tasks -> Coordinator -> add our CM.
Individual registration in the tasks -> admin -> add the checkboxes NOC + ECC.
Registering team types - admin -> links -> add SM.
User registration -> Add another user to the admin and vpn1000 channels
Group registration of nodes in tasks -> Coordinator -> registration in task hw1000 -> select the required CM -> ip addresses -> enter IP addresses. (See the documentation “ViPNet NCC” pp. 13.4.2.1 and 13.5). Here you need to specify the internal and external address of our coordinator and tunneled networks.

Now we check :
Configuration check
Generate all directories

We have finished with the NOC, we are launching our ECC

Appearance of ECC

Primary adjustment is done using a simple wizard. I will not describe each button, I will run briefly.
The user whose name we assign to the network administrator is admin, the default settings are not changed. Mark the checkbox "create asymmetric master key"

Set an administrator password for the “All Network” group (this group includes all network nodes by default), which is used to enter administrator mode on Network Nodes (our coordinators).
The created distributions will be displayed in the ECC in the Key Center section > Own ViPNet network> Keys> Key Distributions.

After that, restart the ECC - he will ask for the password. Enter the same administrator password that has just been generated.

A small remark: if you suddenly forgot one of the passwords, it would be easiest to reconfigure everything again (delete the NOC and the ECC, delete the InfoTecs folder) - from the second or third time, the setup takes about fifteen minutes and goes almost to the machine).

We form exports for our partner’s network.
In NOC: Services -> Export. Since we don't have anything yet, add a network for export (this is your partner's trusted network). We add there all our SU and all TC. Click Copy.
The received files will need to be picked up in the NCC \ EXPORT folder, stuffed into an encrypted archive and transferred to the partner network administrator.
Accept import. We copy the contents of the archive into the IMPORT folder, reboot the NOC. Services -> raw import.

We return to the ECC
We accept a symmetric master key (see the manual for the ECC) or create your own - here you will agree with your partner
Create node keys (see manual on ECC)
Own network -> Keys -> Keys of nodes. On each node PKM -> move to NOC

NOC
Generate all directories, then re-export and send to partner. Accept import.

Cooking key distributions
WCC -> KC -> SU -> Open. We set the administrator password.
NOC -> Services -> Files for ... ECC -> Distributions ... (copy both SU: VPN1000 and admin)
WCC -> Service -> Automatically create -> Key Distributions

We transfer distributions (* .dst files) to removable media (using the Move to folder folder in the context menu).
Copy user passwords to the same carrier ( Tools> Save Passwords In File> User Passwords ).

Import certificates
UCC -> UTs -> Trusted Networks -> Inbox. Import all certificates

Finally, we get, in fact, to iron
Import keys and directories on HW. With the help of the wizard we set up network interfaces. This can be done later from the console. The default password for vipnet / vipnet login
After installing the keys login: vipnet, password: password from the distribution with the keys SM, enable: password of the administrator of the SU (the one for the UCC).
In the NCC we add connections between the imported TC and its own. We again export and accept imports. Import-export is repeated until anomalies stop on both sides.
After each import, we do “Generate all directories”, Management -> Submit changed files -> Directory references -> select our control systems (admin, vpn1000) and send.
In the ViPNet client, a message should appear on the update of address directories and a coordinator with whom we contact.
NOC -> Management -> Send changed files -> Keys of nodes. We send the keys to the coordinator and the client.

3. Bonus

Failover implies that you have two pieces of iron, and they work together, posing as one cluster. The work is based on VRRP plus synchronization of crypto sessions.



Notice the [misc] section and the “reboot = no” option. By default, it is set to yes, and if failover fails to start the first time, you will have to reinstall the PACK OS again from the image. At the same time, the instruction states that the default value is “no”. Perhaps this is already fixed, but you still have to keep in mind.

We check that both you and the partner have the same encryption type:
iplir set cipher-mode cfb

Another useful feature of the encryption module:
iplir show config
After all imports and exports, there should be your partner’s networks and networks, between which you need to set up the exchange. Well, do not forget to properly configure the routing so that the traffic to the partner nodes is wrapped in the coordinator.

4. Through thorns - to the stars!

So, the setup is complete, but the channel between our PAK and the partner network does not rise. And here the most interesting began.

Naturally, the ticket was launched in support, there were clarifying questions, repeated reset of the PAK “to default”, recheck of all settings, including by the support itself through a remote session ...

After a month of knocking on a tambourine and copying the next file from one folder to another, the channel rose. Bingo? In general, yes, but the sediment remained considerable! A month almost wasted, hundreds of emails to support and a partner administrator, endless exchange of settings (one of the ViPNet tokens is import-export settings between the PACK with key information and network settings) and a letter from the management to Infotex with a proposal to take the buggy piece back .

There were even attracted developers, the answer of which was, in its own way, brilliant: “probably, you did something wrong”. Well, of course, the channel eventually earned. And it still works, pah-pah.

Colleagues suggest that they also suffered for about a month, and it, as a result, “worked by itself” when the manufacturer’s technical support got involved.

Mysticism, not otherwise. Or maybe this is a kind of dedication - the system obeys only the persistent.

In conclusion, I want to say that I don’t strive to “throw mud at someone”, I just describe my experience. At first, the terminology, which seems to me to be sharpened by information security specialists rather than networkers: subscriber stations, key distributions, user groups, communications, and so on, caused particular dissonance. Although, iron is designed for large companies, and they, as a rule, have IT security personnel. On the other hand, an obvious sharpening under state structures (and who else in their right mind would use Gostov's encryption?) Imposes localization requirements, and, it seems, on terminology as well.