Adaptér OpenVPN na Windowsi bliká? Skontrolujte duplicitnú IP

Vo Windowsi adaptér OpenVPN, ktorý prevezme adresu, zahodí ju a každých pár sekúnd to zopakuje, zvyčajne nie je chyba DHCP. Adaptéru sa hovorí, aby používal adresu, na ktorú už odpovedá niečo iné, takže ju Windows označí ako nepoužiteľnú a klient začne odznova. Protokol klienta zostáva ticho, pretože konflikt sa rieši pod ním, v samotnom sieťovom zásobníku operačného systému.

Tento rozdiel je dôležitý, pretože každý krok riešenia problémov zameraný na konfiguráciu tunela prehliadne duplicitnú adresu na strane servera.

Začnite protokolom udalostí Windows, nie protokolom klienta

Windows zaznamenáva konflikty adries do systémového protokolu s ID udalostí 4198 a 4199. Prvý hlási zistený konflikt pre adresu, druhý hlási, že rozhranie nemohlo použiť adresu, s ktorou bolo nakonfigurované. Ani jeden nespomína OpenVPN, a práve preto sa dajú ľahko prehliadnuť.

Vytiahnite nedávne udalosti a porovnajte ich časové pečiatky s obnovovacím cyklom adaptéra: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikt každých pätnásť sekúnd zodpovedá klientovi, ktorý znova skúša tú istú adresu voči vlastníkovi, ktorý na ňu ďalej odpovedá. Jediný konflikt pri pripojení skôr naznačuje jednorazovú kolíziu. V oboch prípadoch je ďalšou otázkou, kto iný adresu drží.

Tri usporiadania stavajú dvoch hostiteľov na jednu adresu

Opýtajte sa servera, kto podľa neho adresu drží, a potom sa opýtajte siete, kto na ňu odpovedá. grep -H ifconfig-push /etc/openvpn/ccd/* vypíše každú pripnutú adresu tunela a certifikát, ku ktorému patrí. ip -4 neigh show dev tap0 ukazuje, čo sa most naučil na druhej vrstve. Porovnanie týchto dvoch zoznamov nájde väčšinu duplikátov za menej ako minútu.

Tri usporiadania vysvetľujú takmer všetky: záznam v client-config-dir pripne jednu adresu pre dva certifikáty, premosťovaný tap segment dá stroju adresu, ktorú už iný hostiteľ má staticky, alebo zastaraný súbor lízingu vráti adresu, o ktorej sa stále pripojený klient domnieva, že ju vlastní. Tretí prípad je najzáludnejší, pretože ifconfig-pool-persist zámerne znovu používa adresy pre známych klientov.

Urobte adresu jedinečnou namiesto toho, aby ste o ňu pretekali

Poradie spúšťania rozhoduje len o tom, kto dnes vyhrá, preto akúkoľvek opravu založenú na poradí reštartov považujte za dočasnú. Dajte každému klientovi vlastný riadok ifconfig-push alebo prideľujte statické adresy z rozsahu, ktorého sa nedotýka žiadne mostné ani serverové rozhranie. Skontrolujte aj zoznam klientov na duplicitné spoločné názvy, pretože duplicate-cn umožňuje dvom reláciám zdieľať jednu identitu a teda jednu pripnutú adresu. Ak premostené zariadenie naozaj potrebuje pevnú adresu, presuňte ho do vlastnej podsiete alebo ju rezervujte z fondu na mieste, ktoré server zaznamenáva.

Súbor persist vymažte až po tom, čo zistíte, ktoré lízingy obsahuje, inak ďalšie opätovné pripojenie znova rozdelí tie isté adresy.

Reštartujte v správnom poradí a potvrďte jedného vlastníka na adresu

Zmenu najprv použite na serveri a potom znova pripojte klientov, aby sa každý účastník zaregistroval voči opravenému fondu. Ak ako prvých reštartujete klientov, zostanú s adresami, ktoré server stále považuje za obsadené. Po reštarte prečítajte stavový súbor a potvrďte, že každý spoločný názov sa objaví raz s jednou adresou. Dva záznamy pre jeden názov znamenajú, že stará relácia sa nikdy neuzavrela, nie že je fond pokazený.

Ak klient stále nedokáže udržať svoju adresu, skontrolujte, či ju nenesie mostné rozhranie na tom istom hostiteľovi. Most, ktorý zdedil adresu od zariadenia dodávateľa, bude na ňu odpovedať ARP, aj keď server VPN už adresu odovzdal klientovi.

Sledujte celý obnovovací cyklus, kým zatvoríte tikety

Jediné čisté čítanie nič nedokazuje. Sledujte adaptér aspoň desať minút a v strede vynúťte opätovné pripojenie: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresa by mala opätovné pripojenie prežiť a zostať v preferovanom stave.

Potom znova spustite dopyt na udalosti z prvého kroku a potvrďte, že nevracia nič nové. Tichý protokol počas opätovného pripojenia je dôkazom, že konflikt zmizol, kým tichý protokol po jedinom pripojení znamená len to, že preteky ešte nenastali. Nakoniec otestujte prostriedok, kvôli ktorému tunel existuje, pretože most, ktorý stratil adresu, môže pokaziť cestu dodávateľa, aj keď samotný VPN vyzerá zdravo.

Zapíšte rozsah fondu, každú pripnutú adresu a hostiteľa, ktorý ju vlastní, do poznámok servera. Ďalšia kolízia sa tak nájde za minúty namiesto celého popoludnia na jej opätovné objavenie.