ಫೈರ್‌ವಾಲ್ ಪ್ಯಾಕೇಜ್ ಸ್ಥಾಪನೆಯಾಗಿದೆ, ರೀಬೂಟ್ ನಂತರ ನಿಯಮಗಳು ಮಾಯ

ಪ್ಯಾಕೇಜ್ ಸ್ವಚ್ಛವಾಗಿ ಸ್ಥಾಪನೆಯಾಯಿತು, ನಿಯಮಗಳನ್ನು ಪರೀಕ್ಷಿಸಲಾಯಿತು, ಮತ್ತು ಮುಂದಿನ ರೀಬೂಟ್ ನಂತರ ಗೇಟ್‌ವೇ ಸಂಪೂರ್ಣ ತೆರೆದಿತ್ತು. ವ್ಯವಹಾರದಲ್ಲಿ ಏನೂ ವಿಫಲವಾಗಲಿಲ್ಲ; ವೈಫಲ್ಯವು ಏನು ಉಳಿಯುತ್ತದೆ ಎಂಬ ಊಹೆಯಲ್ಲಿತ್ತು. ಫೈರ್‌ವಾಲ್ ಸಾಧನಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದು, ಯಾವ ನಿಯಮಗಳು ಉಳಿಯಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವುದು ಮತ್ತು ಸರಿಯಾದ ಕ್ಷಣದಲ್ಲಿ ಅವನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದು ಮೂರು ಬೇರೆ ಕೆಲಸಗಳು.

ಲಕ್ಷಣವು ವಾಸ್ತವವಾಗಿ ಏನು ಹೇಳುತ್ತದೆ

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

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

ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಬೇಡಿ.

ಬಳಸುವ ಮೊದಲು ನಿರಂತರತೆ ಸಾಧನವನ್ನು ಓದಿ

ಡೆಬಿಯನ್ ಸಾಧನಗಳು ನಿರಂತರತೆಯನ್ನು ಪ್ಲಗಿನ್ ಸಮಸ್ಯೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತವೆ: ಪ್ರತಿ ಪ್ಲಗಿನ್ ತನ್ನ ನಿಯಮಗಳನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಎಂದು ತಿಳಿದಿದೆ, ಮತ್ತು ಒಂದು ಸುತ್ತುವರಿಕೆ ಅವನ್ನು ಕರೆಯುತ್ತದೆ. ಅದರ ಉಳಿಸುವ ಕ್ರಿಯೆ ಆ ಕ್ಷಣದಲ್ಲಿ ಲೋಡ್ ಆಗಿರುವುದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಪ್ರಾರಂಭ ಕ್ರಿಯೆ ಆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಮತ್ತೆ ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಕ್ರಿಯೆಗಳಲ್ಲಿ ತಾನು ಏನನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಿದೆ ಎಂದು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ.

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

ಏನು ಲೋಡ್ ಆಗಿದೆ ಎಂಬುದನ್ನು ಓದಿದ ನಂತರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಉಳಿಸಿ.

ಏನು ಉಳಿಯಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ

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

ಮೂರು ಕ್ಷಣಗಳಿಗೆ ಉದ್ದೇಶಿತ ಫಲಿತಾಂಶವನ್ನು ಬರೆಯಿರಿ: ಬೂಟ್, VPN ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಸುರಂಗ ನಷ್ಟ. ನಂತರ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಸಾಧನವು ಪ್ರತಿಯೊಂದನ್ನು ವ್ಯಕ್ತಪಡಿಸಬಲ್ಲದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಸ್ಥಿರ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಮತ್ತೆ ಲೋಡ್ ಮಾಡುವ ನಿರಂತರತೆ ಪ್ಯಾಕೇಜ್ ಮೊದಲನೆಯದನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ ಮತ್ತು ಉಳಿದವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ನಿಭಾಯಿಸದಿರಬಹುದು, ಏಕೆಂದರೆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗೆ ಸುರಂಗದ ಸ್ಥಿತಿ ಯಾವಾಗ ಬದಲಾಯಿತು ಎಂಬುದು ತಿಳಿದಿಲ್ಲ. ಅವನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಆ ಕೊರತೆ ಬೇರೆ ಘಟಕಕ್ಕೆ ಸೇರಿದೆ.

ಉತ್ತರವನ್ನು ನೀತಿ ನಿರ್ಧರಿಸುತ್ತದೆ, ಪ್ಯಾಕೇಜ್ ಅಲ್ಲ.

ಮರುಸ್ಥಾಪನೆಯ ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ

ಫೈಲ್ ಮರುಸ್ಥಾಪಿಸುವುದು ಫಲಿತಾಂಶವನ್ನು ಹೊಂದಿರುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ. ಇನ್ನೊಬ್ಬ ನಿರ್ವಾಹಕ ನಿಯಮಗಳನ್ನು ಬದಲಿಸಬಹುದು, ಹಿಂದಿನ ಅನುಮತಿ ಅವನ್ನು ಮರೆಮಾಡಬಹುದು, ಅಥವಾ ನಿರ್ಬಂಧ ಜಾರಿಗೆ ಬರುವ ಮೊದಲೇ ಕ್ಲೈಂಟ್‌ಗಳು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಕೇವಲ ಉಳಿಸಿದ ಫೈಲ್ ಇರುವಿಕೆಯಲ್ಲ, ಪ್ರಾರಂಭ ಮತ್ತು ಮರುಸಂಪರ್ಕದ ವರ್ತನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.

systemctl status netfilter-persistent
iptables -S

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

ಕ್ರಮವು ಚಾಲನೆಯಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಯ ಗುಣ, ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ನದಲ್ಲ.

ಮೂರು ಬೇರೆ ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿ

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

nft list ruleset

ನಂತರ ಅನುಮತಿಸಿದ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಅಗತ್ಯವಾದ ನಿರಾಕರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ.

ರೀಬೂಟ್ ನಂತರ ಮತ್ತು ಸುರಂಗ ಬಿದ್ದ ನಂತರ ನಿರಾಕರಣೆ ಉಳಿದರೆ, ನೀತಿ ಉಳಿಯುತ್ತದೆ. ಅದು ಆ ಸ್ಥಿತಿಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಮಾತ್ರ ಉಳಿದರೆ, ನೀವು ಸರಿಪಡಿಸುವ ಬದಲು ಕ್ರಮದ ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.