Časový limit L2TP na Ubuntu 22.04: chyba tunelu xl2tpd

Plocha ukazuje probíhající připojení, IPsec hlásí úspěch a rozhraní PPP se nikdy neobjeví. V systémovém protokolu se stejné číslo tunelu opakuje, dokud pokus nevyprší na UDP 1701. Než upravíte předem sdílený klíč nebo konfiguraci serveru, rozpoznejte tento tvar: na Ubuntu 22.04 jde obvykle o regresi balíčku v xl2tpd a server byl celou dobu správný.

Co vám říká opakující se dvojice řádků v protokolu

Selhávající relace vypisuje dvojici řádků v pravidelných intervalech: démon nenajde tunel pro příchozí řídicí zprávu a poté vypíše identifikátory volání a tunelu, které dostal. Později čítač opakování dosáhne limitu a spojení se uzavře s časovým limitem portu 1701. Adresy a identifikátory jsou náhodné; rozhoduje tvar. IKE dokončil, řídicí provoz L2TP dorazil a démon jej nedokázal přiřadit k tunelu, který už vytvořil.

Závada tedy leží mezi řízením L2TP a PPP. O tajemství, volbách PPP ani vzdálené podsíti se dosud nic neověřovalo.

Ověřte, že IPsec skutečně uspěl

Dvě kontroly oddělují tento případ od problému s přihlašovacími údaji a obě patří před jakoukoli změnu balíčku.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

Výstup stavu vypisuje spojení a jeho stav, a navázaný tunel znamená, že první i druhá fáze skončily. Řádek v protokolu o chybějícím sdíleném klíči ukazuje jen na tajemství, takže se zastavte a nejprve to opravte. Když je IPsec navázán a časový limit L2TP se stále objevuje, démon zůstává podezřelým. Uchovejte přesné řádky z jednoho pokusu místo celého dne opakování.

Prověřte build xl2tpd, ne název vydání

Build xl2tpd 1.3.16 v jammy od Ubuntu zapnul optimalizaci v době linkování, což rozbilo parsování identifikátoru tunelu v odpovědi SCCRP serveru. Démon pak zahazuje řídicí pakety pro tunel, který sám vytvořil. Řetězec verze je důležitější než název distribuce.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Opravený balíček je 1.3.16-1ubuntu0.1, takže build bez této přípony předchází opravě. Výstup politiky ukazuje, kterého kandidáta by aktualizace nainstalovala, a seznam zadržených vysvětluje, proč oprava nedorazila. Kde je balíček dostupný, aktualizujte jej a připojte se znovu přes běžný profil, místo abyste soubory upravovali ručně. Nepřestavujte moduly ani neměňte tajemství, dokud je starý build stále nainstalovaný.

Po změně ověřte PPP

Úspěšná aktualizace se prokazuje na vrstvě, která byla rozbitá. Ověřte, že PPP naskočilo, ne jen že se změnila ikona.

ip -4 addr show ppp0
ip route | grep ppp

Výpis rozhraní by měl ukázat místní adresu a adresu protistrany a směrovací tabulka by měla nést prefixy tunelu. Systémový protokol by měl ukázat přijatý tunel a pppd hlásící obě adresy, bez opakovaných řádků o nenalezeném tunelu. Pokud PPP běží a provoz stále selhává, podívejte se dále na směrování nebo MTU, protože fáze L2TP už svou práci dokončila. Zapište funkční verzi balíčku do poznámek stroje, aby budoucí přeinstalace neobnovila rozbitý build.

Kde opravený balíček není k dispozici, dokumentovanými alternativami jsou místní build ze zdrojů 1.3.16 nebo 1.3.17, přechod na kl2tpd nebo připnutý downgrade. Každá nese náklad na údržbu, který stojí za zapsání.