ನಿಮ್ಮ VPN ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಮೊದಲು VPS ಏನನ್ನು ಅನುಮತಿಸಬೇಕು

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

ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬೇಕಾದ ಇಂಟರ್ಫೇಸ್ ದೃಢೀಕರಿಸಿ

OpenVPN TUN ಮೇಲೆ ಚಲಾಯಿಸಲು ಅಕ್ಷರ ಸಾಧನ ಮತ್ತು ಅದರ ಹಿಂದಿನ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಬೇಕು; WireGuard ಗೆ ತನ್ನದೇ ಕರ್ನಲ್ ಬೆಂಬಲ ಅಥವಾ ಹೊಂದಿಕೆಯಾಗುವ ನಿರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಬಳಕೆದಾರ ಸ್ಥಳ ಅನುಷ್ಠಾನ ಬೇಕು. ನಿರ್ವಹಿತ ಕಂಟೇನರ್‌ಗಳು ಸಾಧನವನ್ನು ಎಂದಿಗೂ ಬಹಿರಂಗಪಡಿಸದ ಹೋಸ್ಟ್ ಕರ್ನಲ್ ಹಂಚಿಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಕೆಲವು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಏನೇ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೂ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ರಚಿಸುವುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷೇಧಿಸುತ್ತವೆ.

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

ಮೊದಲ ಜೋಡಿಯಲ್ಲಿ ನಿರಾಕರಣೆ ಎಂದರೆ TUN ಲಭ್ಯವಿಲ್ಲ ಮತ್ತು OpenVPN ನ ಡೀಫಾಲ್ಟ್ ಮೋಡ್ ಪ್ರಾರಂಭವಾಗಲಾರದು; ಕೊನೆಯ ಸಾಲಿನಲ್ಲಿ ನಿರಾಕರಣೆ ಎಂದರೆ WireGuard ಕರ್ನಲ್ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲ. ಕರ್ನಲ್‌ನ TUN/TAP ದಾಖಲೆ ಮೊದಲ ಪರಿಶೀಲನೆ ಪರೀಕ್ಷಿಸುವ ಸಾಧನವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಎರಡು ವೈಫಲ್ಯಗಳಲ್ಲಿ ಯಾವುದೂ VPN ಪ್ಯಾಕೇಜ್ ಮರುಸ್ಥಾಪಿಸುವುದರಿಂದ ಸರಿಯಾಗುವುದಿಲ್ಲ.

ಒಳಬರುವ ಮಾರ್ಗಕ್ಕೆ ಇಬ್ಬರು ಮಾಲೀಕರಿದ್ದಾರೆ ಎಂದು ನೆನಪಿಡಿ

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

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಯೋಜಿಸಿ, ನಿರ್ಗಮನವನ್ನು ಮಾತ್ರವಲ್ಲ

ಪೂರ್ಣ ಟನೆಲ್ ಸೇವೆಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯ, ಕ್ಲೈಂಟ್ ಸಂಚಾರಕ್ಕೆ ಅನುವಾದ ಅಥವಾ ರೂಟಿಂಗ್ ಯೋಜನೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಪೂಲ್ ತಲುಪುವ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು. ಆಲಿಸುವವನನ್ನು ತೆರೆಯುವುದು ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ನೀಡುವುದಿಲ್ಲ. ಸ್ಥಾಪಿತವಾಗಿ ಉಪಯುಕ್ತ ಸಂಚಾರ ಸಾಗಿಸದ ಟನೆಲ್ ಸಾಮಾನ್ಯವಾಗಿ ದೃಢೀಕರಣದಲ್ಲಿ ಅಲ್ಲ, ಇಲ್ಲಿಯೇ ವಿಫಲವಾಗುತ್ತದೆ. ಯಶಸ್ವಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ರೋಗನಿರ್ಣಯದ ಅಂತ್ಯವಲ್ಲ, ಆರಂಭ ಎಂದು ಪರಿಗಣಿಸಿ.

ಯೋಜನೆಯನ್ನು ಮೂರು ನಿರ್ದಿಷ್ಟ ನಿರ್ಣಯಗಳಾಗಿ ಬರೆಯಿರಿ: ಕ್ಲೈಂಟ್‌ಗಳು ಯಾವ ಮೂಲ ಶ್ರೇಣಿ ಪಡೆಯುತ್ತಾರೆ, ಅವರ ಸಂಚಾರ ಇಂಟರ್ನೆಟ್‌ಗೆ ಹೇಗೆ ಹೊರಡುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಗಳು ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಹೇಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತವೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಕರ್ನಲ್ ಯೋಜನೆಗೆ ಒಪ್ಪುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಇದರಿಂದ ಸದ್ದಿಲ್ಲದ ಅಸಾಮರಸ್ಯವನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯ ದೋಷ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸದಿರಿ.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 ವಿಚಾರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ಧರಿಸಿ

IPv6 ಗೇಟ್‌ವೇಗೆ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವ ಹಲವು ಕಾರ್ಯವಿಧಾನಗಳ ಮೂಲಕ ಬರುತ್ತದೆ: ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನಲ್ಲಿ ವಿಳಾಸ, ರೂಟ್ ಮಾಡಿದ ಪೂರ್ವಪ್ರತ್ಯಯ, ಅಥವಾ ಏನೂ ಇಲ್ಲ. ಕೇವಲ ರೂಟ್ ಮಾಡಿದ ಪೂರ್ವಪ್ರತ್ಯಯವು ಸರ್ವರ್ ಸಾಮಾನ್ಯ ರೀತಿಯಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ವಿಳಾಸಗಳನ್ನು ನೀಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ IPv6 ವಿಳಾಸವು ಬಳಸಬಹುದಾದ ಕ್ಲೈಂಟ್ ಪೂರ್ವಪ್ರತ್ಯಯ ಎಂದರ್ಥ ಎಂಬ ಊಹೆ ನಂತರ ಅರ್ಧ ಮುರಿದ ಸಂಪರ್ಕವಾಗಿ ಕಾಣುವ ತಪ್ಪು. ಇದು IPv4 ಮಾತ್ರ ಬಳಸಿ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯನ್ನೂ ದಾಟಿ ಉಳಿಯುವ ದೋಷದ ಪ್ರಕಾರ.

ಪೂರೈಕೆದಾರರು ಯಾವುದೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ರೂಟ್ ಮಾಡದಿದ್ದರೆ, ಟನೆಲ್ IPv4 ಮಾತ್ರವೇ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅದನ್ನು ತಿಳಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ಸಂಪರ್ಕಿತ ಬಳಕೆದಾರರಿಗೆ IPv6 ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಕಪ್ಪು ಕುಳಿಗೆ ಎಸೆಯುವ ಭಾಗಶಃ ಸಂರಚನೆಗಿಂತ ದಾಖಲಿತ ಅನುಪಸ್ಥಿತಿ ಸುರಕ್ಷಿತ.

ಬಾಹ್ಯ ಕ್ಲೈಂಟ್‌ನಿಂದ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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