Windows ನಲ್ಲಿ WireGuard ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ IP ಗೆ SSH ವಿಫಲವಾಗುತ್ತದೆ

ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ SSH ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಏಳುವ ಟನೆಲ್ಗಳು ಸರ್ವರ್ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತವೆ. Windows ನಲ್ಲಿ ಹೆಚ್ಚು ಸಂಭಾವ್ಯ ಕಾರಣ ಸ್ಥಳೀಯವಾಗಿದೆ: ಪೂರ್ಣ-ಟನೆಲ್ AllowedIPs /0 ಆದಾಗ ನಿರ್ಬಂಧಕ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಆನ್ ಆಗುತ್ತವೆ, ಅವು ಟನೆಲ್ನ ಸ್ವಂತ ಸಾಗಣೆಗೆ ಮತ್ತು ಬಹಳ ಕಡಿಮೆ ಬೇರೆ ಯಾವುದಕ್ಕೂ ಅನುಮತಿ ನೀಡುತ್ತವೆ. ಆ ವಿಳಾಸವನ್ನು ತಲುಪುವ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ಗಳು ಅದೇ ವಿಳಾಸಕ್ಕೆ ಪ್ರತ್ಯೇಕ TCP ಸಂಪರ್ಕ ಹೊರಹೋಗಬಹುದೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಪಿಯರ್ ಪಟ್ಟಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಎಂಡ್ಪಾಯಿಂಟ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಅದರ ಒಳಗಿನ ಟನೆಲ್ ವಿಳಾಸದಿಂದ ಬೇರ್ಪಡಿಸಿ. AllowedIPs ಸಂಪಾದಿಸಿ ಇದನ್ನು ಸರಿಪಡಿಸುವ ಬಹುತೇಕ ಪ್ರಯತ್ನಗಳು ಮಾರ್ಗವನ್ನು ಸರಿಯಾಗಿಸುವ ಬದಲು ನೀತಿಯನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತವೆ.

ರೂಟಿಂಗ್ ಅನುಮತಿ ಮತ್ತು ಫೈರ್ವಾಲ್ ಅನುಮತಿ ಬೇರೆ ಬೇರೆ

ರೂಟ್ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಳುಹಿಸಬಹುದೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ನ ಸಾರ್ವಜನಿಕ IP ಗೆ ರೂಟ್ ಸೇರಿಸುವುದು ಫಿಲ್ಟರ್ ಇನ್ನೂ ತಡೆಯಬಹುದಾದ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಮತ್ತು ಈ ಲಕ್ಷಣವು ಸೃಷ್ಟಿಸುವ ಗೊಂದಲ ನಿಖರವಾಗಿ ಅದೇ. Windows ನಲ್ಲಿ ಫಿಲ್ಟರ್ ಪ್ರತ್ಯೇಕ ಸೇರ್ಪಡೆ ಅಲ್ಲ, ಅನುಷ್ಠಾನದ ಭಾಗ, ಆದ್ದರಿಂದ ಯಾವುದೇ ರೂಟ್ ನಮೂದು ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಈ ಎರಡು ನಿರ್ಧಾರಗಳು ಬೇರೆಡೆಯೂ ಪ್ರತ್ಯೇಕ, ಆದರೂ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು ಭಿನ್ನ.

ಅದಕ್ಕೇ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ traceroute ಯಶಸ್ವಿಯಾಗಬಹುದು ಆದರೆ SSH ಪ್ರಯತ್ನ ವಿಫಲವಾಗುತ್ತದೆ. ಮೊದಲನೆಯದನ್ನು ವಿನಾಯಿತಿ ಹೊಂದಿರುವ ಸೇವೆ ಸಾಗಿಸುತ್ತದೆ, ಎರಡನೆಯದನ್ನಲ್ಲ.

Windows ನಲ್ಲಿ /0 ಏನು ಮಾಡುತ್ತದೆ

ಒಂದೇ ಪಿಯರ್ನ ಅನುಮತಿಸಿದ ವಿಳಾಸಗಳು ಇಡೀ IPv4 ಸ್ಥಳಾವಕಾಶವನ್ನು ಆವರಿಸಿದಾಗ, WireGuard for Windows ನಿರ್ಬಂಧಕ ಫೈರ್ವಾಲ್ ಧೋರಣೆಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಅದು ಇಲ್ಲದಿದ್ದರೆ ಟನೆಲ್ನ ಹೊರಗೆ ಹೋಗುತ್ತಿದ್ದ ಸಂಚಾರವನ್ನು ತಡೆಯುತ್ತದೆ. ಟನೆಲ್ ಸೇವೆಯ ಸ್ವಂತ ಸಾಗಣೆಗೆ ಅನುಮತಿ ಇದೆ, ಏಕೆಂದರೆ VPN ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಹೋಗುವ ಇನ್ನೊಂದು ಅಪ್ಲಿಕೇಶನ್ಗೆ ಅಂತಹ ಅನುಮತಿ ಸಿಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿನಾಯಿತಿ ಸಾಗಣೆಗೆ ಸೇರಿದ್ದು, ವಿಳಾಸಕ್ಕಲ್ಲ. Windows ನೆಟ್ವರ್ಕಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು ಈ ವರ್ತನೆ ಮತ್ತು ಸಂಪಾದಕದಲ್ಲಿನ ಸಂಬಂಧಿತ ನಿಯಂತ್ರಣವನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಆ ನಿಯಮಗಳೇ kill switch ಪದಗುಚ್ಛದ ಹಿಂದಿನ ಕಾರ್ಯವಿಧಾನ. ಅವು ಆ ಹೆಸರಿನ ಚೆಕ್ಬಾಕ್ಸ್ನಿಂದಲ್ಲ, ಸಂರಚನೆಯ ಆಕಾರದಿಂದ ಸಕ್ರಿಯವಾಗುತ್ತವೆ.

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

