Hodinový výpadek OpenVPN: renegociace, nebo skutečné opětovné připojení?

Šedesát minut, nebo třicet, nebo sto dvacet: výpadek, který padne na kulatý interval, téměř nikdy není síť. OpenVPN obnovuje podle časovače klíčový materiál, který chrání datový kanál, a časovač kratší než ten, který jste předpokládali, vypadá přesně jako spojení, které neustále selhává. Uživatelé hlásí přerušené připojení, zatímco log hlásí úspěšnou výměnu klíčů. Návod níže odděluje tuto obnovu od skutečného restartu, čte hodnotu, která skutečně platí, a mění ji teprve poté, co je cena na stole.

Provádějte kroky popořadě, protože první z nich rozhoduje, zda se vás zbytek stránky vůbec týká. Přeskočte dopředu a strávíte večer laděním časovače kvůli závadě, která s ním nemá nic společného.

Rozeznejte měkký reset od restartu

Řádek v logu je celá diagnóza. Renegociace zapíše měkký reset a poté novou výměnu klíčů uvnitř stejného tunelu: rozhraní si ponechá adresu, trasy se znovu nepřidávají a navázaná TCP spojení obvykle přežijí s pauzou. Skutečný restart přetrhne relaci, znovu sestaví rozhraní, může přidělit jinou adresu klienta a zabije každé dlouhodobé spojení. Obě události jsou běžné; jen jedna z nich vysvětluje přerušený hovor.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Řádek s verzí je důležitý, protože formulace v logu se mezi vydáními posouvají a zpráva, kterou si pamatujete z 2.3, může být v 2.6 formulována jinak. Čtěte vlastní log, ne výňatek z fóra od někoho jiného. Když žádáte o pomoc, citujte přesný řádek, protože parafráze ztrácí detail, který událost identifikuje. Pokud se adresa rozhraní během události nezmění a seznam relací přežije, díváte se na obnovu a zbývající části platí.

Čtěte platný časovač, ne svůj soubor

reneg-sec je počet sekund mezi renegociacemi datového kanálu a jeho výchozí hodnota je 3600. Každý protějšek nese svou hodnotu a právě menší z obou obnovu spouští. To jediné pravidlo vysvětluje většinu hlášení: profil klienta, který nastaví velké číslo, se stejně resetuje každou hodinu, dokud server drží výchozí hodnotu.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Přečtěte si také platnou konfiguraci serveru, včetně všeho, co posílá, než z klientského souboru vyvodíte závěr. Potom zvyšte podrobnost a sledujte jeden interval od začátku do konce: úroveň 3 už zobrazuje řádky renegociace a časové značky řeknou, zda se událost opakuje každých 3600 sekund, nebo následuje aktivitu.

Měňte to tam, kde se to skutečně posílá

Rozšířený lék je jediný řádek v klientském profilu a přibližně v polovině případů je to špatné místo. Protože vyhrává nižší hodnota protějšku, klient, který nastaví časovač na nulu, může být stále znovu vyjednán serverem, který se nezměnil.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Kde se profily generují centrálně, upravte šablonu, ne nasazenou kopii, jinak příští běh provisioning obnoví hodnotu, kterou jste právě odstranili. Ověřujte sledováním dvou intervalů, ne jednoho: jediná tichá hodina je v souladu i s časovačem nastaveným na 7200.

Rozhodněte také, co se stane při smíšeném nasazení. Pokud změnu nejprve rozšíříte na klienty, zůstane okno, ve kterém server stále spouští obnovu; je to neškodné, ale matoucí, pokud sledujete logy kvůli potvrzení. Změňte nejprve stranu s nižší hodnotou a symptom zmizí v bodě, který očekáváte.

Čeho se vzdáváte vypnutím renegociace

Pravidelná renegociace omezuje, jak dlouho jedna sada klíčů datového kanálu chrání provoz. Vypnutí časovače tunel nerozbije a na domácím routeru nebo bráně malé kanceláře je praktická expozice skromná. Je to stále výměna a vyplatí se ji pojmenovat, než ji uděláte. Mění se, jak dlouho jedna sada klíčů chrání relaci, ne to, zda tunel vůbec funguje.

Rozumný případ pro vypnutí je reset, který rozbije něco, co nelze obnovit: hovor, který spadne, relace vzdálené plochy, kterou je třeba znovu navázat, záloha, která začíná od začátku. Pokud je pauza pro uživatele neviditelná, ponechání výchozí hodnoty nic nestojí a zachová vám rotaci klíčů.

Dejte přednost opravě příčiny, když to vzorec dovolí. Obnova, která selže v polovině, zatímco první handshake uspěl, ukazuje na cestu, ne na časovač: hledejte problém s velikostí paketu ve větší výměně řídicího kanálu, stavový firewall, který zahazuje tok, nebo návrh, který uspěje jen na první pokus. Každý z nich zanechá stopu ve stejném logu, který jste právě četli. Vypnutí časovače ten důkaz skryje.

Když interval ukazuje jinam

Dva sousedé v konfiguraci dávají podobné symptomy a různé opravy. ping-restart restartuje tunel, když po nastavenou dobu nic nedorazí, zatímco ping-exit klienta zcela vypne. Výpadek v nečinnosti bez jakékoli renegociace v logu patří jim nebo zařízení NAT, kterému vypršelo mapování UDP podle jeho vlastního rozvrhu.

Spotřebitelské routery, mobilní hotspoty a NAT na úrovni operátora nechávají nečinné UDP relace vypršet, aniž by to někomu řekly. Ta porucha následuje nečinnost, ne hodiny, a to je ta známka: relace, která spadne po deseti tichých minutách a přežije hodinu stálého provozu, nevyjednává znovu.

Zapište si tři věci, než změníte čtvrtou: interval, který jste změřili, platnou hodnotu, kterou jste našli, a příkaz, který ji ukázal. Pokud se interval pohne, když se pohne časovač, mechanismus je určen a oprava je rozhodnutí o výměně výše. Pokud se nepohne, vraťte nastavení a dál sledujte keepalive, stav NAT a ztrátu paketů.