WireGuard ಒಳಗಿನ IPIP: ಯಾರೂ ಬಜೆಟ್‌ನಲ್ಲಿ ಸೇರಿಸದ ಆ ಹೆಚ್ಚುವರಿ 20 ಬೈಟ್‌ಗಳು
IPIP WireGuard ಒಳಗೆ 20 ಹೆಚ್ಚುವರಿ ಬೈಟ್ ವೆಚ್ಚ ಮಾಡುತ್ತದೆ. ಜೀವಂತ ಟನೆಲ್‌ನಲ್ಲಿ ನಿಂತಿರುವ ವರ್ಗಾವಣೆಗೆ ತುಣುಕುಗೊಳಿಸುವಿಕೆಯನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸರಿಯಾದ ಪದರದಲ್ಲಿ ಬಜೆಟ್ ಮಾಡಿ.
ಸಣ್ಣ ping ಗಳು ದಿನವಿಡೀ ಟನೆಲ್ ದಾಟುತ್ತವೆ, SSH ಬ್ಯಾನರ್ ಬರುತ್ತದೆ, ನಂತರ ಫೈಲ್ ವರ್ಗಾವಣೆ ಆರಂಭವಾದ ಕ್ಷಣದಲ್ಲಿ ಸೆಷನ್ ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ. ಈ ಮಾದರಿ ತಪ್ಪು ಪದರದಲ್ಲಿ ಎಣಿಸಿದ ಬೈಟ್ ಬಜೆಟ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಹೊರಗಿನ ಟನೆಲ್ ತನ್ನದೇ ಓವರ್‌ಹೆಡ್‌ಗಾಗಿ ಅಳೆಯಲ್ಪಟ್ಟಿತು ಮತ್ತು ಒಳಗಿನದನ್ನು ಯಾರೂ ಕಳೆಯಲಿಲ್ಲ. WireGuard ಗೆ ಒಳಗೊಂಡ IPIP ಪ್ಯಾಕೆಟ್ ಕೇವಲ ಇನ್ನೊಂದು IP ಪ್ಯಾಕೆಟ್, ಮತ್ತು ಅದಕ್ಕೇ ನೀವು ಎಂದೂ ಕಾದಿರಿಸದ ಬೈಟ್‌ಗಳನ್ನು ಅದು ಬಳಸುತ್ತದೆ. ಸರಿಪಡಿಸುವಿಕೆ ಅಂಕಗಣಿತ, ಮತ್ತು ಅದು ಮೂರು ಆಜ್ಞೆ ಹಾಗೂ ಒಂದು ಕೋಷ್ಟಕದಲ್ಲಿ ಸೇರುತ್ತದೆ.
ಅದನ್ನು ಬಯಲು ಮಾಡುವ ಲಕ್ಷಣ
ತುಣುಕುಗೊಳಿಸುವಿಕೆಯ ಸಮಸ್ಯೆ ತನ್ನನ್ನು ಗಾತ್ರದಿಂದ ಘೋಷಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಎಂದೂ ವಿಳಾಸಗಳಿಂದ ಅಲ್ಲ. ನಿಮ್ಮ ಪೀರ್ ಒಂದು ಗಂಟೆ 56 ಬೈಟ್‌ನ ping ಗೆ ಉತ್ತರಿಸಿ ನಂತರ 1400 ಬೈಟ್‌ನಲ್ಲಿ ಮೌನವಾಗುತ್ತದೆ, ಟನೆಲ್ ಮೇಲೇ ಇರುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಮಾರ್ಗ ಬದಲಾಗಿಲ್ಲ. ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಹೊಂದುತ್ತದೆ, ಮೊದಲ ಪೂರ್ಣ TCP ವಿಂಡೋ ಹೊಂದುವುದಿಲ್ಲ, ಮತ್ತು ಆರೋಗ್ಯಕರವಾಗಿ ಕಂಡ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ವರ್ಗಾವಣೆ ನಿಲ್ಲುತ್ತದೆ.
ಏನನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮೇಲ್ಚಾವಣಿಯನ್ನು ಅಳೆಯಿರಿ, ಏಕೆಂದರೆ ಅಳೆಯದ ಮೇಲ್ಚಾವಣಿಯೇ ನೀವು ಎರಡು ಬಾರಿ ಬೆನ್ನಟ್ಟುವಂಥದ್ದು. ಸಂಶಯಾಸ್ಪದ ಗಾತ್ರದ ಕೆಳಗೆ do-not-fragment ಬಿಟ್ ಸೆಟ್ ಮಾಡಿ ಒಂದು ಪ್ರೋಬ್ ಕಳುಹಿಸಿ, ping -M do -s 1000 10.9.0.2, ನಂತರ ತುಂಬಾ ದೊಡ್ಡದು ಎಂದು ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಗಾತ್ರದಲ್ಲಿ ಪುನರಾವರ್ತಿಸಿ. ಗಮ್ಯಸ್ಥಾನ ಬದಲಾಗದೆ ಉಳಿದುಕೊಂಡು ಉಲ್ಟಾ ಪೇಲೋಡ್‌ನ ಗಾತ್ರವನ್ನು ಅನುಸರಿಸಿದರೆ, ರೂಟಿಂಗ್ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಬಜೆಟ್‌ನಿಂದ ಒಂದು ಹೆಡರ್ ಕಾಣೆಯಾಗಿದೆ.
ಪ್ರತಿ ಹೆಡರ್ ಅನ್ನು ಒಮ್ಮೆ ಎಣಿಸಿ, ಸರಿಯಾದ ಪದರದಲ್ಲಿ
ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಅಲ್ಲ, ಮಾರ್ಗದ ಅತ್ಯಂತ ಚಿಕ್ಕ MTU ನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಗೋಡೆ ಎರಡೂ ತುದಿಗಳ ಮೇಲಿದೆ. WireGuard IPv4 ಹೊರ ಸಾಗಣೆಯ ಮೇಲೆ 60 ಬೈಟ್ ಖರ್ಚು ಮಾಡುತ್ತದೆ: 20 IP ಗೆ, 8 UDP ಗೆ ಮತ್ತು 32 ತನ್ನದೇ ಹೆಡರ್‌ಗೆ, ಮತ್ತು ಆ ಸಾಗಣೆ IPv6 ಆದಾಗ 80 ಬೈಟ್. 1420 ಬೈಟ್‌ನ wg0 1500 ಬೈಟ್ ಮಾರ್ಗ ನಿಜವಾಗಿ ತಲುಪಿಸಬಲ್ಲ 1440 ಕ್ಕಿಂತ ಕೆಳಗೆ 20 ಬೈಟ್ ಅವಕಾಶ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಕಿಯಿಂದ ನಕಲಿಸಿದ ಸಂಖ್ಯೆ ಇಲ್ಲಿಯೂ ಹೊಂದುತ್ತದೆ. ಇಡೀ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದೆ MTU ಬದಲಿಸುವವರು ಇಲ್ಲದಿದ್ದರೆ ಹೊಸ ಗುಂಡಾದ ಸಂಖ್ಯೆ ಆರಿಸಿ ನಿಮ್ಮ ದೋಷವನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತಾರೆ.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
ಐದನೇ ಸಾಲು ಬಜೆಟ್‌ಗಳು ತಪ್ಪಾಗುವ ಸ್ಥಳ, ಏಕೆಂದರೆ ಒಳಗೊಂಡ ಇಂಟರ್ಫೇಸ್ ಹೊತ್ತುಕೊಂಡು ಹೋಗುವ 1400 ಬೈಟ್‌ಗಳು ಮೂಲ ಪ್ಯಾಕೆಟ್‌ನ ತನ್ನದೇ 40 ಬೈಟ್ ಹೆಡರ್‌ಗಳನ್ನು ಈಗಾಗಲೇ ಒಳಗೊಂಡಿವೆ. ಆ ಬೈಟ್‌ಗಳಲ್ಲಿ 1360 ಮಾತ್ರ ಫೈಲ್ ಓದುವ ಪ್ರಕ್ರಿಯೆಗೆ ತಲುಪುತ್ತವೆ. 1400 ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಪೇಲೋಡ್ ಎಂದು ಪರಿಗಣಿಸಿ, ಆ ಕಾಲಮ್ ಇಲ್ಲದ ಯಾವುದೇ ರೇಖಾಚಿತ್ರ ನಿಮ್ಮನ್ನು ಆಹ್ವಾನಿಸಿದಂತೆ, ಮತ್ತು ಒಳಗಿನ ಸಾಧನವು ಚಲಿಸದ ಗೋಡೆಯ ಮುಂದೆ 40 ಬೈಟ್ ಹೆಚ್ಚು ಉದಾರವಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
ಎರಡು MTU ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹೊಂದಿಸಿ
ವಾಹಕ ಮತ್ತು ಒಳಗೊಂಡ ಸಾಧನ ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳು, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಮೌಲ್ಯ ಬೇಕು. ಅವುಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಅನ್ವಯಿಸಿ, ಏಕೆಂದರೆ ಒಳಗೊಂಡ ಸಾಧನ ವಾಹಕದಿಂದ ಏನನ್ನೂ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400ನೆನಪಿಡಲು ಯೋಗ್ಯವಾದ ನಿಯಮ: ಒಳಗಿನ MTU = ಹೊರಗಿನ MTU - 20, IPIP ಟನೆಲ್ ಹೊತ್ತುಕೊಂಡು ಹೋಗುವ ಪ್ಯಾಕೆಟ್ IPv4 ಆದಾಗ, ಮತ್ತು - 40, ಒಳಗಿನ ಪ್ಯಾಕೆಟ್‌ನ ಯಾವುದೇ ಬದಿ IPv6 ಆದ ಕ್ಷಣ, ಏಕೆಂದರೆ ಒಳಗೊಂಡ ಹೆಡರ್ 20 ಬೈಟ್‌ನಿಂದ 40 ಕ್ಕೆ ಬೆಳೆಯುತ್ತದೆ. ಆ ಕಳೆಯುವಿಕೆಗೆ ಬೇರೆ ಯಾವುದೂ ಸೇರುವುದಿಲ್ಲ. ನೀವು 1420 ಆಯ್ಕೆ ಮಾಡಿದಾಗ WireGuard ನ ಓವರ್‌ಹೆಡ್ ಈಗಾಗಲೇ ಖರ್ಚಾಗಿತ್ತು, ಮತ್ತು ಅದನ್ನು ಎರಡು ಬಾರಿ ವಿಧಿಸಿದರೆ ಪರಿಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಯಾರೂ ಅಳೆಯದಿರುವವರೆಗೆ ನಿಧಾನವಾಗಿ ಉಳಿಯುವ ಟನೆಲ್ ಉಂಟಾಗುತ್ತದೆ. ಎರಡೂ ಸಾಧನಗಳು ಗುಂಡಾದ 1400 ಹೊತ್ತುಕೊಳ್ಳುವ ನಿಯೋಜನೆ ಆ ತಪ್ಪಿನ ಬೆರಳಚ್ಚు.
ಒಳಗೊಂಡ ಪ್ಯಾಕೆಟ್‌ನ ಯಾವುದೇ ಬದಿಯಲ್ಲಿ IPv6 ಇದ್ದರೆ ಮೇಲಿನ ಪ್ರತಿ ಸಂಖ್ಯೆಯೂ ಅಸಿಂಧುವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಲುವ ಸೈಟ್‌ನಿಂದ ಸಂಖ್ಯೆ ನಕಲಿಸುವ ಬದಲು ಮತ್ತೆ ಲೆಕ್ಕಿಸಿ. IPv6 ಹೊರ ಮಾರ್ಗದಲ್ಲಿ ಅಥವಾ ಮೂಲ ಡೇಟಾಗ್ರಾಮ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡ ಕ್ಷಣ ಕಳೆಯುವ ಹೆಡರ್‌ಗಳು ಪ್ರತಿಯೊಂದೂ 40 ಬೈಟ್, ಮತ್ತು ಪೇಲೋಡ್ ಸಂಖ್ಯೆ ನಿಖರವಾಗಿ ಅಷ್ಟೇ ಇಳಿಯುತ್ತದೆ.
ನಿಮಗೆ ಬಹುಶಃ ಬೇಕಿಲ್ಲದ ಫೈರ್‌ವಾಲ್ ನಿಯಮ
ಎರಡು WireGuard ಪೀರ್‌ಗಳ ನಡುವೆ ತಂತಿಯ ಮೇಲಿರುವ ಏಕೈಕ ವಸ್ತು UDP, ಆದ್ದರಿಂದ 4 ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಒಳಬರುವ ನಿಯಮ, RFC 2003 IPv4-ಒಳಗೆ-IPv4 ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್‌ಗೆ ಕೊಡುವ ಸಂಖ್ಯೆ, ಒಳಗೊಂಡ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದೂ ಇಲ್ಲ, ಅದನ್ನು ಜೀವಂತವಾಗಿ ಇಡುವುದೂ ಇಲ್ಲ. IPIP ಹೆಡರ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಪೇಲೋಡ್ ಒಳಗೆ ವಾಸಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಯಾವುದೇ ಅಂಚಿನ ಫೈರ್‌ವಾಲ್ ಅದನ್ನು ನೋಡುವುದಿಲ್ಲ. 4 ಪ್ರೋಟೋಕಾಲ್ ತೆರೆದರೂ ಹೋಸ್ಟ್‌ಗೆ ಇನ್ನೊಂದು ಅನುಮತಿಸಿದ ದಾರಿಯ ಹೊರತು ಬೇರೆ ಏನನ್ನೂ ಕೊಳ್ಳುವುದಿಲ್ಲ.
ಮೂಲ ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲಗಳು ಮತ್ತು ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ನೀತಿ ಡೀಕ್ಯಾಪ್ಸುಲೇಶನ್ ನಂತರ, ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ಗಳಲ್ಲಿ ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಸೇರುತ್ತದೆ. ಅದನ್ನು ಅಲ್ಲಿಡಿ ಮತ್ತು ಅಂಚಿನ ನಿಯಮ ಮುಚ್ಚಿದ್ದು ಉಳಿಯಬಹುದು.
WireGuard ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ
AllowedIPs WireGuard ಹೊತ್ತುಕೊಂಡು ಹೋಗುವ ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲವನ್ನು ನಿರ್ಣಯಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಹೊತ್ತುಕೊಂಡು ಹೋಗುವುದು IPIP-ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಪ್ಯಾಕೆಟ್. ಅನುಮತಿಸಿದ IPIP ಮೂಲವನ್ನು ಒಳಗಿನ ಹೆಡರ್ ನೀವು ರೂಟ್ ಮಾಡಲು ಇಷ್ಟಪಡದ ಹೋಸ್ಟ್ ಹೆಸರಿಸಿದರೂ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಮೂಲ ಮೂಲವು ಪೀರ್ ನಿಮಗಾಗಿ ಪರಿಶೀಲಿಸಿದ್ದಲ್ಲ, ಮತ್ತು ಆ ಒಳಗಿನ ವಿಳಾಸಗಳ ಜೋಡಿಗೆ ಡೀಕ್ಯಾಪ್ಸುಲೇಶನ್ ನಂತರ ತನ್ನದೇ ಜಾರಿಗೆ ಬೇಕು.
ಸುತ್ತು ಪದರವು ರೂಟಿಂಗ್ ರಚನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಎರಡನೇ ಕ್ರಿಪ್ಟೋಗ್ರಫಿ ಪದರವನ್ನಲ್ಲ. WireGuard ಒಳಗೆ IPIP ಅನ್ನು ಹೆಚ್ಚುವರಿ ರಕ್ಷಣೆ ಎಂದು ಕರೆಯುವುದು ಬೇರೆ ವಿನ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಒಂದು ping ಅಲ್ಲ, ಏಣಿಯಿಂದ ಪರಿಶೀಲಿಸಿ
ನೀವು ಲೆಕ್ಕಿಸಿದ ಗಡಿಯ ಎರಡೂ ಬದಿಗಳನ್ನು ಆವರಿಸುವ ಗಾತ್ರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿ, ನಂತರ ಕರ್ನೆಲ್ ಎರಡೂ ಸಾಧನಗಳ ಬಗ್ಗೆ ಏನು ನಂಬುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. 1360 ಬೈಟ್ ಪೇಲೋಡ್ ಜೊತೆಗೆ 40 ಬೈಟ್ ಹೆಡರ್ ಸೇರಿ 1400 ಆದರೆ, ಕೆಳಗಿನ ಮೊದಲ ಪ್ರತಿಧ್ವನಿ ಹೊಂದುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದು ಮೇಲ್ಚಾವಣಿಯಿಂದ ಒಂದು ಬೈಟ್ ಆಚೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತದೆ:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0ಮೇಲ್ಚಾವಣಿಯ ಕೆಳಗೆ ಸ್ವಚ್ಛವಾಗಿ ದಾಟಿ ಅದರ ಮೇಲಿನ ಮೊದಲ ಗಾತ್ರದಲ್ಲಿ ವಿಫಲವಾದರೆ ಅಂಕಗಣಿತ ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ನಿಲ್ಲುತ್ತದೆ ಎಂದರ್ಥ. ನಂತರ ಮೊದಲು ನಿಂತ ವರ್ಗಾವಣೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಕೃತಕ ಪ್ರೋಬ್ ಬಜೆಟ್ ಸಾಬೀತು ಮಾಡುತ್ತದೆ ಮತ್ತು ಕಳುಹಿಸುವವರ ಸ್ವಂತ ಬರವಣಿಗೆ ಗಾತ್ರಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನೀವು ಸಾಬೀತು ಮಾಡಿದ ಗಾತ್ರದಲ್ಲೂ ಒಳಗೊಂಡ ಮಾರ್ಗ ಮುರಿದರೆ, MTU ನಿಂದ ಇನ್ನೂ ಹತ್ತು ಬೈಟ್ ಕಡಿಯುವ ಮೊದಲು ದೂರದ ತುದಿಯ ಡೀಕ್ಯಾಪ್ಸುಲೇಶನ್ ಮತ್ತು ಮಾರ್ಗಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.