Dva řádky logu OpenVPN začínají stejnými slovy a jen jeden z nich hlásí problém. Could not determine IPv4/IPv6 protocol. Using AF_INET je oznámení o záložním režimu: profil ponechal rodinu adres otevřenou, takže daemon jednu vybral a pokračoval. Větev selhání hlásí, že socket nebyl vytvořen, a žádá restart. Vše za společnou předponou je odděluje, takže čtěte dál, než něco změníte.

Co oznámení o záložním režimu říká

OpenVPN přijímá explicitní rodinu pomocí proto udp4 nebo proto udp6 a přijímá proto udp, když se má rodina odvodit při startu. Ve druhém případě daemon prozkoumá místní informace o navázání a vybere.

Když toto odvození funguje, varování uvede, kterým směrem se vydalo, a proces pokračuje vytvořením socketu. Server s proto udp na hostiteli s duálním zásobníkem tak často skončí na IPv4. Nic na této cestě není chyba a nic v ní nenaznačuje útok, chybějící webový server nebo odmítnutý účet. Řádek je užitečný jen proto, že pozdější kontroly by se měly srovnávat s rodinou, kterou uvádí.

Berte to jako odpověď na jednu otázku, ne jako diagnózu. Říká, kterou rodinu tento proces zvolil, a vůbec nic o tom, proč se klient nemůže připojit.

Jak vypadá větev selhání

Později ve stejném kódu pro socket je větev, kde žádný socket vůbec neexistuje. Zapíše kratší zprávu o rodině adres a požádá o restart, protože není čím pokračovat. Úvodní slova odpovídají záložnímu režimu, výsledek ne.

Rozeznejte je podle toho, co následuje. Pokud daemon běží dál a hlásí svého naslouchače, byl řádek informace. Pokud skončí nebo se restartuje ve smyčce, hovoří se teď o navázání.

Ani nález v grepu není identifikace větve. Fráze se objevuje v rotovaných souhrnech, v zalomených řádcích a ve výpisech logu, které lidé vkládají z druhé ruky, takže čtěte sousední řádky a pořadí časových značek, ne jedinou shodu.

Zkontrolujte naslouchač, ne varování

Běžící server odpovídá na otázku rodiny přímo, bez odvozování z textu logu.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Porovnejte rodinu, adresu a port s profilem. Řádek 0.0.0.0:1194 je pouze IPv4, zatímco řádek [::]:1194 na hostiteli s duálním zásobníkem může přijímat obě rodiny podle nastavení bindv6only. Pokud profil uvádí udp a socket je IPv4, klienti, jejichž resolver vrací jen záznam AAAA, selžou dřív, než se tunel vůbec vyjedná.

Potom testujte z klienta, který se podobá vašim uživatelům: stejná cesta resolveru, stejný druh sítě. Místní připojení ze serveru dokazuje jen velmi málo o provozu, který prochází zařízením NAT nebo pravidlem firewallu napsaným pro druhou rodinu.

Kdy je vynucení rodiny správné

Připnutí proto udp4 se hodí pro nasazení pouze s IPv4: DNS jméno jen s A, pravidla firewallu pro jednu adresu v4, klienti za operátory, kteří přidělují jen adresy v4. Odstraňuje to nejednoznačnost a činí další sadu řádků logu předvídatelnou.

Stejný argument platí opačně pro prostředí s prioritou IPv6 a udp6 před klientskou základnou jen s A je samo způsobený výpadek. Vynucovat rodinu jen proto, aby se umlčelo neškodné varování, je klasická verze této chyby, protože jste změnili, kdo se může připojit, výměnou za klidnější log.

Vyberte podle koncových bodů a klientů, kteří k nim musí dosáhnout. Příručka OpenVPN 2.6 dokumentuje formy přenosu a zpráva je výstupem této volby, ne jejím vstupem.

Držte záznam úzký

Zapište přesný řádek s jeho časovou značkou, účinné nastavení přenosu z běžícího profilu, socket tak, jak jej hlásí jádro, a další fázi, která selhala. Tyto čtyři položky vyřeší téměř každou otázku, kterou zpráva vyvolává, a žádná z nich nepotřebuje hádat o nesouvisejících službách. Přežijí také předání, což snímek obrazovky z grepu neumí.

Návrhy balíčků, které přicházejí spolu s tímto varováním, nesouvisejí, dokud chyba nepojmenuje chybějící spustitelný soubor.

Pokud ifconfig skutečně chybí, daemon to řekne jménem, když ho skript zavolá, a to si zaslouží vlastní vyšetřování. Řádek AF_INET a chybějící utilita jsou různé poruchy a instalování věcí jen proto, abyste viděli, zda se varování změní, je způsob, jak se z čistého hostitele stane nepořádný.

Související články