/0 ಅನ್ನು ಎರಡು ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಂದ ಬದಲಿಸುವುದು ನಿರ್ಬಂಧಕ ಅರ್ಥವಿವರಣೆ ಇಲ್ಲದೆ ವಿಶಾಲ ರೂಟಿಂಗ್ ಉಳಿಸಿಕೊಳ್ಳುವ ದಾಖಲಿತ ದಾರಿ, ಮತ್ತು ಇದು ಚಿಕ್ಕ ಬರವಣಿಗೆ ಅಲ್ಲ, ಬೇರೆ ರಕ್ಷಣಾ ಮಾದರಿ. ಅನುಮತಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸವನ್ನು ಕಳೆಯುವುದು ಇನ್ನೊಂದು ಸಾಮಾನ್ಯ ಪರಿಹಾರ, ಅದು ಪಟ್ಟಿಯನ್ನು ಉದ್ದಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ನಿಯಮಗಳು ಸಕ್ರಿಯವಾಗುತ್ತವೆ ಎಂಬುದನ್ನೂ ಬದಲಿಸುತ್ತದೆ. ಎರಡೂ ಸ್ಥಳೀಯ ಪರಿಣಾಮದ ಸ್ಥಳೀಯ ಸಂಪಾದನೆಗಳಲ್ಲ. ಪ್ರತಿಯೊಂದೂ ಯಂತ್ರದ ಪ್ರತಿ ಹರಿವಿಗೂ ಮಿತಿಯನ್ನು ಸರಿಸುತ್ತದೆ, ನೀವು ಸರಿಪಡಿಸುತ್ತಿದ್ದ ಸಂಪರ್ಕಕ್ಕೆ ಮಾತ್ರವಲ್ಲ.

ನೇರ ಸಾರ್ವಜನಿಕ SSH ನಿಜವಾಗಿ ಅಗತ್ಯವಿರುವಲ್ಲಿ, ಪ್ರೊಫೈಲ್ ಮಾಲೀಕರು ಹೊರಗಿನ ರೂಟ್ ಮತ್ತು ಅದರ ಫೈರ್ವಾಲ್ ಅನುಮತಿ ಎರಡನ್ನೂ ವಿನ್ಯಾಸ ಮಾಡಬೇಕು, ಮತ್ತು ಟನೆಲ್ ಬಿದ್ದಾಗ ಅಸಂಬಂಧಿತ ಸಂಚಾರಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು. IPv4 ಮತ್ತು IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸುವುದೂ ಅದರ ಭಾಗ, ಏಕೆಂದರೆ ನಿಯಮಗಳು ಕುಟುಂಬದ ಪ್ರಕಾರ ವ್ಯಕ್ತವಾಗುತ್ತವೆ. ಒಂದು ನಿರ್ವಹಣಾ ಅವಧಿಯನ್ನು ಉಳಿಸಲು ಸೇರಿಸಿದ ವಿಶಾಲ ಬೈಪಾಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಅವಧಿಗಿಂತ ಹೆಚ್ಚನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.

ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ನಿರ್ವಹಣಾ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

ಒಳಗಿನ ವಿಳಾಸಕ್ಕೆ ಯಶಸ್ವಿ SSH ಟನೆಲ್ ನಿರ್ವಹಣಾ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ನ ಸ್ವಂತ ಫೈರ್ವಾಲ್ ಅದನ್ನು ಪಿಯರ್ ಶ್ರೇಣಿಯಿಂದ ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಎರಡೂ ಗುರಿಗಳಲ್ಲಿ ವಿಫಲತೆ Windows ರೂಟಿಂಗ್ನದಲ್ಲ, ಸರ್ವರ್-ಬದಿ ಅಥವಾ ಕೀ ಸಮಸ್ಯೆ. ಒಳಗಿನ ವಿಳಾಸ ಕೆಲಸ ಮಾಡಿ ಹೊರಗಿನದು ಮಾಡದಿದ್ದರೆ, ಸ್ಥಳೀಯ ಫೈರ್ವಾಲ್ ಧೋರಣೆ ಅದನ್ನು ವಿನ್ಯಾಸ ಮಾಡಿದ ಉದ್ದೇಶವನ್ನೇ ನಿರ್ವಹಿಸುತ್ತಿದೆ. ಪ್ರೊಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮೂರು ಫಲಿತಾಂಶಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಓದಿ.

ನಿರ್ವಹಣಾ ಮಾರ್ಗ, ಬಳಸಿದ ವಿಳಾಸ ಮತ್ತು ಟನೆಲ್ ಆಫ್ ಇರುವಾಗಿನ ವರ್ತನೆಯನ್ನು ದಾಖಲಿಸಿ. ಐದು ನಿಮಿಷ ಉಳಿಸಲು ಬೈಪಾಸ್ ಅಗಲಿಸದಂತೆ ತಡೆಯುವುದೇ ಆ ಟಿಪ್ಪಣಿ.