VPN ಇಲ್ಲದೆ Git ನಿಲ್ಲುತ್ತದೆಯೇ? OpenSSH IPQoS ನಿಂದ ಪ್ಯಾಕೆಟ್ ಗುರುತಿಸುತ್ತದೆ

ಕಚೇರಿಯಿಂದ ಮಾಡಿದ ಕ್ಲೋನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಫೋನ್ ಹಾಟ್‌ಸ್ಪಾಟ್ ಮೂಲಕ ಅದೇ ಕ್ಲೋನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಹೋಟೆಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಅದೇ ಕ್ಲೋನ್ VPN ಆನ್ ಆಗುವವರೆಗೆ ನೇತಾಡುತ್ತದೆ. SSH ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮುಗಿಯುತ್ತದೆ ಮತ್ತು ಮೊದಲ ನಿಜವಾದ ವರ್ಗಾವಣೆಯಲ್ಲಿ ಸೆಷನ್ ಮೌನವಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಸೇರಿಸಿದ ಒಂದು ಸಾಲು git ಮತ್ತು ssh ಎರಡನ್ನೂ ಜೊತೆಯಾಗಿ ಸರಿಪಡಿಸುತ್ತದೆ. ಒಂದೇ ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್ ಒಟ್ಟಿಗೆ ಹಲವು ಉಪಕರಣಗಳನ್ನು ಸರಿಪಡಿಸಿದಾಗ, ದೋಷವು ಕ್ಲೈಂಟ್ ಕಳುಹಿಸುವುದರಲ್ಲಿದೆ, ಅದು ಕಳುಹಿಸುವ ಕೊಂಡಿಯಲ್ಲಿಲ್ಲ.

ಲಕ್ಷಣವನ್ನು ಮಾರ್ಗದ ವ್ಯತ್ಯಾಸವಾಗಿ ಓದಿ

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

ಸೆಷನ್ ಸಾಯುವ ಬಿಂದು ಇದನ್ನು ಇನ್ನಷ್ಟು ಸಂಕುಚಿಸುತ್ತದೆ. ಹೆಸರಿನ ಹುಡುಕಾಟದಲ್ಲಿ ಅಥವಾ ಕೀ ವಿನಿಮಯದಲ್ಲಿ ವಿಫಲವಾಗುವ ಯಾವುದೂ ಹೀಗೆ ಕಾಣುವುದಿಲ್ಲ. ದೃಢೀಕರಿಸಿ, ಬ್ಯಾನರ್ ಮುದ್ರಿಸಿ, ನಂತರ ಮೊದಲ ದೊಡ್ಡ ಬರವಣಿಗೆಯಲ್ಲಿ ಹೆಪ್ಪುಗಟ್ಟುವ ಸೆಷನ್, ಮಾರ್ಗ, ಹೆಸರು ಮತ್ತು ರುಜುವಾತುಗಳು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ ಎಂದು ಈಗಾಗಲೇ ಸಾಬೀತುಪಡಿಸಿದೆ.

ಕ್ಲೈಂಟ್ ಪ್ರತಿ SSH ಸಾಕೆಟ್‌ಗೆ QoS ಬೈಟ್ ಒತ್ತುತ್ತದೆ

7.8 ರಿಂದ ಪ್ರತಿ OpenSSH ಸಂಪರ್ಕವು IP ಹೆಡರ್‌ನಲ್ಲಿ ರೂಟರ್‌ಗಳು ಸಂಚಾರಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಲು ಬಳಸಬಹುದಾದ ಮೌಲ್ಯವನ್ನು ಹೊತ್ತಿರುತ್ತದೆ. ಟರ್ಮಿನಲ್ ಸೆಷನ್‌ಗಳಿಗೆ ಒಂದು ಮೌಲ್ಯ ಮತ್ತು ದೊಡ್ಡ ಪ್ರತಿಗಳಿಗೆ ಇನ್ನೊಂದು ಸಿಗುತ್ತದೆ, ಟೈಪ್ ಮಾಡುವ ಮನುಷ್ಯ ಫೈಲ್ ವರ್ಗಾವಣೆಗಿಂತ ಉತ್ತಮ ವರ್ತನೆಗೆ ಅರ್ಹ ಎಂಬ ಸಿದ್ಧಾಂತದ ಮೇರೆಗೆ. ಬಹುತೇಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಈ ಸುಳಿವನ್ನು ಸಂಪೂರ್ಣ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದು ವರ್ಷಗಳ ಕಾಲ ಗಮನಕ್ಕೆ ಬರುವುದಿಲ್ಲ. ಕೆಲವೇ Wi-Fi ಡ್ರೈವರ್‌ಗಳು, ಮೊಬೈಲ್ ಆಪರೇಟರ್‌ಗಳು ಮತ್ತು VPN ಕೇಂದ್ರೀಕರಣಕಾರರು ಅದರ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವರಲ್ಲಿ ಕೆಲವರು ಕೆಟ್ಟದಾಗಿ ವರ್ತಿಸುತ್ತಾರೆ.

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

ಮೊದಲು ssh -V ನಿಂದ ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಯನ್ನು ಖಚಿತಪಡಿಸಿ. 7.8 ಅಥವಾ ಹೆಚ್ಚಿನ ಯಾವುದೇ ಆವೃತ್ತಿ ಈ ವರ್ತನೆಯನ್ನು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಹೊಂದಿದೆ.

ಇದನ್ನು MTU ಮತ್ತು DNS ನಿಂದ ಬೇರ್ಪಡಿಸುವ ಮೂರು ಆದೇಶಗಳು

ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಎರಡು ಸಮಾನ ಕಾರಣಗಳನ್ನು ಹೊರಗಿಡಬೇಕು. MTU ದೋಷವು ಸಣ್ಣ ವಿನಿಮಯಗಳನ್ನು ದಾಟಿಸಿ ಮೊದಲ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ, ಆದರೆ ಹೆಸರಿನ ದೋಷವು ಎಂದಿಗೂ ಸೆಷನ್ ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

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

ವರ್ಗಾವಣೆಯನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಮಾಡಿ, ಏಕೆಂದರೆ ಮೌಲ್ಯವನ್ನು ಕಳುಹಿಸುವವನು ಇಡುತ್ತಾನೆ ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳು ಅದನ್ನು ಬದಲಿಸಬಹುದು. ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ವಿಫಲವಾಗುವ ಮಾರ್ಗವನ್ನು ಅದೇ ಸೆರೆಹಿಡಿಯುವಿಕೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ಊಹೆ ಇಲ್ಲದೆ ವ್ಯತ್ಯಾಸ ಕಾಣುತ್ತದೆ.

ವಿನಾಯಿತಿಯನ್ನು ಒಂದು ಫೈಲ್‌ನಲ್ಲಿ ಇರಿಸಿ, ಒಂದು ಸಲಕ್ಕೆ ಒಂದು ಹೋಸ್ಟ್

ವಿನಾಯಿತಿಯು ಅನ್ವಯವಾಗುವ ಹೋಸ್ಟ್‌ನ ಪಕ್ಕದಲ್ಲಿರಬೇಕು, ಅದು ಏಕೆ ಇದೆ ಎಂದು ಹೇಳುವ ಟಿಪ್ಪಣಿಯೊಂದಿಗೆ.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

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

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

ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರೊಂದಿಗೆ ವೃತ್ತ ಮುಚ್ಚಿ

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

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

ಕ್ಲೈಂಟ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆ ಮುಕ್ತಾಯ ದಿನಾಂಕವಿರುವ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರ. ಆ ದಿನಾಂಕವನ್ನು ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಬರೆಯಿರಿ.