ಒಂದೇ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಎರಡು ಪೀರ್ WireGuard ಪರೀಕ್ಷೆಯನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು

ಡೀಫಾಲ್ಟ್ ರೂಟ್, LAN ಪ್ರಿಫಿಕ್ಸ್, DNS ಮತ್ತು ಫೈರ್‌ವಾಲ್ ವಿನಾಯಿತಿಯನ್ನು ಹೊತ್ತಿರುವ WireGuard ಪರೀಕ್ಷೆಯು ಅವುಗಳಲ್ಲಿ ಯಾವುದು ಮುರಿದಿದೆ ಎಂದು ಹೇಳಲಾರದು. ಅದನ್ನು ಎರಡು ಪೀರ್, ಒಂದು ವಿಳಾಸ ಜೋಡಿ ಮತ್ತು ಒಂದು ಅನುಮತಿಸಿದ ಸೇವೆಗೆ ಇಳಿಸಿ, ಆಗ ವೈಫಲ್ಯಕ್ಕೆ ಅಡಗಿಕೊಳ್ಳಲು ಜಾಗ ಉಳಿಯದು. ನೀರಸ ಆಧಾರವೇ ರೋಗನಿರ್ಣಯ. ಅದನ್ನು ಮೊದಲು ನಿರ್ಮಿಸಿ; ಅದು ಹದಿನೈದು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಊಹಿಸುವುದರಲ್ಲಿ ಕಳೆಯುತ್ತಿದ್ದ ಮಧ್ಯಾಹ್ನವನ್ನು ಉಳಿಸುತ್ತದೆ.

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

ಕೀಗಳು, ವಿಳಾಸಗಳು ಮತ್ತು ಏಕೈಕ ಎಂಡ್‌ಪಾಯಿಂಟ್

ಪ್ರತಿ ಸಿಸ್ಟಂನಲ್ಲಿ ಕೀ ಜೋಡಿ ರಚಿಸಿ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಸಾರ್ವಜನಿಕ ಅರ್ಧಗಳನ್ನು ಮಾತ್ರ ಸರಿಸಿ. wg genkey | tee privatekey | wg pubkey > publickey ದಾಖಲಿತ ಒಂದೇ ಸಾಲಿನ ಆಜ್ಞೆಯಾಗಿದೆ, ಮತ್ತು ಅದು ಖಾಸಗಿ ಕೀಯನ್ನು ನಂತರ ರಕ್ಷಿಸಬಹುದಾದ ಫೈಲ್‌ನಲ್ಲಿ ಬಿಡುತ್ತದೆ. ನಿಮ್ಮ ಬೇರೆ ಯಾವುದೇ ಸಂರಚನೆಯಲ್ಲಿ ಕಾಣದ ಶ್ರೇಣಿಯಿಂದ ಟನೆಲ್ ವಿಳಾಸಗಳನ್ನು ಆರಿಸಿ, ಉದಾಹರಣೆಗೆ 10.99.0.1/24 ಮತ್ತು 10.99.0.2/24. ಯಾವ ವಿಳಾಸ ಯಾವ ಯಂತ್ರಕ್ಕೆ ಸೇರಿದೆ ಎಂದು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಪ್ರತಿ ಪರಿಶೀಲನೆಯೂ ಆ ಮ್ಯಾಪಿಂಗ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ.

ಖಾಸಗಿ ಕೀಗಳು ಎಂದಿಗೂ ಪ್ರಯಾಣಿಸುವುದಿಲ್ಲ. ಪರೀಕ್ಷೆಗೆ ಒಂದನ್ನು ಇನ್ನೊಂದು ಬದಿಗೆ ನಕಲಿಸಬೇಕಿದ್ದರೆ, ಪರೀಕ್ಷೆ ಈಗಾಗಲೇ ತಪ್ಪಾಗಿದೆ. ಎರಡೂ ಸಿಸ್ಟಂಗಳು NAT ಹಿಂದೆ ಇದ್ದಾಗ, ಕನಿಷ್ಠ ಒಂದಕ್ಕೆ ತಲುಪಬಹುದಾದ UDP ಪೋರ್ಟ್ ಬೇಕು, ಇನ್ನೊಂದು ಅದನ್ನು ಸೂಚಿಸುವ Endpoint ಹೊರುತ್ತದೆ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿರಬೇಕು, 51820 ಬಗ್ಗೆ ನಿಮ್ಮ ಊಹೆಗಳಲ್ಲಿ ಅಲ್ಲ.

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

wg ಗೆ ಸೇರಿದ ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ಸೇರದಿರುವವು

ಮೂಲ ಕ್ಷೇತ್ರಗಳ ಗುಂಪು ಚಿಕ್ಕದು: Interface ಅಡಿಯಲ್ಲಿ PrivateKey ಮತ್ತು ListenPort, Peer ಅಡಿಯಲ್ಲಿ PublicKey, AllowedIPs ಮತ್ತು Endpoint. Address ಮತ್ತು DNS wg ಗೆ ಅಲ್ಲ, wg-quick ಗೆ ಸೇರಿವೆ, ಮತ್ತು ಅದೇ ಸಂರಚನೆ ಇನ್ನೊಂದು ಸಾಧನಕ್ಕೆ ಹೋದ ಕ್ಷಣ ಈ ವ್ಯತ್ಯಾಸ ಕಚ್ಚುತ್ತದೆ.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs ಒಟ್ಟಿಗೆ ಎರಡು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳು ಟನೆಲ್‌ಗೆ ಹೋಗುತ್ತವೆ ಎಂದು ಆರಿಸುತ್ತದೆ, ಮತ್ತು ಬಂದಾಗ ಆ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಬಳಸಲು ಪೀರ್‌ಗೆ ಅಧಿಕಾರ ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಇನ್ನೊಂದು ಬದಿಯ ಪ್ರತಿಬಿಂಬ ನಮೂದು ನಿಮ್ಮ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ನಿಖರವಾಗಿ ಹೆಸರಿಸಬೇಕು; ತಪ್ಪು ಪೀರ್‌ಗೆ /32 ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯಾಗಿ ಓದುತ್ತದೆ ಮತ್ತು ಅಧಿಕಾರ ಸಮಸ್ಯೆಯಂತೆ ವರ್ತಿಸುತ್ತದೆ. WireGuard ತ್ವರಿತ ಆರಂಭ ಕ್ಷೇತ್ರ ಹೆಸರುಗಳನ್ನು ಹೋಲಿಸಲು ಬಯಸಿದರೆ ಅದೇ ಎರಡು-ಪೀರ್ ಆಕಾರವನ್ನು ಪ್ರಮಾಣಿತ ಪದಗುಚ್ಛದೊಂದಿಗೆ ತೋರಿಸುತ್ತದೆ.

ಐಕಾನ್ ಬದಲು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಓದುವುದು

ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಅದನ್ನು ಹೊಂದಿರುವ ಮೂಲಕ ಮೇಲೆ ಎತ್ತಿ, ನಂತರ ಸ್ಥಿತಿ ಬೆಳಕಿನ ಬದಲು ಸ್ಥಿತಿಯನ್ನು ಓದಿ. wg show ಪ್ರತಿ ಪೀರ್‌ನ ಇತ್ತೀಚಿನ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಬೈಟ್ ಕೌಂಟರ್‌ಗಳೊಂದಿಗೆ ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಕಳೆದ ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಎಂದರೆ ಕೀಗಳು, ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು UDP ಮಾರ್ಗ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ. ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಮಾತ್ರ ಏರುವ ಕೌಂಟರ್ ತನ್ನದೇ ಉತ್ತರ, ಮತ್ತು ಅದು ಎಂದಿಗೂ ಆಗದ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಂತೆಯೇ ಅಲ್ಲ.

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

ಒಂದು ಅನುಮತಿಸಿದ ಸೇವೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುವುದು, ನಂತರ ವಿರುದ್ಧ ದಿಕ್ಕು

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

ವಿರುದ್ಧ ದಿಕ್ಕನ್ನು ತನ್ನದೇ ಫಲಿತಾಂಶದ ಪ್ರತ್ಯೇಕ ಪರೀಕ್ಷೆಯಾಗಿ ನಡೆಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ದಿಕ್ಕುಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಫೈರ್‌ವಾಲ್ ಮತ್ತು AllowedIPs ನಮೂದುಗಳಿವೆ ಮತ್ತು ಅವು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗಬಹುದು. ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಕೆಲಸ ಮಾಡಿ ವಿನಂತಿ ಮಾಡದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಟನೆಲ್‌ನಲ್ಲಲ್ಲ, ಡೇಟಾ ಮಾರ್ಗದಲ್ಲಿದೆ: AllowedIPs, ಕೇಳುತ್ತಿರುವ ಸೇವೆ, ಅಥವಾ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್. ಫಾರ್ವರ್ಡಿಂಗ್, NAT ಅಥವಾ DNS ಸೇರಿಸುವ ಮೊದಲು ಅದನ್ನು ಸರಿಪಡಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಎಂದಿಗೂ ದೋಷಿಯಲ್ಲದ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಡೀಬಗ್ ಮಾಡುವುದರಲ್ಲಿ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುತ್ತದೆ.

ಆಧಾರವನ್ನು ಉಲ್ಲೇಖವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುವುದು

ಕೆಲಸ ಮಾಡುವ ಟೋಪಾಲಜಿ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಮೂಲವನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಉಳಿಸಿ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಸೇವೆಗೆ ಸಿಂಕ್ ಆಗುವ ಯಾವುದೇ ಫೋಲ್ಡರ್‌ನಿಂದ ಹೊರಗಿಡಿ. ನಂತರ ಒಂದೊಂದಾಗಿ ವೈಶಿಷ್ಟ್ಯ ಸೇರಿಸಿ, ಪ್ರತಿಯ ನಂತರ ಮೂಲ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಿ: ಫಾರ್ವರ್ಡಿಂಗ್, NAT, LAN ರೂಟ್, ಮತ್ತು ನಂತರವೇ DNS. ಪರೀಕ್ಷೆಯನ್ನು ಮುರಿಯುವ ಪ್ರತಿ ಸೇರ್ಪಡೆ ಈಗ ಗುರುತಿಸಬಹುದಾದದ್ದು, ಏಕೆಂದರೆ ಬೇರೆ ಏನೂ ಚಲಿಸಿಲ್ಲ.

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