Adaptér OpenVPN na Windowsu neustále padá? Zkontrolujte duplicitní IP

Ve Windows adaptér OpenVPN, který převezme adresu, zahodí ji a každých pár sekund to zopakuje, obvykle není chyba DHCP. Adaptéru se říká, aby používal adresu, na kterou už odpovídá něco jiného, takže ji Windows označí jako nepoužitelnou a klient začne znovu. Protokol klienta zůstává tichý, protože konflikt se řeší pod ním, uvnitř vlastního síťového zásobníku operačního systému.

Tento rozdíl je důležitý, protože každý krok řešení potíží zaměřený na konfiguraci tunelu přehlédne duplicitní adresu na straně serveru.

Začněte protokolem událostí Windows, ne protokolem klienta

Windows zaznamenává konflikty adres do systémového protokolu s ID událostí 4198 a 4199. První hlásí zjištěný konflikt pro adresu, druhý hlásí, že rozhraní nemohlo použít adresu, se kterou bylo nakonfigurováno. Ani jeden nezmiňuje OpenVPN, a právě proto je snadné je přehlédnout.

Vytáhněte nedávné události a porovnejte jejich časová razítka s obnovovacím cyklem adaptéru: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikt každých patnáct sekund odpovídá klientovi, který znovu zkouší stejnou adresu proti vlastníkovi, jenž na ni dál odpovídá. Jediný konflikt v době připojení ukazuje spíš na jednorázovou kolizi. V obou případech je další otázkou, kdo další adresu drží.

Tři uspořádání staví dva hostitele na jednu adresu

Zeptejte se serveru, kdo podle něj adresu drží, a pak se zeptejte sítě, kdo na ni odpovídá. grep -H ifconfig-push /etc/openvpn/ccd/* vypíše každou připevněnou adresu tunelu a certifikát, ke kterému patří. ip -4 neigh show dev tap0 ukazuje, co se most naučil na druhé vrstvě. Porovnání těchto dvou seznamů najde většinu duplicit za méně než minutu.

Tři uspořádání vysvětlují téměř všechny: záznam v client-config-dir připevní jednu adresu pro dva certifikáty, přemostěný tap segment dá stroji adresu, kterou už jiný hostitel má staticky, nebo zastaralý soubor pronájmu vrátí adresu, o níž se stále připojený klient domnívá, že ji vlastní. Třetí případ je nejzáludnější, protože ifconfig-pool-persist záměrně znovu používá adresy pro známé klienty.

Udělejte adresu jedinečnou, místo abyste o ni závodili

Pořadí spouštění rozhoduje jen o tom, kdo dnes vyhraje, takže jakoukoli opravu založenou na sledu restartů považujte za dočasnou. Dejte každému klientovi vlastní řádek ifconfig-push nebo přidělujte statické adresy z rozsahu, kterého se nedotýká žádné mostní ani serverové rozhraní. Zkontrolujte také seznam klientů na duplicitní společná jména, protože duplicate-cn umožňuje dvěma relacím sdílet jednu identitu, a tím i jednu připevněnou adresu. Pokud přemostěné zařízení skutečně potřebuje pevnou adresu, přesuňte je do vlastní podsítě nebo ji rezervujte z fondu na místě, které server zaznamenává.

Soubor persist smažte až poté, co zjistíte, které pronájmy obsahuje, jinak příští opětovné připojení znovu rozdá stejné adresy.

Restartujte ve správném pořadí a potvrďte jednoho vlastníka na adresu

Změnu nejprve použijte na serveru a potom znovu připojte klienty, aby se každý účastník zaregistroval proti opravenému fondu. Když nejdřív restartujete klienty, zůstanou s adresami, které server stále považuje za obsazené. Po restartu přečtěte stavový soubor a potvrďte, že každé společné jméno se objeví jednou s jednou adresou. Dva záznamy pro jedno jméno znamenají, že se stará relace nikdy neuzavřela, ne že je fond rozbitý.

Pokud klient stále nedokáže udržet svou adresu, zkontrolujte, zda ji nenese mostní rozhraní na stejném hostiteli. Most, který zdědil adresu od zařízení dodavatele, bude na ni odpovídat ARP, i když ji server VPN už předal klientovi.

Sledujte celý obnovovací cyklus, než tiket uzavřete

Jediné čisté čtení nic nedokazuje. Sledujte adaptér alespoň deset minut a uprostřed vynuťte opětovné připojení: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresa by měla opětovné připojení přežít a zůstat v preferovaném stavu.

Potom znovu spusťte dotaz na události z prvního kroku a potvrďte, že nevrací nic nového. Tichý protokol během opětovného připojení je důkazem, že konflikt zmizel, zatímco tichý protokol po jediném připojení znamená jen to, že závod ještě nenastal. Nakonec otestujte prostředek, kvůli kterému tunel existuje, protože most, který ztratil svou adresu, může rozbít cestu dodavatele, i když samotná VPN vypadá zdravě.

Zapište rozsah fondu, každou připevněnou adresu a hostitele, který ji vlastní, do poznámek serveru. Příští kolize se pak najde za minuty místo celého odpoledne.