Ang OpenVPN adapter sa Windows ay paulit-ulit na bumababa? Suriin ang doble na IP

Sa Windows, ang OpenVPN adapter na kumukuha ng address, binitawan ito at inuulit ito tuwing ilang segundo ay karaniwang hindi bug ng DHCP. Sinasabihan ang adapter na gumamit ng address na may ibang sumasagot na, kaya minamarkahan ito ng Windows na hindi magagamit at nagsisimulang muli ang client. Nananatiling tahimik ang log ng client dahil ang salungatan ay niresolba sa ilalim nito, sa loob ng sariling network stack ng operating system.

Mahalaga ang pagkakaibang iyon, dahil bawat hakbang sa pag-troubleshoot na nakatutok sa configuration ng tunnel ay makakaligtaan ang dobleng address sa panig ng server.

Magsimula sa event log ng Windows, hindi sa log ng client

Itinatala ng Windows ang mga salungatan ng address sa System log, kasama ang event ID 4198 at 4199. Ang una ay nag-uulat ng salungatang natukoy para sa isang address, ang pangalawa ay nag-uulat na hindi magamit ng interface ang address na na-configure dito. Wala sa dalawa ang nagbabanggit ng OpenVPN, at iyon ang dahilan kung bakit madaling mapalampas ang mga ito.

Kunin ang mga kamakailang event at ihambing ang kanilang timestamp sa cycle ng pag-renew ng adapter: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Ang salungatan tuwing labinlimang segundo ay tumutugma sa client na muling sinusubukan ang parehong address laban sa may-ari na patuloy na sumasagot dito. Ang nag-iisang salungatan sa oras ng pagkonekta ay nagtuturo sa halip sa isang beses na banggaan. Anuman ito, ang susunod na tanong ay kung sino pa ang may hawak ng address.

Tatlong kaayusan ang naglalagay ng dalawang host sa isang address

Tanungin ang server kung sino sa palagay nito ang may address, pagkatapos ay tanungin ang network kung sino ang sumasagot dito. Inililista ng grep -H ifconfig-push /etc/openvpn/ccd/* ang bawat naka-pin na tunnel address at ang certificate na kinabibilangan nito. Ipinapakita ng ip -4 neigh show dev tap0 ang natutunan ng bridge sa ikalawang layer. Ang paghahambing ng dalawang listahan ay makakahanap ng karamihan sa mga doble sa loob ng wala pang isang minuto.

Tatlong kaayusan ang nagpapaliwanag sa halos lahat: ang entry sa client-config-dir ay nag-pin ng isang address para sa dalawang certificate, ang naka-bridge na tap segment ay nagbibigay sa isang makina ng address na mayroon na ang ibang host nang statiko, o ang lumang lease file ay nagbabalik ng address na inaakalang pag-aari ng client na nakakonekta pa. Ang ikatlong kaso ang pinakatuso, dahil sadyang ginagamit muli ng ifconfig-pool-persist ang mga address para sa mga kilalang client.

Gawing natatangi ang address sa halip na makipagkarera para dito

Ang boot order ay nagpapasya lamang kung sino ang mananalo ngayon, kaya ituring na pansamantala ang anumang pagwawasto na nakabatay sa pagkakasunod-sunod ng restart. Bigyan ang bawat client ng sariling linya ng ifconfig-push, o maglaan ng statikong address mula sa saklaw na hindi ginalaw ng anumang interface ng bridge o server. Suriin din ang listahan ng client para sa doble na karaniwang pangalan, dahil pinapayagan ng duplicate-cn ang dalawang sesyon na magbahagi ng isang pagkakakilanlan at dahil doon ay isang naka-pin na address. Kung ang naka-bridge na device ay talagang nangangailangan ng nakapirming address, ilipat ito sa sariling subnet o ireserba ito mula sa pool sa lugar na itinatala ng server.

Burahin ang persist file pagkatapos mong malaman kung anong mga lease ang hawak nito, kung hindi ay muling ipamimigay ng susunod na muling pagkonekta ang parehong mga address.

Mag-restart sa tamang pagkakasunod-sunod at kumpirmahin ang isang may-ari bawat address

Ilapat muna ang pagbabago sa server, pagkatapos ay ikonekta muli ang mga client, upang ang bawat kalahok ay magrehistro laban sa naitamang pool. Ang pag-restart muna ng mga client ay nag-iiwan sa kanila ng mga address na inaakala pa ring sakop ng server. Pagkatapos ng restart, basahin ang status file at kumpirmahin na ang bawat karaniwang pangalan ay lumilitaw nang isang beses na may isang address. Ang dalawang entry para sa isang pangalan ay nangangahulugang hindi kailanman isinara ang lumang sesyon, hindi na sira ang pool.

Kung ang isang client ay hindi pa rin mapanatili ang address nito, suriin kung may interface ng bridge sa parehong host na nagdadala nito. Ang bridge na nagmana ng address mula sa device ng vendor ay sasagot ng ARP para dito kahit na naibigay na ng VPN server ang address na iyon sa isang client.

Panoorin sa buong cycle ng pag-renew bago isara ang ticket

Walang pinatutunayan ang isang malinaw na pagbasa. Panoorin ang adapter nang hindi bababa sa sampung minuto at pilitin ang muling pagkonekta sa gitna: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Dapat lumampas ang address sa muling pagkonekta at manatili sa ginustong estado.

Pagkatapos ay patakbuhin muli ang query ng event mula sa unang hakbang at kumpirmahin na wala itong ibinabalik na bago. Ang tahimik na log sa buong muling pagkonekta ay ang ebidensyang nawala na ang salungatan, samantalang ang tahimik na log pagkatapos ng isang koneksyon ay nangangahulugan lamang na hindi pa nangyayari ang karera. Sa huli, subukan ang resource kung saan umiiral ang tunnel, dahil ang bridge na nawalan ng address ay maaaring makasira ng vendor path habang ang VPN mismo ay mukhang malusog.

Itala ang saklaw ng pool, bawat naka-pin na address at ang host na may-ari nito sa mga tala ng server. Pagkatapos, ang susunod na banggaan ay makikita sa loob ng ilang minuto sa halip na kailanganin ang buong hapon upang muling matuklasan ito.