Linux IPsec ಗೇಟ್‌ವೇಯಲ್ಲಿ TCP MSS ಕ್ಲ್ಯಾಂಪಿಂಗ್: ಅದು ಏನನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ

Ping ಕೆಲಸ ಮಾಡುತ್ತದೆ, SSH ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಒಂದು ಸಣ್ಣ ಪುಟ ಲೋಡ್ ಆಗುತ್ತದೆ, ನಂತರ ಪ್ರತಿ ದೊಡ್ಡ ಪ್ರತಿಕ್ರಿಯೆಯೂ ಸಮಯ ಮುಗಿಯುವವರೆಗೆ ನಿಲ್ಲುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ ಮಾದರಿ ತಲುಪುವಿಕೆಯನ್ನಲ್ಲ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಸೂಚಿಸುತ್ತದೆ: ಮಾರ್ಗವು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮತ್ತು ಮೊದಲ ಕೆಲವು ಕಿಲೋಬೈಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ನಂತರ ಪೂರ್ಣ ಗಾತ್ರದ ವಿಭಾಗ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. Linux IPsec ಗೇಟ್‌ವೇಯಲ್ಲಿ TCP MSS ನಿಯಮವು ಹೆಚ್ಚಾಗಿ ಪರಿಹಾರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಅದು ಏನನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಸ್ಪರ್ಶಿಸುವ ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ ಮಾತ್ರ. ಕೆಳಗಿನ ಕ್ರಮವು ರೋಗಲಕ್ಷಣದಿಂದ ನಿಯಮದ ಸ್ಥಾನದವರೆಗೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿವರಣೆ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ತಕ್ಷಣ ನೀವು ನಿಲ್ಲಿಸಬಹುದು.

MSS ಅನ್ನು ಸೂಚಿಸುವ ರೋಗಲಕ್ಷಣ

TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಲ್ಲಿ ಗರಿಷ್ಠ ವಿಭಾಗ ಗಾತ್ರದ ಬಗ್ಗೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ. ಆ ಮೌಲ್ಯವು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ನಂತರ ಮಾರ್ಗವು ಸಾಗಿಸಬಹುದಾದ್ದಕ್ಕಿಂತ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಕಳುಹಿಸುವವನು ಎಂದಿಗೂ ತಲುಪದ ವಿಭಾಗಗಳನ್ನು ಉತ್ಪಾದಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾನೆ, ಮತ್ತು ಮೊದಲ ಸುತ್ತಿನ ನಂತರ ಸಂಪರ್ಕ ನಿಲ್ಲುತ್ತದೆ. ಸಣ್ಣ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಹೊಂದುತ್ತವೆ; ದೊಡ್ಡವು ಹೊಂದುವುದಿಲ್ಲ.

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

TCPMSS ನಿಯಮ ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನು ಮಾಡುವುದಿಲ್ಲ

ನಿಯಮವು TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪ್ಯಾಕೆಟ್‌ಗಳು ಹಾದುಹೋಗುವಾಗ ಅವುಗಳಲ್ಲಿನ MSS ಆಯ್ಕೆಯನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. ಅದು ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್‌ನ MTU ಅನ್ನು ಹೊಂದಿಸುವುದಿಲ್ಲ, IPsec ನೀತಿಯನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರಸ್ತುತ ಕರ್ನೆಲ್‌ಗಳಲ್ಲಿ ಈಗಾಗಲೇ ಚಿಕ್ಕದಾದ ಮೌಲ್ಯವನ್ನು ಹೆಚ್ಚಿಸುವ ಬದಲು ಘೋಷಿತ ಮೌಲ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಅದು TCP ಅನ್ನು ಮಾತ್ರ ಸ್ಪರ್ಶಿಸುತ್ತದೆ; UDP ಪೇಲೋಡ್‌ಗಳು, DNS ವರ್ತನೆ ಮತ್ತು ಮಾತುಕತೆಯಾದ ಟ್ರಾಫಿಕ್ ಆಯ್ಕೆಗಾರರು ಅದರ ಪರಿಧಿಯ ಹೊರಗಿವೆ.

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

