1,500 ಬೈಟ್‌ನ ಸ್ಥಿರ ಒಳ ಪ್ಯಾಕೆಟ್ ಅನ್ನು VPN ಮೂಲಕ ಸಾಗಿಸುವುದು

ನಿಮಗೆ ಬಾಗದ ಅಗತ್ಯವಿದೆ: ಕಳುಹಿಸುವವನು ಹೊರಡಿಸುವ ಅದೇ 1,500 ಬೈಟ್ IP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಶೀರ್ಷಿಕೆಗಳ ಸಹಿತ ಆಚೆಯ ಬದಿ ಸ್ವೀಕರಿಸಬೇಕು. ಟನೆಲ್ ಆ ಪ್ಯಾಕೆಟ್ ಮತ್ತು ತನ್ನದೇ ಫ್ರೇಮಿಂಗ್ ಅನ್ನು ಎರಡನೇ 1,500 ಬೈಟ್ IP ಪ್ಯಾಕೆಟ್ ಒಳಗೆ ಸುತ್ತಲಾರದು, ಆದ್ದರಿಂದ ವಿನ್ಯಾಸದಲ್ಲಿ ಏನಾದರೂ ಬಿಟ್ಟುಕೊಡಬೇಕು. ಕೆಳಗಿನ ಕ್ರಮ ನಾನು ಬದಲಾವಣೆ ವಿಂಡೋದಲ್ಲಿ ಬಳಸುವ ಕ್ರಮ: ಬೈಟ್ ಬಜೆಟ್ ಬರೆಯಿರಿ, ಅಂಡರ್‌ಲೇ ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಗಿಸಬಲ್ಲದೆಂದು ಸಾಬೀತು ಮಾಡಿ, ನಂತರ ನಿಖರವಾಗಿ ಒಂದು ಸಾಗಣೆ ವಿಧಾನ ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಆಚೆಯ ಬದಿಯಲ್ಲಿ ಒಳ ಪ್ಯಾಕೆಟ್ ದೃಢೀಕರಿಸಿ.

ಪ್ರೊಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಬೈಟ್ ಬಜೆಟ್ ಬರೆಯಿರಿ

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

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

do-not-fragment ping ಬಳಸಿ ಅಂಡರ್‌ಲೇ ಪರೀಕ್ಷಿಸಿ

ಇಂಟರ್‌ಫೇಸ್ MTU ಅನ್ನು ನಂಬದೆ ಮಾರ್ಗವನ್ನು ಅಳೆಯಿರಿ, ಏಕೆಂದರೆ ಹೊರ ಮಾರ್ಗದ ಅತಿ ಚಿಕ್ಕ ಕೊಂಡಿ ಮುಖ್ಯ. Linux ನಲ್ಲಿ, -M do do-not-fragment ಬಿಟ್ ಸೆಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು -s ICMP ಪೇಲೋಡ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ 20 ಬೈಟ್ IP ಶೀರ್ಷಿಕೆ ಮತ್ತು 8 ಬೈಟ್ ICMP ಶೀರ್ಷಿಕೆ ಕಳೆದಾಗ 1,500 ಬೈಟ್ ಫ್ರೇಮ್ 1,472 ಬೈಟ್ ಪೇಲೋಡ್‌ನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆ ವಿಫಲವಾಗುವವರೆಗೆ ಪೇಲೋಡ್ ಹೆಚ್ಚಿಸಿ, ನಂತರ ಜಂಬೋ ಗಾತ್ರಕ್ಕೆ ಜಿಗಿಯಿರಿ ಮತ್ತು ಮಾರ್ಗ ಅದನ್ನು ಸಾಗಿಸುತ್ತದೆಯೇ ನೋಡಿ.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

1,472 ರಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿ 8,972 ರಲ್ಲಿ ವಿಫಲವಾಗುವ ಮಾರ್ಗವು 1,500 ಬೈಟ್ ಒಳ ಪ್ಯಾಕೆಟ್ ಮತ್ತು ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಒಂದೇ ಹೊರ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಸಾಗಿಸಲಾರದು. VPN ಸಂರಚನೆ ತೆರೆಯುವ ಮೊದಲು ನಿಮಗೆ ಬೇಕಿದ್ದ ಉತ್ತರ ಇದು. ಮುಂದಿನ ಎರಡು ವಿಭಾಗಗಳಲ್ಲಿ ಯಾವುದು ನಿಮಗೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನೂ ಇದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡೂ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳನ್ನು ಟಿಕೆಟ್ ಪಕ್ಕ ಇಡಿ. ಇಲ್ಲಿ ಊಹಿಸುವುದು ಒಂದು ನಿರ್ವಹಣಾ ವಿಂಡೋವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ತಾನು up ಎಂದು ವರದಿ ಮಾಡುವ ಟನೆಲ್ ಮಾರ್ಗ ಸ್ವೀಕರಿಸುವ ಅತಿ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಪ್ರತಿ ಹಾಪ್ ಒಪ್ಪುವಲ್ಲಿಯೇ ಮಾರ್ಗ MTU ಹೆಚ್ಚಿಸಿ

