OpenVPN adapteris Windows sistēmā mirgo? Pārbaudiet dubultotu IP

Windows sistēmā OpenVPN adapteris, kas paņem adresi, to nomet un atkārto to ik pēc dažām sekundēm, parasti nav DHCP kļūda. Adapterim liek izmantot adresi, uz kuru jau atbild kaut kas cits, tāpēc Windows to atzīmē kā neizmantojamu, un klients sāk no jauna. Klienta žurnāls paliek kluss, jo konflikts tiek risināts zem tā, pašā operētājsistēmas tīkla stekā.

Šī atšķirība ir svarīga, jo katrs problēmu novēršanas solis, kas vērsts uz tuneļa konfigurāciju, palaidīs garām dubultotu adresi servera pusē.

Sāciet ar Windows notikumu žurnālu, nevis klienta žurnālu

Windows reģistrē adrešu konfliktus sistēmas žurnālā ar notikumu ID 4198 un 4199. Pirmais ziņo par konfliktu, kas konstatēts adresei, otrais ziņo, ka saskarne nevarēja izmantot adresi, ar kuru tā bija konfigurēta. Neviens no tiem nemin OpenVPN, un tieši tāpēc tos ir viegli nepamanīt.

Izvelciet jaunākos notikumus un salīdziniet to laikspiedolus ar adaptera atjaunināšanas ciklu: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikts ik pēc piecpadsmit sekundēm atbilst klientam, kas atkārtoti mēģina to pašu adresi pret īpašnieku, kurš joprojām uz to atbild. Viens konflikts savienošanās laikā drīzāk norāda uz vienreizēju sadursmi. Jebkurā gadījumā nākamais jautājums ir, kam vēl pieder adrese.

Trīs izkārtojumi novieto divus resursdatorus uz vienas adreses

Pajautājiet serverim, kas, viņaprāt, tur adresi, un pēc tam pajautājiet tīklam, kas uz to atbild. grep -H ifconfig-push /etc/openvpn/ccd/* uzskaita katru piefiksēto tuneļa adresi un sertifikātu, kuram tā pieder. ip -4 neigh show dev tap0 parāda, ko tilts iemācījies otrajā slānī. Salīdzinot šos divus sarakstus, lielākā daļa dublikātu tiek atrasta mazāk nekā minūtē.

Trīs izkārtojumi izskaidro gandrīz visus: client-config-dir ieraksts piefiksē vienu adresi diviem sertifikātiem, tiltā savienots tap segments dod mašīnai adresi, kas citam resursdatoram jau ir statiski, vai novecojis nomas fails atgriež adresi, kuru vēl savienots klients uzskata par savu. Trešais gadījums ir visviltīgākais, jo ifconfig-pool-persist apzināti atkārtoti izmanto adreses zināmiem klientiem.

Padariet adresi unikālu, nevis sacentieties par to

Sāknēšanas secība nosaka tikai to, kas uzvar šodien, tāpēc uzskatiet par pagaidu jebkuru labojumu, kas balstīts uz restartēšanas secību. Dodiet katram klientam savu ifconfig-push rindu vai piešķiriet statiskas adreses no diapazona, kuram nepieskaras neviena tilta vai servera saskarne. Pārbaudiet arī klientu sarakstu uz dubultotiem koplietotiem nosaukumiem, jo duplicate-cn ļauj divām sesijām koplietot vienu identitāti un tādējādi vienu piefiksētu adresi. Ja tiltā savienotai ierīcei patiešām vajag fiksētu adresi, pārvietojiet to uz savu apakštīklu vai rezervējiet to no kopas vietā, kuru serveris reģistrē.

Dzēsiet persist failu tikai pēc tam, kad zināt, kādas nomas tas satur, citādi nākamā atkārtotā savienošanās atkal izdalīs tās pašas adreses.

Restartējiet pareizā secībā un apstipriniet vienu īpašnieku katrai adresei

Vispirms piemērojiet izmaiņas serverim, pēc tam atkārtoti savienojiet klientus, lai katrs dalībnieks reģistrētos pret laboto kopu. Ja vispirms restartējat klientus, tie paliek ar adresēm, kuras serveris joprojām uzskata par aizņemtām. Pēc restarta izlasiet statusa failu un apstipriniet, ka katrs koplietotais nosaukums parādās vienu reizi ar vienu adresi. Divi ieraksti vienam nosaukumam nozīmē, ka vecā sesija nekad netika aizvērta, nevis to, ka kopa ir salauzta.

Ja klients joprojām nevar noturēt savu adresi, pārbaudiet, vai to nenes tilta saskarne tajā pašā resursdatorā. Tilts, kas mantoja adresi no piegādātāja ierīces, atbildēs uz ARP par to pat tad, kad VPN serveris jau ir nodevis šo adresi klientam.

Vērojiet visu atjaunināšanas ciklu pirms biļetes aizvēršanas

Viens tīrs nolasījums neko nepierāda. Vērojiet adapteri vismaz desmit minūtes un vidū piespiediet atkārtotu savienojumu: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresei jāiztur atkārtotā savienošanās un jāpaliek vēlamajā stāvoklī.

Pēc tam vēlreiz palaidiet pirmā soļa notikumu vaicājumu un apstipriniet, ka tas neatgriež neko jaunu. Kluss žurnāls atkārtotas savienošanās laikā ir pierādījums, ka konflikts ir pazudis, savukārt kluss žurnāls pēc viena savienojuma tikai nozīmē, ka sacensība vēl nav notikusi. Visbeidzot, pārbaudiet resursu, kura dēļ tuneļa pastāv, jo tilts, kas zaudēja savu adresi, var salauzt piegādātāja ceļu, kamēr pats VPN izskatās vesels.

Pierakstiet kopas diapazonu, katru piefiksēto adresi un resursdatoru, kuram tā pieder, servera piezīmēs. Tad nākamā sadursme tiks pamanīta dažu minūšu laikā, nevis prasīs veselu pēcpusdienu, lai to no jauna atklātu.