FIPS çekirdek değişimi Wi-Fi ve VPN modüllerini de götürdü

fips-updates'i açın, yeniden başlatın; makine kablosuz arayüz olmadan geri gelirken VPN istemcisi çekirdek modülü bulunmadığı için başlamayı reddeder. Paketlerin olağan anlamında hiçbir şey kaldırılmadı, bu yüzden istemciyi yeniden kurmak hiçbir şeyi değiştirmez. Makine, sürücülerinin asla derlenmediği bir çekirdek üzerinde çalışıyor. İki belirti, tek neden, ve neden tek bir komutta görünüyor.

Yeniden başlatma gerçekte neyi değiştirdi

Ubuntu Pro'daki FIPS güncellemeleri sertifikalı bir çekirdek varyantı kurar ve onu varsayılan önyükleme girdisi yapar. Bu varyant gerçek bir çekirdektir: açılır, çalışır ve zaten sahip olduğunuz servisleri başlatır. İçermediği şey, genel çekirdek için derlenmiş her modüldür; ağaç dışında derlenmiş bir kablosuz sürücü ve DKMS aracılığıyla sağlanan bir tünel modülü de buna dahildir. Sürücü kümesi paket yöneticisiyle değil, çekirdekle birlikte hareket eder. Yani donanım hâlâ orada, onunla konuşan yazılım değil.

Herhangi bir ağ ayarını açmadan önce çalışan çekirdeği kurulu paketlerle karşılaştırın. Sürüm dizesi genel çekirdekte olmayan bir işaret taşır ve bu tek ayrıntı eksik iki parçayı da açıklar.

Önyükleme girdisini de okuyun, çünkü bir makinede sertifikalı çekirdek kurulu olup yine de çalışmıyor olabilir. Bu durumda modül hikâyesi tamamen farklıdır ve yeniden kurmaya hazırlandığınız bağlantı noktaları ile sürücüler sağlamdır.

İstemci yapılandırmasından önce modül durumunu okuyun

Bulunamayan bir modül ile var olan ama yüklenmeyi reddeden bir modül, farklı düzeltmeleri olan iki farklı arızadır. modinfo hangisine sahip olduğunuzu, lsmod ise şu anda neyin yüklü olduğunu bildirir. VPN istemcisinin yapılandırmasına dokunmadan önce ikisini de yapın, çünkü istemcinin kendi hatası bunları nadiren ayırır.

Kablosuz tarafı da aynı ayrımı gerektirir. Hiç görünmeyen bir arayüz sürücüyü işaret ederken, var olup engellenmiş kalan arayüz rfkill'i veya ağ yöneticisini işaret eder. İkisi masaüstü uygulamasında aynı görünür ve altında hiçbir şeyi paylaşmaz.

Denetimleri, arıza hâlâ yeniden üretilebilirken makinenin kendisinde çalıştırın. Başka bir ana bilgisayardan yapıştırılan çıktı bunun yerini tutmaz.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

modinfo modülü hiç bulamadığında, kullanıcı alanı paketini yeniden kurmak yardımcı olmaz, çünkü eksik parça hiçbir zaman kullanıcı alanı değildi. Bu gözlem bir saatlik paket uğraşını önler ve doğrudan çekirdeği işaret eder.

Size bir çekirdek bırakan sırayla geri dönün

FIPS yanlışlıkla açıldıysa, belgelenmiş kurtarma yolu servisi devre dışı bırakır, paketlerini temizler ve ardından genel çekirdeği geri yükler. Sıra kozmetik değildir. Temizleme, başka bir Ubuntu çekirdeği bulamadığında devam etmeyi reddeder, çünkü tek olanı kaldırmak açılmayan bir makine bırakırdı. Bu denetim, geri alma ile yeniden oluşturma arasındaki farktır. Genel çekirdek daha önce kaldırıldığında dizinin başarısız olmasının nedeni de budur.

Genel çekirdek hâlâ kuruluyken çalıştırın, çekirdek kaldırma uyarısını kabul edin ve ardından yeniden başlatın. Sonra kurulu durumda hiçbir FIPS paketinin kalmadığını ve çalışan çekirdeğin beklediğiniz olduğunu doğrulayın.

Uzak bir ana bilgisayarda önce konsol veya bant dışı erişim sağlayın. SSH üzerinden çekirdek kaldırmak, geri dönmeyen yeniden başlatmaya kadar sorunsuzdur.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

Sertifikasyon gereklilik olduğunda

Sertifikasyon sözleşmeye bağlıysa geri dönmek yanlış hamledir, çünkü makine o zaman denetimin tanımladığı yapılandırmadan çıkar. Bu durumda sürücü boşluğu bir donanım seçimi sorunudur: sürücüsü sertifikalı çekirdekle gelen bir kablosuz bağdaştırıcı seçin, yalnızca kablolu bir makineyi kabul edin veya tüneli sertifikalı çekirdeğin zaten desteklediği bir bileşene taşıyın.

Ağaç dışı bir modülü sertifikalı çekirdeğe derlemek tarafsız bir çözüm değildir. Çekirdeğin neyi yürüttüğünü değiştirir ve sertifikasyonun tanımladığı özellik tam olarak budur.

Kararı sahibinin adıyla birlikte kaydedin, çünkü sadece Wi-Fi çalışsın talebi birkaç ay sonra daha az bağlamla geri gelecektir. Şimdi yazılan kısa bir not, aynı tartışmayı sonra önler.

Değişiklikten sonra yığını katman katman denetleyin

Geri almadan veya donanım değişikliğinden sonra VPN istemcisinden aşağıya değil, aşağıdan yukarıya doğrulayın. Arayüz var olmalı, bağlantı ayakta olmalı, çözümleyici çalışmalı ve ancak o zaman tünel önemlidir. Her katman kendi iletisiyle başarısız olur ve bunları sırayla okumak tanıyı dürüst tutar.

Önceki açılıştan kalan DNS durumu yaygın bir yanlış pozitiftir, bu yüzden tünelin bozulduğu sonucuna varmadan önce çözümleyiciyi okuyun.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

Çekirdek geri geldikten sonra tünel hâlâ başarısız oluyorsa istemcinin özet satırını değil, başarısız olan aşamayı okuyun. Hiç yüklenmemiş bir modül, karşı tarafın reddettiği bir sertifika ve sunucunun reddettiği bir kimlik bilgisi üç ayrı sorundur ve yeniden başlatma bunları sizin yerinize ayırmaz. Aşamanın adını kayda yazın, sonraki mühendis sizin durduğunuz yerden başlar.