ಜಂಬೋ ಫ್ರೇಮ್‌ಗಳು end-to-end ಗುಣಲಕ್ಷಣ, ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ನಿಯಂತ್ರಿಸುವ ಎರಡು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸುವ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. ಹೊರ ಮಾರ್ಗದ ಪ್ರತಿ ಸ್ವಿಚ್, ರೂಟರ್ ಮತ್ತು ಪೂರೈಕೆದಾರರ ಹಸ್ತಾಂತರವು ದೊಡ್ಡ ಗಾತ್ರಕ್ಕೆ ಒಪ್ಪಬೇಕು, ಮತ್ತು ಒಂದೇ 1,500 ಬೈಟ್ ಹಾಪ್ ನೀವು ಈಗಷ್ಟೇ ದೊಡ್ಡದಾಗಿಸಿದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡುತ್ತದೆ. ಸ್ಥಳೀಯ ಇಂಟರ್‌ಫೇಸ್ ಮಾತ್ರ ಹೆಚ್ಚಿಸುವುದು ಟನೆಲ್ ಮುರಿದಂತೆ ಕಾಣಿಸುವ, ಆದರೆ ಅಂಡರ್‌ಲೇ ಸದ್ದಿಲ್ಲದೆ ಬೀಳಿಸುವ ಸಾಂಪ್ರದಾಯಿಕ ಅರ್ಧ ಬದಲಾವಣೆ.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

ಇಂಟರ್‌ಫೇಸ್ ಬದಲಿಸಿ, ನಂತರ ಬೇರೆ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಅದೇ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. ಪರೀಕ್ಷೆ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಹಿಂತಿರುಗಿಸಿ ip link set dev eth1 mtu 1500 ಮತ್ತು ನಿಮ್ಮದಲ್ಲದ ಲಿಂಕ್ ಬಗ್ಗೆ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ವಾದಿಸುವ ಬದಲು ಫ್ರಾಗ್ಮೆಂಟೇಶನ್‌ಗೆ ಹೋಗಿ.

ಅಂಡರ್‌ಲೇ ಬೆಳೆಯಲಾಗದಿದ್ದಾಗ ಟನೆಲ್ ಫ್ರಾಗ್ಮೆಂಟೇಶನ್ ಬಳಸಿ

ಒಳ ಪ್ಯಾಕೆಟ್‌ನ ಕೆಳಗೆ ಬೆಂಬಲಿತ ಫ್ರಾಗ್ಮೆಂಟೇಶನ್ ವಿಧಾನವು ಹಲವು ಹೊರ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಒಂದು ಒಳ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ, ಮತ್ತು ಆಚೆಯ ಟನೆಲ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮೂಲವನ್ನು ಸ್ಟ್ಯಾಕ್‌ಗೆ ನೀಡುವ ಮೊದಲು ಅವನ್ನು ಮರುಜೋಡಿಸುತ್ತದೆ. Community OpenVPN ನ UDP fragment ಆಯ್ಕೆ ಆ ಕಲ್ಪನೆಯ ಒಂದು ಅನುಷ್ಠಾನ, ಮತ್ತು ಹೊರ ಪ್ಯಾಕೆಟ್‌ನ ಸಾಮಾನ್ಯ IP ಫ್ರಾಗ್ಮೆಂಟೇಶನ್‌ಗಿಂತ ಬೇರೆಯದು. ಎರಡೂ ಪೀರ್‌ಗಳು ಆ ಸ್ವರೂಪವನ್ನು ಬೆಂಬಲಿಸುವ ಆವೃತ್ತಿ ಚಲಾಯಿಸಬೇಕು, ಮತ್ತು ದತ್ತಾಂಶ ಮಾರ್ಗ ನೀವು ಭಾವಿಸುವಂತೆಯೇ ಇರಬೇಕು: OpenVPN 3 ಕ್ಲೈಂಟ್‌ಗಳ ಮತ್ತು ಕರ್ನಲ್-ವೇಗವರ್ಧಿತ ದತ್ತಾಂಶ ಚಾನೆಲ್‌ಗಳ ಮಿತಿಗಳು ಬೇರೆ, ಆದ್ದರಿಂದ ಒಂದು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಇನ್ನೊಂದರಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

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

ಸ್ಟ್ರೀಮ್ ಆಧಾರಿತ ಹೊರ ವಾಹಕ ತನ್ನದೇ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ವಿಭಜಿಸಿ ಗಾತ್ರದ ಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಿಕೊಳ್ಳದೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಮರುನಿರ್ಮಿಸಿದ ಒಳ ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ 1,500 ಬೈಟ್ ಆಗಿರಬಹುದು. ಇದು ತನ್ನದೇ ವೆಚ್ಚವಿರುವ ಸಾಗಣೆ ನಿರ್ಧಾರ, TCP ಒಳಗಿನ TCP ಯ ಪರಿಚಿತ ನಡವಳಿಕೆ ಸೇರಿದಂತೆ, ಆದ್ದರಿಂದ MTU ವಾದದ ಅಡ್ಡಪರಿಣಾಮವಾಗಿ ಅಲ್ಲ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾಡಿ.

ಒಳ ಪ್ಯಾಕೆಟ್ ಬದಲಾಗದೆ ತಲುಪುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ

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

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

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

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