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

Решението не е по-добро копие. То е да не се копира файлът.

Какво всъщност съдържа телефонната книга

Телефонната книга е контейнер с дефиниции на връзки, а не профил. Записите за отделните потребители живеят в потребителския профил, а записите за всички потребители живеят в пътя ProgramData на ниво машина, поради което внедряване, което пише този файл, засяга всеки локален потребител наведнъж. Същият файл носи и записи, създадени от други доставчици, и точно оттам идва съпътстващата щета.

Дефиницията на връзка също не е цялата история. Маршрутите, DNS политиката, довереният CA материал и самоличността се осигуряват от отделни собственици.

Открийте кой обхват притежава профила

Избройте двата обхвата, преди да пишете каквото и да е. Get-VpnConnection връща записите на текущия потребител, а Get-VpnConnection -AllUserConnection връща тези на ниво машина, и едно и също име може да съществува в двете с различни настройки. Решете кой обхват притежава вашето внедряване и го запишете, защото обновяването на грешния обхват оставя потребителя да се свързва през стария профил, докато промяната ви стои във файл, който никой не чете. Планирана задача, работеща като SYSTEM също вижда различен набор от профили от влезлия потребител.

Назоваването на собственика е стъпката, която спира следващия инженер да повтори копирането на целия файл.

Създайте или обновете именуваната връзка, нищо друго

За вграден Windows профил Add-VpnConnection създава един запис, а -AllUserConnection избира обхвата на ниво машина. Стартирайте го първо с -WhatIf, за да попадне прегледът в транскрипта ви, а не в оплакване от потребител:

Add-VpnConnection -Name 'Office VPN' -ServerAddress 'vpn.example.com' -TunnelType Ikev2 -AuthenticationMethod Eap -EapConfigXmlStream $approvedEapXml -AllUserConnection -WhatIf

EAP XML трябва да дойде от някъде законно: експортиран от работещ референтен профил или генериран от инструментите ви за управление за действителния шлюз. Без правилни настройки за доверие на сървъра профилът или се свързва с грешното нещо, или се проваля навсякъде, и нито едно от двете не е успех на внедряване.

Когато записът вече съществува, сравнете настройките му и го обновете с Set-VpnConnection, вместо да го изтривате и създавате наново. Изтриването е начинът, по който работеща конфигурация губи полета, които никой не е документирал, и начинът, по който несвързани записи попадат в широко почистване.

Проверете за втора система за управление, която ще върне стария профил при следващото обновяване на политиката. Пилотите се провалят тук по-често, отколкото при cmdlet.

Пилотирайте на машина, която вече има друг VPN

Изберете тестова машина с несвързан запис на ниво машина, внедрете, после проверете три неща: новият профил се появява в предвидения обхват, удостоверяването достига до частен ресурс, и несвързаният запис все още се свързва. Внедрете още два пъти и потвърдете, че второто изпълнение променя само профила, който притежава. Тази трета проверка хваща пакет, който е идемпотентен за собствения си запис и разрушителен за всичко останало.

Премахването следва същото правило: Remove-VpnConnection -Name 'Office VPN' -AllUserConnection пенсионира един запис и оставя останалата част от файла непокътната.

Дръжте предишната предвидена конфигурация на разположение, така че ограничено връщане назад да означава повторен импорт на един профил, вместо възстановяване на цялото състояние на машината.

Подобни статии