L2TP-tiidferrin op Ubuntu 22.04: de xl2tpd-tunnelbrek

It buroblêd lit in ferbining sjen dy't dwaande is, IPsec meldt súkses, en de PPP-ynterface ferskynt nea. Yn 'e systeemlog werhellet deselde tunnelnûmer oant de besiking op UDP 1701 tiidferrint. Foardat jo de foarôf dielde kaai of de serverkonfiguraasje bewurkje, werken jo dit patroan: op Ubuntu 22.04 is it meastentiids in pakketregresje yn xl2tpd, en de server wie de hiele tiid korrekt.

Wat it werheljende logpear jo fertelt

In mislearjende sesje printet geregeld in pear rigels: de daemon fynt gjin tunnel foar in ynkommend kontrôleberjocht, en smyt dan de oprop- en tunnelidentifikaasjes út dy't er krigen hat. Letter berikt de werbepogingsteller syn limyt en wurdt de ferbining sletten mei in tiidferrin op poarte 1701. Adressen en identifikaasjes binne tafallich; de foarm is wat telt. IKE waard foltôge, L2TP-kontrôleferkear kaam oan, en de daemon koe it net keppelje oan in tunnel dy't er al makke hie.

De flater sit dus tusken L2TP-kontrôle en PPP. Oer it geheim, de PPP-opsjes of it fiere subnet is noch neat útprobearre.

Befêstigje dat IPsec echt slagge is

Twa kontrôles skiede dit fan in probleem mei oanmeldgegevens, en beide hearre foar elke pakketwiziging.

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

De statusútfier lit de ferbining en har steat sjen, en in oanleine tunnel betsjut dat faze ien en faze twa foltôge binne. In logrigel oer in ûntbrekkende dielde kaai wiist allinnich op it geheim, dus stopje en reparearje dat earst. As IPsec oanlein is en it L2TP-tiidferrin noch hieltyd ferskynt, is de daemon de oerbliuwende fertochte. Bewarje de krekte rigels fan ien besiking yn plak fan in hiele dei werbepogingen.

Kontrôles de xl2tpd-bou, net de namme fan de útjefte

Ubuntu syn jammy-bou fan xl2tpd 1.3.16 sette linktiid-optimalisaasje oan, wat it parsen fan 'e tunnelidentifikaasje yn it SCCRP-antwurd fan 'e server bruts. De daemon smyt dan kontrôlepakketten fuort foar in tunnel dy't er sels makke hat. De ferzjestring telt mear as de distribúsjenamme.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

It korrizjearre pakket is 1.3.16-1ubuntu0.1, dus in bou sûnder dat efterheaksel is âlder as de korreksje. De beliedsútfier lit sjen hokker kandidaat in upgrade ynstallearje soe, en de holdlist ferklearret wêrom't in korreksje net oankaam. Wêr't it pakket beskikber is, upgrade it en meitsje opnij ferbining fia it normale profyl yn plak fan bestannen mei de hân te bewurkjen. Bou gjin modules opnij en feroarje it geheim net salang't de âlde bou noch ynstallearre is.

Ferifiearje PPP nei de wiziging

In slagge upgrade wurdt bewiisd op 'e laach dy't brutsen wie. Kontrôles dat PPP omheech kaam, en net allinnich dat it ikoan feroare.

ip -4 addr show ppp0
ip route | grep ppp

De ynterfacelist soe in lokaal en in peeradres sjen litte, en de rûtetabel soe de prefiksen fan 'e tunnel drage moatte. De systeemlog soe sjen litte dat de tunnel akseptearre is en pppd beide adressen meldt, sûnder werhelle rigels oer tunnel net fûn. As PPP omheech is en ferkear dochs mislearret, sjoch dan neist nei routing of MTU, want de L2TP-etappe hat syn wurk dien. Skriuw de wurkjende pakketferzje yn 'e masjinenotysjes, sadat in takomstige werynstallaasje de brutsen bou net weromset.

Wêr't it korrizjearre pakket net beskikber is, binne de dokumintearre alternativen in lokale boarnebou fan 1.3.16 of 1.3.17, in oerstap nei kl2tpd of in fêstsette weromgong. Elk draacht in ûnderhâldskost dy't it wurdich is om op te skriuwen.