ನೆಸ್ಟೆಡ್ WireGuard: ಮಧ್ಯದ ಹಾಪ್ ತನ್ನದೇ ಪೋರ್ಟ್ಗೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ
ಮಧ್ಯದ ಹಾಪ್ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸಿದಾಗ, ಅದರ ಒಳಬರುವ ಸೇವೆಗೆ ಉತ್ತರಗಳು ತಪ್ಪು ಮಾರ್ಗದಲ್ಲಿ ಹೊರಡುತ್ತವೆ. ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಮೂಲ-ಪೋರ್ಟ್ ನಿಯಮ ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ.
ಮೂರು WireGuard ಹಾಪ್ಗಳು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಿಲ್ಲದ ನೆಟ್ವರ್ಕ್ ತಲುಪುತ್ತವೆ, ನಂತರ ಮಧ್ಯದ ಯಂತ್ರವು ಕೇಳಬೇಕಿದ್ದ ಪೋರ್ಟ್ನಲ್ಲಿ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಮುಂದಿನ ಸುರಂಗ ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ದೂರದ ಹೋಸ್ಟ್ ಇನ್ನೂ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ, ಮತ್ತು ಹೊರಗಿನಿಂದ ಸದ್ದಿಲ್ಲದೆ ಹೋಗಿರುವುದು ಮಧ್ಯದ ಸರ್ವರ್ ಮಾತ್ರ. ಈ ಸಂಯೋಜನೆ ಗೊಂದಲಮಯವಾಗಿರುವುದು ಅದು ಸ್ವಯಂ ಉಂಟುಮಾಡಿದ್ದು ಎಂಬ ಕಾರಣದಿಂದಲೇ: ಮಧ್ಯದ ಹಾಪ್ ತನ್ನದೇ ರೌಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಪಾಲಿಸುತ್ತಿದೆ, ಮತ್ತು ಕೋಷ್ಟಕವು ಅದರ ಉತ್ತರಗಳನ್ನು ತಪ್ಪು ದಿಕ್ಕಿಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ಮಧ್ಯದ ಪೆಟ್ಟಿಗೆಯೊಂದಿಗೆ ಮಾತನಾಡುವವರೆಗೆ ಕೆಲಸ ಮಾಡುವ ಸರಣಿ
ಒಂದು ಉದಾಹರಣೆಯ ಸರಣಿ ತೆಗೆದುಕೊಳ್ಳಿ: ಕ್ಲೈಂಟ್ A UDP 500 ನಲ್ಲಿ ಸರ್ವರ್ B ತಲುಪುತ್ತದೆ, ಮತ್ತು B UDP 500 ನಲ್ಲಿ ಸರ್ವರ್ C ಕಡೆಗೆ ಮುಂದುವರಿಯುತ್ತದೆ. C ತನ್ನ ಏಕೈಕ ಪೀರ್ನ ವಿಳಾಸದಿಂದ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಇದು ಅದನ್ನು ಎಲೆಯನ್ನಾಗಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ವರ್ತನೆಯನ್ನು ಸರಳವಾಗಿ ಇರಿಸುತ್ತದೆ. B ಎಲೆಯಲ್ಲ, ಮತ್ತು ಈ ವೈಫಲ್ಯದ ಬಗ್ಗೆ ಆಸಕ್ತಿದಾಯಕವಾದದ್ದೆಲ್ಲವೂ ಅಲ್ಲಿಯೇ ನಡೆಯುತ್ತದೆ.
ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯವಾದುದು ಏಕೆಂದರೆ ಎಲೆ ಮತ್ತು ಮಧ್ಯದ ಪಾತ್ರಗಳು ವಿರುದ್ಧ ದಿಕ್ಕುಗಳಲ್ಲಿ ಎಳೆಯುತ್ತವೆ. ಎಲೆಯು ಯಾವುದೇ ಪರಿಣಾಮವಿಲ್ಲದೆ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸಬಹುದು, ಏಕೆಂದರೆ ಬೇರೆ ಯಾವುದೂ ಅದನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ. ಮಧ್ಯದ ಹಾಪ್ ಏಕಕಾಲದಲ್ಲಿ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಅಂತ್ಯಬಿಂದು ಮತ್ತು ದೂರದ ಕಡೆಗೆ ಕ್ಲೈಂಟ್ ಆಗಿದೆ, ಮತ್ತು ಆ ಎರಡು ಕೆಲಸಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ರೌಟಿಂಗ್ ಬೇಕು.
ಉತ್ತರ ಸುರಂಗದ ಮೂಲಕ ಹೊರಡುವುದೇಕೆ
B ಯಲ್ಲಿ, C ಕಡೆಗಿನ ಇಂಟರ್ಫೇಸ್ ಸರಿಸಮಾನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದೊಂದಿಗೆ AllowedIPs = 0.0.0.0/0 ಹೊತ್ತಿದೆ. ಆದ್ದರಿಂದ B ರಚಿಸುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಆ ಸುರಂಗಕ್ಕೆ ಹೋಗುತ್ತದೆ, ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದದ್ದು ಆದ್ಯತೆ ಪಡೆಯದಿದ್ದರೆ.
A ಯಿಂದ B ಗೆ ಉದ್ದೇಶಿಸಿದ ಪ್ಯಾಕೆಟ್ ಬಂದು ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತದೆ, ಏಕೆಂದರೆ B ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಸ್ಥಳೀಯ ವಿತರಣೆ ಮೊದಲು ನಡೆಯುತ್ತದೆ. ಉತ್ತರವು A ಯ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಗುರಿಪಡಿಸಿದ ಸಂಪೂರ್ಣ ಹೊಸ ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಪ್ಯಾಕೆಟ್, ಮತ್ತು ಆ ಗಮ್ಯಸ್ಥಾನ ಸುರಂಗದೊಳಗಿನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಕ್ಕೆ ಹೊಂದುತ್ತದೆ. C ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆ ವಿಳಾಸದ ಒಡೆಯನಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ.
ಲಕ್ಷಣವು ಫೈರ್ವಾಲ್ ಸಮಸ್ಯೆ ಅಥವಾ ಕೀ ಹೊಂದಿಕೆಯಾಗದಿರುವಂತೆ ಓದಿಸುತ್ತದೆ, ಮತ್ತು ಇಲ್ಲಿ ಎರಡೂ ನಿಜವಲ್ಲ. C ಕಡೆಗಿನ ಸುರಂಗದಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಉತ್ತರಗಳು ತಪ್ಪು ದಿಕ್ಕಿಗೆ ಹೋಗುತ್ತಿರುವುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಆ ಒಂದು ಅವಲೋಕನವು ಎಷ್ಟೇ ಸಂರಚನೆ ಓದುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ಉಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೀಗಳನ್ನು ಬದಲಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಅದನ್ನು ಬರೆದಿಡಿ. ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ನೋಡದವರು ಸುರಂಗವೇ ಮುರಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ.
ಸಣ್ಣ ರಿಪೇರಿ: ಮೂಲ ಪೋರ್ಟ್ಗೆ ಹೊಂದುವ ನೀತಿ ನಿಯಮಗಳು
B ಯ ಕೇಳುವ ಸಾಕೆಟ್ನಿಂದ ಉತ್ತರಗಳು ಮೂಲ ಪೋರ್ಟ್ 500 ನೊಂದಿಗೆ ಹೊರಡುತ್ತವೆ. ನೀತಿ ನಿಯಮವು ಅದಕ್ಕೆ ಹೊಂದಿ ಆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಮಾನ್ಯ ಕೋಷ್ಟಕಕ್ಕೆ ಮರಳಿಸಬಹುದು:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101ನೀತಿ ನಿಯಮಗಳನ್ನು ಆದ್ಯತೆಯ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಮುಖ್ಯ ಕೋಷ್ಟಕ 32766 ನಲ್ಲಿದೆ, ಆದ್ದರಿಂದ 100 ನಲ್ಲಿನ ನಿಯಮವು ಸುರಂಗದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮಾತನಾಡುವ ಮೊದಲು ಕೇಳಲ್ಪಡುತ್ತದೆ. ಹೊರಗಿನಿಂದ ತಲುಪಬಲ್ಲದಾಗಿ ಉಳಿಯಬೇಕಾದ ಪ್ರತಿ ಪೋರ್ಟ್ಗೆ ಒಂದು ನಮೂದನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಅದಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಇಲ್ಲ, ಇದರಿಂದ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುವ ಸಂಚಾರವು ಅದಕ್ಕಾಗಿ ನಿರ್ಮಿಸಿದ ಸುರಂಗವನ್ನೇ ಬಳಸುತ್ತದೆ.
ಈ ಉಪಾಯದ ಮಿತಿಯನ್ನು ತಿಳಿಯಿರಿ. sport ಆಯ್ಕೆಗಾರವು ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಹೊಂದುತ್ತದೆ, ಇದು ಉತ್ತರದ ಪ್ರಕರಣವನ್ನೇ ನಿಖರವಾಗಿ ಒಳಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು B ಬೇರೆಯವರಿಗಾಗಿ ಕೇವಲ ರವಾನಿಸುವ ಸಂಚಾರವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ. B ಯ ಹಿಂದೆ ಹೋಸ್ಟ್ ಮಾಡಿದ ಸೇವೆಗೆ ಇನ್ನೂ ತನ್ನದೇ ಉತ್ತರ ಬೇಕು, ಮತ್ತು ವಿರುದ್ಧವಾಗಿ ನಟಿಸುವುದು ಮೊದಲ ಸೇವೆಗೆ ಕೆಲಸ ಮಾಡಿ ಎರಡನೆಯದಕ್ಕೆ ವಿಫಲವಾಗುವ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.
ನಿಯಮಕ್ಕೆ ಮಾಲೀಕರನ್ನು ನೀಡಿ
ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ನಿಯಮವು ಮುಂದಿನ ಬಾರಿ ಇಂಟರ್ಫೇಸ್ ಮರುನಿರ್ಮಾಣವಾದಾಗ ಮಾಯವಾಗುತ್ತದೆ. WireGuard ಸೆಟಪ್ನಲ್ಲಿ ಅದನ್ನು ಇಂಟರ್ಫೇಸ್ ರಚಿಸುವ ಮತ್ತು ತೆಗೆದುಹಾಕುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100ಇಂಟರ್ಫೇಸ್ನ ಮಾಲೀಕರು NetworkManager, ವಿತರಣಾ ಹುಕ್ ಅಥವಾ ಕಂಟೇನರ್ ಪ್ರವೇಶಬಿಂದು ಆಗಿದ್ದರೆ, ಜೋಡಿ ಕೈಯಿಂದ ಸಂಪಾದಿಸಿದ ಫೈಲ್ಗಲ್ಲ, ಆ ಮಾಲೀಕರಿಗೆ ಸೇರುತ್ತದೆ. ಮರುಸಂಪರ್ಕದ ನಂತರ ಪರಿಣಾಮಕಾರಿ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಮೊದಲ ಆರಂಭದ ನಂತರ ಮಾತ್ರವಲ್ಲ, ಏಕೆಂದರೆ ಮೊದಲ ಆರಂಭವು ಯಾವಾಗಲೂ ಕೆಲಸ ಮಾಡುವ ಪ್ರಕರಣ.
ಪರ್ಯಾಯಗಳನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೋಲಿಸಿ
ಮೂಲ-ಪೋರ್ಟ್ ನಿಯಮವು ನಾಲ್ಕು ನಿರ್ಗಮನ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಅತ್ಯಂತ ಸಣ್ಣದು. ಸುರಂಗದ ನೀತಿಯನ್ನು ಸ್ವಲ್ಪವೂ ಮುಟ್ಟದಿರುವುದು ಅದರ ಪ್ರಯೋಜನ, ಆದ್ದರಿಂದ ಅದು ನಂತರದ ಬದಲಾವಣೆಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬದುಕುಳಿಯುತ್ತದೆ. ಸಣ್ಣ ಸರಿಪಡಿಸುವಿಕೆಗಳು ಅನ್ವಯವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ, ಆದರೆ ವಿಶಾಲ ವಿನಾಯಿತಿ ಅದರ ಕಾರಣ ಮಾಯವಾದ ಬಹಳ ನಂತರವೂ ಸದ್ದಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ. ಎರಡು ವರ್ಷಗಳ ನಂತರ ಪೆಟ್ಟಿಗೆಯ ಮಾಲೀಕತ್ವ ಬೇರೆಯವರಿಗೆ ಇದ್ದಾಗ ಆ ವ್ಯತ್ಯಾಸವು ಸೊಬಗಿಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
ಆಯ್ಕೆ ಮಾಡಿದ ನಂತರ ಎರಡೂ ತುದಿಗಳಿಂದ ಪರಿಶೀಲಿಸಿ. A ಯಿಂದ, B ಯ ಪೋರ್ಟ್ಗೆ ಸಂಪರ್ಕ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯ ಅದನ್ನು ಕಾರ್ಯನಿರತವಾಗಿರಿಸಿ. B ಯಲ್ಲಿ, ಕರ್ನಲ್ಗೆ ip route get <address-of-A> sport 500 ನಂತಹದರಿಂದ ಉತ್ತರ ಮಾರ್ಗವನ್ನು ಸಮರ್ಥಿಸಲು ಹೇಳಿ, ಮತ್ತು ಅದು ಸುರಂಗವಲ್ಲ WAN ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ನಂತರ, C ಯ ಹಿಂದಿನ ಯಾವುದೋ ಸರಣಿಯ ಮೂಲಕ ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಇದು ವಿನಾಯಿತಿಯು ಬೈಪಾಸ್ ಆಗದೆ ಸಣ್ಣದಾಗಿಯೇ ಉಳಿದಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಕೊನೆಯದಾಗಿ, ಪೋರ್ಟ್ಗಳನ್ನು ವಿನ್ಯಾಸ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಇದನ್ನು ಬೇರೆ ಸೇವೆಯಲ್ಲಿ ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ.