fips-updates ಆನ್ ಮಾಡಿ, ರೀಬೂಟ್ ಮಾಡಿ, ಮತ್ತು ಯಂತ್ರವು ವೈರ್ಲೆಸ್ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲದೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಆದರೆ VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಇಲ್ಲದ ಕಾರಣ ಪ್ರಾರಂಭವಾಗಲು ನಿರಾಕರಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯ ಪ್ಯಾಕೇಜ್ ಅರ್ಥದಲ್ಲಿ ಏನೂ ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ಆಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಮರುಸ್ಥಾಪಿಸಿದರೂ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಯಂತ್ರವು ತನ್ನ ಡ್ರೈವರ್‌ಗಳನ್ನು ಎಂದೂ ನಿರ್ಮಿಸದ ಕರ್ನಲ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಎರಡು ಲಕ್ಷಣಗಳು, ಒಂದು ಕಾರಣ, ಮತ್ತು ಕಾರಣ ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ಕಾಣುತ್ತದೆ.

ರೀಬೂಟ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಬದಲಿಸಿತು

Ubuntu Pro ನ FIPS ನವೀಕರಣಗಳು ಪ್ರಮಾಣೀಕೃತ ಕರ್ನಲ್ ರೂಪಾಂತರವನ್ನು ಸ್ಥಾಪಿಸಿ ಅದನ್ನು ಡೀಫಾಲ್ಟ್ ಬೂಟ್ ನಮೂದಾಗಿ ಮಾಡುತ್ತವೆ. ಆ ರೂಪಾಂತರ ನಿಜವಾದ ಕರ್ನಲ್: ಅದು ಬೂಟ್ ಆಗುತ್ತದೆ, ಚಾಲನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಬಳಿ ಈಗಾಗಲೇ ಇದ್ದ ಸೇವೆಗಳನ್ನು ಆರಂಭಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಇಲ್ಲದಿರುವುದು ಸಾಮಾನ್ಯ ಕರ್ನಲ್‌ಗಾಗಿ ನಿರ್ಮಿಸಿದ ಪ್ರತಿ ಮಾಡ್ಯೂಲ್, ಅಂದರೆ ಮರದ ಹೊರಗೆ ಸಂಕಲಿಸಿದ ವೈರ್ಲೆಸ್ ಡ್ರೈವರ್ ಮತ್ತು DKMS ಮೂಲಕ ಒದಗಿಸುವ ಟನೆಲ್ ಮಾಡ್ಯೂಲ್. ಡ್ರೈವರ್ ಗುಂಪು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಜೊತೆಗಲ್ಲ, ಕರ್ನಲ್‌ನೊಂದಿಗೆ ಚಲಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಯಂತ್ರಾಂಶ ಇನ್ನೂ ಇದೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಮಾತನಾಡುವ ತಂತ್ರಾಂಶ ಇಲ್ಲ.

ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್ ಸೆಟ್ಟಿಂಗ್ ತೆರೆಯುವ ಮೊದಲು ಚಾಲನೆಯಲ್ಲಿರುವ ಕರ್ನಲ್ ಅನ್ನು ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಆವೃತ್ತಿ ಸರಣಿಯು ಸಾಮಾನ್ಯ ಕರ್ನಲ್‌ನಲ್ಲಿ ಇಲ್ಲದ ಗುರುತನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಆ ಒಂದು ವಿವರವೇ ಕಾಣೆಯಾದ ಎರಡೂ ಭಾಗಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಬೂಟ್ ನಮೂದನ್ನು ಸಹ ಓದಿ, ಏಕೆಂದರೆ ಯಂತ್ರದಲ್ಲಿ ಪ್ರಮಾಣೀಕೃತ ಕರ್ನಲ್ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೂ ಅದು ಚಾಲನೆಯಲ್ಲಿಲ್ಲದಿರಬಹುದು. ಆ ಸಂದರ್ಭದಲ್ಲಿ ಮಾಡ್ಯೂಲ್‌ಗಳ ಕಥೆ ಸಂಪೂರ್ಣ ಬೇರೆ, ಮತ್ತು ನೀವು ಮರುಸ್ಥಾಪಿಸಲು ಹೊರಟಿದ್ದ ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಡ್ರೈವರ್‌ಗಳು ಸರಿಯಾಗಿವೆ.

ಕ್ಲೈಂಟ್ ಸಂರಚನೆಗೆ ಮೊದಲು ಮಾಡ್ಯೂಲ್ ಸ್ಥಿತಿ ಓದಿ

ಸಿಗದ ಮಾಡ್ಯೂಲ್ ಮತ್ತು ಇದ್ದರೂ ಲೋಡ್ ಆಗಲು ನಿರಾಕರಿಸುವ ಮಾಡ್ಯೂಲ್ ಬೇರೆ ಬೇರೆ ದೋಷಗಳು, ಬೇರೆ ಬೇರೆ ಪರಿಹಾರಗಳೊಂದಿಗೆ. modinfo ನಿಮ್ಮಲ್ಲಿ ಯಾವುದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು lsmod ಈಗ ಏನು ಲೋಡ್ ಆಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. VPN ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಎರಡನ್ನೂ ಮಾಡಿ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ದೋಷ ಅವುಗಳನ್ನು ಅಪರೂಪವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತದೆ.

ವೈರ್ಲೆಸ್‌ಗೂ ಅದೇ ವಿಂಗಡಣೆ ಬೇಕು. ಎಂದೂ ಕಾಣದ ಇಂಟರ್ಫೇಸ್ ಡ್ರೈವರ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಇದ್ದು ತಡೆಯಲ್ಪಟ್ಟಿರುವುದು rfkill ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜರ್‌ಗೆ. ಎರಡೂ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲೆಟ್‌ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಒಳಗೆ ಏನನ್ನೂ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ದೋಷ ಇನ್ನೂ ಪುನರಾವರ್ತಿಸಬಹುದಾದಾಗಲೇ ಯಂತ್ರದ ಮೇಲೆಯೇ ಪರಿಶೀಲನೆಗಳನ್ನು ನಡೆಸಿ. ಇನ್ನೊಂದು ಹೋಸ್ಟ್‌ನಿಂದ ಅಂಟಿಸಿದ ಔಟ್‌ಪುಟ್ ಇದಕ್ಕೆ ಪರ್ಯಾಯವಲ್ಲ.

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

modinfo ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಂಡುಕೊಳ್ಳದಿದ್ದರೆ, ಬಳಕೆದಾರ ಸ್ಥಳ ಪ್ಯಾಕೇಜ್ ಮರುಸ್ಥಾಪಿಸಿದರೂ ಸಹಾಯವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಬಳಕೆದಾರ ಸ್ಥಳ ಎಂದೂ ಕಾಣೆಯಾದ ಭಾಗವಾಗಿರಲಿಲ್ಲ. ಆ ಅವಲೋಕನ ಒಂದು ಗಂಟೆಯ ಪ್ಯಾಕೇಜ್ ರಗಳೆಯನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ನೇರವಾಗಿ ಕರ್ನಲ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ.

ನಿಮಗೆ ಕರ್ನಲ್ ಉಳಿಸುವ ಕ್ರಮದಲ್ಲಿ ಹಿಂತಿರುಗಿ

FIPS ತಪ್ಪಾಗಿ ಸಕ್ರಿಯಗೊಂಡಿದ್ದರೆ, ದಾಖಲಿತ ಚೇತರಿಕೆ ಮಾರ್ಗ ಸೇವೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ, ಅದರ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಅಳಿಸಿ ನಂತರ ಸಾಮಾನ್ಯ ಕರ್ನಲ್ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ. ಕ್ರಮ ಅಲಂಕಾರಿಕವಲ್ಲ. ಇನ್ನೊಂದು Ubuntu ಕರ್ನಲ್ ಸಿಗದಿದ್ದಾಗ ಅಳಿಸುವಿಕೆ ಮುಂದುವರಿಯಲು ನಿರಾಕರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಏಕೈಕವನ್ನು ತೆಗೆದರೆ ಬೂಟ್ ಆಗದ ಯಂತ್ರ ಉಳಿಯುತ್ತದೆ. ಆ ಪರಿಶೀಲನೆಯೇ ಹಿಂತಿರುಗುವಿಕೆ ಮತ್ತು ಮರುನಿರ್ಮಾಣದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ಸಾಮಾನ್ಯ ಕರ್ನಲ್ ಈಗಾಗಲೇ ತೆಗೆದುಹಾಕಲ್ಪಟ್ಟಿದ್ದರೆ ಈ ಕ್ರಮ ವಿಫಲವಾಗುವುದಕ್ಕೂ ಅದೇ ಕಾರಣ.

ಸಾಮಾನ್ಯ ಕರ್ನಲ್ ಇನ್ನೂ ಸ್ಥಾಪಿತವಾಗಿರುವಾಗಲೇ ಅದನ್ನು ನಡೆಸಿ, ಕರ್ನಲ್ ತೆಗೆಯುವ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆ ಸ್ವೀಕರಿಸಿ, ನಂತರ ರೀಬೂಟ್ ಮಾಡಿ. ನಂತರ ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಯಲ್ಲಿ ಯಾವುದೇ FIPS ಪ್ಯಾಕೇಜ್ ಉಳಿದಿಲ್ಲ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಕರ್ನಲ್ ನೀವು ನಿರೀಕ್ಷಿಸಿದ್ದೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ದೂರದ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮೊದಲು ಕನ್ಸೋಲ್ ಅಥವಾ ಔಟ್-ಆಫ್-ಬ್ಯಾಂಡ್ ಪ್ರವೇಶವನ್ನು ಏರ್ಪಡಿಸಿ. SSH ಮೂಲಕ ಕರ್ನಲ್ ತೆಗೆಯುವುದು ಹಿಂತಿರುಗದ ರೀಬೂಟ್‌ವರೆಗೆ ಸರಿಯಾಗಿದೆ.

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

ಪ್ರಮಾಣೀಕರಣವೇ ಅಗತ್ಯವಾದಾಗ

ಪ್ರಮಾಣೀಕರಣ ಒಪ್ಪಂದದ್ದಾಗಿದ್ದರೆ ಹಿಂತಿರುಗುವುದು ತಪ್ಪು ಕ್ರಮ, ಏಕೆಂದರೆ ಆಗ ಯಂತ್ರವು ಆಡಿಟ್ ವಿವರಿಸುವ ಸಂರಚನೆಯಿಂದ ಹೊರಬರುತ್ತದೆ. ಆ ಸಂದರ್ಭದಲ್ಲಿ ಡ್ರೈವರ್ ಕೊರತೆ ಯಂತ್ರಾಂಶ ಆಯ್ಕೆಯ ಪ್ರಶ್ನೆ: ಡ್ರೈವರ್ ಪ್ರಮಾಣೀಕೃತ ಕರ್ನಲ್ ಜೊತೆ ಬರುವ ವೈರ್ಲೆಸ್ ಅಡಾಪ್ಟರ್ ಆರಿಸಿ, ಕೇಬಲ್ ಮಾತ್ರವಿರುವ ಯಂತ್ರವನ್ನು ಒಪ್ಪಿ, ಅಥವಾ ಪ್ರಮಾಣೀಕೃತ ಕರ್ನಲ್ ಈಗಾಗಲೇ ಬೆಂಬಲಿಸುವ ಘಟಕಕ್ಕೆ ಟನೆಲ್ ಸರಿಸಿ.

ಪ್ರಮಾಣೀಕೃತ ಕರ್ನಲ್‌ಗೆ ಮರದ ಹೊರಗಿನ ಮಾಡ್ಯೂಲ್ ನಿರ್ಮಿಸುವುದು ತಟಸ್ಥ ಪರಿಹಾರವಲ್ಲ. ಅದು ಕರ್ನಲ್ ಏನನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಮಾಣೀಕರಣ ವಿವರಿಸುವುದು ನಿಖರವಾಗಿ ಆ ಗುಣವನ್ನೇ.

ನಿರ್ಣಯವನ್ನು ಮಾಲೀಕರ ಹೆಸರಿನೊಂದಿಗೆ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಕೇವಲ Wi-Fi ಕೆಲಸ ಮಾಡಲಿ ಎಂಬ ವಿನಂತಿ ಕೆಲವು ತಿಂಗಳ ನಂತರ ಕಡಿಮೆ ಸಂದರ್ಭದೊಂದಿಗೆ ಹಿಂತಿರುಗುತ್ತದೆ. ಈಗಿನ ಚಿಕ್ಕ ಟಿಪ್ಪಣಿ ಮುಂದೆ ಅದೇ ವಾದವನ್ನು ತಡೆಯುತ್ತದೆ.

ಬದಲಾವಣೆಯ ನಂತರ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಪದರಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ

ಹಿಂತಿರುಗುವಿಕೆ ಅಥವಾ ಯಂತ್ರಾಂಶ ಬದಲಾವಣೆಯ ನಂತರ VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ಕೆಳಕ್ಕೆ ಅಲ್ಲ, ಕೆಳಗಿನಿಂದ ಮೇಲಕ್ಕೆ ಪರಿಶೀಲಿಸಿ. ಇಂಟರ್ಫೇಸ್ ಇರಲೇಬೇಕು, ಲಿಂಕ್ ಮೇಲಿರಲೇಬೇಕು, ರೆಸಾಲ್ವರ್ ಕೆಲಸ ಮಾಡಲೇಬೇಕು, ಮತ್ತು ಆಗಷ್ಟೇ ಟನೆಲ್ ಮುಖ್ಯ. ಪ್ರತಿ ಪದರವೂ ತನ್ನದೇ ಸಂದೇಶದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅವನ್ನು ಕ್ರಮದಲ್ಲಿ ಓದುವುದು ನಿರ್ಣಯವನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿರಿಸುತ್ತದೆ.

ಹಿಂದಿನ ಬೂಟ್‌ನಿಂದ ಉಳಿದ DNS ಸ್ಥಿತಿ ಸಾಮಾನ್ಯ ಸುಳ್ಳು ಸೂಚನೆ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಮುರಿದಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ರೆಸಾಲ್ವರ್ ಓದಿ.

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

ಕರ್ನಲ್ ಹಿಂತಿರುಗಿದ ನಂತರವೂ ಟನೆಲ್ ವಿಫಲವಾದರೆ, ಕ್ಲೈಂಟ್‌ನ ಸಾರಾಂಶ ಸಾಲಿನ ಬದಲು ವಿಫಲವಾಗುವ ಹಂತವನ್ನು ಓದಿ. ಎಂದೂ ಲೋಡ್ ಆಗದ ಮಾಡ್ಯೂಲ್, ಎದುರು ತುದಿ ತಿರಸ್ಕರಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಸರ್ವರ್ ನಿರಾಕರಿಸಿದ ರುಜುವಾತು ಮೂರು ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು, ಮತ್ತು ರೀಬೂಟ್ ನಿಮ್ಮ ಪರವಾಗಿ ಅವನ್ನು ಬೇರ್ಪಡಿಸುವುದಿಲ್ಲ. ಟಿಕೆಟ್‌ನಲ್ಲಿ ಹಂತದ ಹೆಸರು ಬರೆಯಿರಿ, ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ನೀವು ನಿಂತಲ್ಲಿಂದ ಆರಂಭಿಸುತ್ತಾರೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು