Ĉu la OpenVPN-adaptilo svingiĝas en Windows? Kontrolu duoblan IP

En Windows, OpenVPN-adaptilo, kiu prenas adreson, forĵetas ĝin kaj ripetas tion ĉiujn kelkajn sekundojn, kutime ne estas cimo de DHCP. Oni diras al la adaptilo uzi adreson, kiu jam respondas al io alia, do Windows markas ĝin neuzebla kaj la kliento rekomencas. La klienta protokolo restas silenta ĉar la konflikto solviĝas sub ĝi, ene de la propra reta stako de la operaciumo.

Tiu distingo gravas, ĉar ĉiu problemara paŝo celanta la tunelan agordon maltrafos duoblan adreson ĉe la servila flanko.

Komencu per la Windows-eventsignalo, ne per la klienta protokolo

Windows registras adresajn konfliktojn en la sistema protokolo, kun eventaj ID-oj 4198 kaj 4199. La unua raportas konflikton detektitan por adreso, la dua raportas, ke interfaco ne povis uzi la adreson, kun kiu ĝi estis agordita. Neniu mencias OpenVPN, kaj ĝuste tial ili facile preteratentiĝas.

Elprenu la lastatempajn eventojn kaj komparu iliajn tempomarkojn kun la renoviga ciklo de la adaptilo: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikto ĉiujn dek kvin sekundojn kongruas kun kliento, kiu reklopodas la saman adreson kontraŭ posedanto, kiu daŭre respondas por ĝi. Unuopa konflikto ĉe la konekta tempo indikas unufojan kolizion. Ĉiuokaze, la sekva demando estas, kiu alia havas la adreson.

Tri aranĝoj metas du gastigantojn sur unu adreson

Demandu al la servilo, kiu laŭ ĝi havas la adreson, poste demandu al la reto, kiu respondas por ĝi. grep -H ifconfig-push /etc/openvpn/ccd/* listigas ĉiun fiksitan tunelan adreson kaj la atestilon, al kiu ĝi apartenas. ip -4 neigh show dev tap0 montras, kion la ponto lernis ĉe la dua tavolo. Kompari tiujn du listojn trovas la plej multajn duoblaĵojn en malpli ol minuto.

Tri aranĝoj klarigas preskaŭ ĉiujn: ero en client-config-dir fiksas unu adreson por du atestiloj, pontigita tap-segmento donas al maŝino adreson, kiun alia gastiganto jam havas statike, aŭ malnova lui-dosiero redonas adreson, kiun ankoraŭ konektita kliento kredas posedi. La tria kazo estas la plej ruza, ĉar ifconfig-pool-persist intence reuzas adresojn por konataj klientoj.

Faru la adreson unika anstataŭ konkuri por ĝi

La startordo nur decidas, kiu gajnos hodiaŭ, do traktu kiel provizoran ĉiun riparon bazitan sur la restartordo. Donu al ĉiu kliento sian propran ifconfig-push-linion, aŭ asignu statikajn adresojn el gamo, kiun tuŝas nek ponto nek servila interfaco. Kontrolu ankaŭ la klientan liston por duoblaj komunaj nomoj, ĉar duplicate-cn permesas al du sesioj kunhavigi unu identecon kaj sekve unu fiksitan adreson. Se pontigita aparato vere bezonas fiksan adreson, movu ĝin al sia propra subreto aŭ rezervu ĝin el la baseno en loko, kiun la servilo registras.

Forigu la persist-dosieron nur post kiam vi scias, kiujn lui-erojn ĝi tenas, alie la sekva rekonekto denove disdonos la samajn adresojn.

Restartu en la ĝusta ordo kaj konfirmu unu posedanton por adreso

Apliku la ŝanĝon unue al la servilo, poste rekonektu la klientojn, por ke ĉiu partoprenanto registriĝu kontraŭ la korektita baseno. Restartigi la klientojn unue lasas ilin kun adresoj, kiujn la servilo ankoraŭ kredas okupitaj. Post la restarto, legu la statusan dosieron kaj konfirmu, ke ĉiu komuna nomo aperas unufoje kun unu adreso. Du eroj por unu nomo signifas, ke malnova sesio neniam fermiĝis, ne ke la baseno difektiĝis.

Se kliento ankoraŭ ne povas teni sian adreson, kontrolu, ĉu ponta interfaco en la sama gastiganto portas ĝin. Ponto, kiu heredis adreson de vendista aparato, respondos ARP por ĝi eĉ kiam la VPN-servilo jam donis tiun adreson al kliento.

Observu tra plena renoviga ciklo antaŭ ol fermi la bileton

Unu pura legado pruvas nenion. Observu la adaptilon almenaŭ dek minutojn kaj devigu rekonekton meze: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. La adreso devus postvivi la rekonekton kaj resti en preferata stato.

Poste remetu la eventan mendon el la unua paŝo kaj konfirmu, ke ĝi redonas nenion novan. Silenta protokolo tra rekonekto estas la pruvo, ke la konflikto malaperis, dum silenta protokolo post unu konekto nur signifas, ke la konkurso ankoraŭ ne okazis. Fine, testu la rimedon, por kiu la tunelo ekzistas, ĉar ponto, kiu perdis sian adreson, povas rompi vendistan vojon dum la VPN mem aspektas sana.

Notu la basenan gamon, ĉiun fiksitan adreson kaj la gastiganton, kiu posedas ĝin, en la servilaj notoj. Tiam la sekva kolizio troveblas en minutoj anstataŭ postuli tutan posttagmezon por redekrii ĝin.