Адаптар OpenVPN на Windows зноў і зноў падае? Праверце дублікат IP

У Windows адаптар OpenVPN, які атрымлівае адрас, скідвае яго і паўтарае гэта кожныя некалькі секунд, звычайна не з'яўляецца памылкай DHCP. Адаптару загадваюць выкарыстоўваць адрас, на які ўжо адказвае нешта іншае, таму Windows пазначае яго як непрыдатны, і кліент пачынае спачатку. Журнал кліента маўчыць, бо канфлікт вырашаецца ніжэй за яго, унутры ўласнага сеткавага стэка аперацыйнай сістэмы.

Гэта розніца важная, бо кожны крок дыягностыкі, накіраваны на канфігурацыю тунеля, прапусціць дублікат адраса на баку сервера.

Пачніце з журнала падзей Windows, а не з журнала кліента

Windows запісвае канфлікты адрасоў у сістэмны журнал з ідэнтыфікатарамі падзей 4198 і 4199. Першы паведамляе пра выяўлены канфлікт для адраса, другі — што інтэрфейс не змог выкарыстаць адрас, з якім быў наладжаны. Ні адзін з іх не згадвае OpenVPN, і менавіта таму іх лёгка прапусціць.

Выміце нядаўнія падзеі і параўнайце іх часовыя меткі з цыклам абнаўлення адаптара: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Канфлікт кожныя пятнаццаць секунд адпавядае кліенту, які паўторна спрабуе той самы адрас супраць уладальніка, што працягвае на яго адказваць. Адзінкавы канфлікт у момант падключэння сведчыць хутчэй пра разовае сутыкненне. У любым выпадку наступнае пытанне — хто яшчэ трымае гэты адрас.

Тры варыянты змяшчаюць два хасты на адным адрасе

Спытайце сервер, хто, на яго думку, трымае адрас, а затым спытайце сетку, хто на яго адказвае. grep -H ifconfig-push /etc/openvpn/ccd/* пералічвае кожны замацаваны адрас тунеля і сертыфікат, якому ён належыць. ip -4 neigh show dev tap0 паказвае, што мост даведаўся на другім узроўні. Параўнанне гэтых двух спісаў выяўляе большасць дублікатаў менш чым за хвіліну.

Тры варыянты тлумачаць амаль усе з іх: запіс client-config-dir замацоўвае адзін адрас за двума сертыфікатамі, мастыфікаваны tap-сегмент выдае машыне адрас, які іншы хост ужо мае статычна, або састарэлы файл арэнды вяртае адрас, які яшчэ падключаны кліент лічыць сваім. Трэці выпадак самы падступны, бо ifconfig-pool-persist наўмысна паўторна выкарыстоўвае адрасы для вядомых кліентаў.

Зрабіце адрас унікальным, а не спаборнічайце за яго

Парадак загрузкі вызначае толькі, хто пераможа сёння, таму лічыце любое рашэнне, заснаванае на паслядоўнасці перазапуску, часовым. Дайце кожнаму кліенту яго ўласны радок ifconfig-push або выдзеліце статычныя адрасы з дыяпазону, якога не кранае ні адзін інтэрфейс моста ці сервера. Праверце спіс кліентаў на дублікаты агульных імёнаў, бо duplicate-cn дазваляе двум сесіям дзяліць адну асобу і, такім чынам, адзін замацаваны адрас. Калі мастыфікаваная прылада сапраўды патрабуе фіксаванага адраса, перанясіце яе ў сваю падсетку або зарэзервуйце яго з пула ў месцы, якое запісвае сервер.

Выдаляйце файл persist толькі пасля таго, як даведаецеся, якія арэнды ён трымае, інакш наступнае перападключэнне зноў выдасць тыя ж адрасы.

Перазапусціце ў правільным парадку і пацвердзіце аднаго ўладальніка на адрас

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

Калі кліент усё яшчэ не можа ўтрымаць свой адрас, праверце, ці не носіць яго інтэрфейс моста на тым самым хасте. Мост, які атрымаў адрас у спадчыну ад прылады пастаўшчыка, будзе адказваць на ARP для яго, нават калі сервер VPN ужо перадаў гэты адрас кліенту.

Назірайце за поўным цыклам абнаўлення, перш чым закрыць заяўку

Адно чыстае чытанне нічога не даказвае. Назірайце за адаптарам як мінімум дзесяць хвілін і ў сярэдзіне прымусова перападключыцеся: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Адрас павінен перажыць перападключэнне і застацца ў пажаданым стане.

Затым паўторна запусціце запыт падзей з першага кроку і пацвердзіце, што ён не вяртае нічога новага. Ціхі журнал на працягу перападключэння — гэта доказ, што канфлікт знік, а ціхі журнал пасля аднаго падключэння азначае толькі, што гонка яшчэ не адбылася. Нарэшце, праверце рэсурс, дзеля якога існуе тунель, бо мост, які страціў адрас, можа зламаць шлях пастаўшчыка, пакуль сам VPN выглядае здаровым.

Запішыце дыяпазон пула, кожны замацаваны адрас і хост, які ім валодае, у нататках сервера. Тады наступнае сутыкненне зойме хвіліны, каб заўважыць, а не паўдня, каб зноў выявіць.