ನಿಯಮವನ್ನು ಒಳಗಿನ TCP ಮಾರ್ಗದಲ್ಲಿ ಇರಿಸಿ

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

iptables ಪರಿಭಾಷೆಯಲ್ಲಿ ನಿಯಮವು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮಾರ್ಗದ mangle ಕೋಷ್ಟಕಕ್ಕೆ ಸೇರುತ್ತದೆ, ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. ಸಂಖ್ಯೆ ಒಂದು ಉದಾಹರಣೆ, ಸಾರ್ವತ್ರಿಕ ಸ್ಥಿರಾಂಕವಲ್ಲ; ಅದನ್ನು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಓವರ್‌ಹೆಡ್ ಮತ್ತು ಮಾರ್ಗದ ನಿಜವಾದ MTU ನಿಂದ ಪಡೆಯಿರಿ. nftables ಸಮಾನವಾದದ್ದು forward ಅಥವಾ postrouting ಸರಪಳಿಯಲ್ಲಿ ಗರಿಷ್ಠ ವಿಭಾಗ ಗಾತ್ರವನ್ನು ಹೊಂದಿಸುತ್ತದೆ.

IKE ಮತ್ತು ESP ಗಾಗಿ ಹೊರಗಿನ ಆಲಿಸುವ ನಿಯಮಗಳನ್ನು ಒಳಗಿನ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿಯಮಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಹರಿವು ಮತ್ತು ಹೊರಗಿನ ಪ್ರೋಟೋಕಾಲ್ ಎರಡನ್ನೂ ಅಧಿಕೃತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಒಂದೇ ನಿಯಮವು ಕೊನೆಗೆ ಎರಡರೊಂದಿಗೂ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ಫೈರ್‌ವಾಲ್‌ನ ಮಾಲೀಕ ಮತ್ತು NAT ಕ್ರಮವನ್ನು ಗೌರವಿಸಿ

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

ಮೂಲ ಅನುವಾದವು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರವಾಗಿದ್ದು ಅದು ಹೆಚ್ಚಾಗಿ ಇದರೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯ masquerade ನಿಯಮದ ಮೊದಲು ಇರಿಸಿದ ವಿನಾಯಿತಿಯು ಸಂರಕ್ಷಿತ ಸಂಚಾರವು ಅದರ ನೀತಿ ಬಯಸುವ ಮೂಲವನ್ನು ಕಳೆದುಕೊಳ್ಳದಂತೆ ತಡೆಯುತ್ತದೆ; ಅದು ಗಾತ್ರದ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಗಾತ್ರದ ನಿಯಮವು ಅನುವಾದದ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಸಂಕುಚಿತವಾಗಿ ಪರಿಶೀಲಿಸಿ, ನಂತರ ನಿಲ್ಲಿಸಿ

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

ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿ ICMP ಗಾತ್ರ-ಪ್ರತಿಕ್ರಿಯೆ ಕೆಲಸ ಮಾಡಲಿ, ಮತ್ತು ಹೊರಗಿನ IPsec ಮಾರ್ಗವು ಒಳಗಿನ ರೂಟ್‌ನಿಂದ ಪ್ರತಿನಿಧಿಸದಿದ್ದಾಗ ಮಾರ್ಗ-MTU ಆಧಾರಿತ ಸ್ವಯಂಚಾಲಿತ ಕ್ಲ್ಯಾಂಪಿಂಗ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸಿ. ತೀರ್ಮಾನವು ಎಷ್ಟು ಸಂಕುಚಿತವೋ, ಮುಂದಿನ ಘಟನೆಯನ್ನು ರೋಗನಿರ್ಣಯ ಮಾಡುವುದು ಅಷ್ಟು ಸುಲಭ.