ಕಿಲ್ ಸ್ವಿಚ್ ಸಕ್ರಿಯವಾದಾಗ: ತೆರೆದ TCP ಸೆಷನ್ಗಳಿಗೆ ಏನಾಗುತ್ತದೆ?

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

ಬಿಡುವುದು, ತಿರಸ್ಕರಿಸುವುದು ಮತ್ತು ಮರುಹೊಂದಿಸುವುದು ಬೇರೆ ಬೇರೆ

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

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

ಮಧ್ಯಂತರ ಇರುವಾಗ ಅಪ್ಲಿಕೇಶನ್ ಏನು ಮಾಡುತ್ತದೆ

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

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

ಚೇತರಿಕೆ ಅಗತ್ಯವೇ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

ನಿರ್ಬಂಧ ಮತ್ತು ಚೇತರಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

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

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

ನಿರೀಕ್ಷಿತ ವರ್ತನೆಯನ್ನು ಜಾರಿ ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ ಬರೆದು ದಿನಾಂಕ ಹಾಕಿ. ಆ ನಿಯಮವನ್ನು ಬದಲಿಸುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ನಿಯೋಜನೆ ಯಾವ ಒಪ್ಪಂದವನ್ನು ಭರವಸೆ ನೀಡಿತು ಎಂದು ತಿಳಿಯಬೇಕು.