VPN ಮತ್ತು ವೆಬ್‌ಗಾಗಿ ಒಂದೇ ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್: ಪಾತ್ರಗಳನ್ನು ಹೇಗೆ ವಿಭಜಿಸುವುದು

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

ಮುಂದಿನದು ನಿರ್ಧಾರ ಪ್ರಕ್ರಿಯೆ, ನಿರ್ಮಾಣ ಹಾಳೆ ಅಲ್ಲ. ಪ್ರತಿ ಹಂತವು ಈಗಷ್ಟೇ ಸೇರಿಸಿದ ಪಾತ್ರ ನಿಜವಾಗಿಯೂ ಪ್ರತ್ಯೇಕವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಪೋರ್ಟ್‌ಗಳಿಗಿಂತ ಮೊದಲು ವಿಳಾಸದ ಮಾಲೀಕರನ್ನು ಆಯ್ಕೆಮಾಡಿ

ಟನೆಲ್‌ನ ಅಂತಿಮ ಬಿಂದು ಮತ್ತು ವೆಬ್ ಸರ್ವರ್ ಒಂದೇ ಕರ್ನಲ್ ಹಂಚಿಕೊಳ್ಳಬಹುದು; ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಂದು ವಿಳಾಸ, ಪೋರ್ಟ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಹಂಚಿಕೊಳ್ಳುವುದೇ ವಿಫಲವಾಗುವುದು. WireGuard ಸಾಮಾನ್ಯವಾಗಿ UDP 51820 ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, OpenVPN UDP 1194 ಅಥವಾ TCP 443 ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ವೆಬ್ ಸರ್ವರ್ TCP 443 ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನೋವು ಕೊಡುವ ಜೋಡಿ ಎಂದರೆ HTTPS ಪಕ್ಕದಲ್ಲಿ TCP 443 ಮೇಲಿನ OpenVPN, ಏಕೆಂದರೆ ಎರಡೂ ಒಂದೇ ಸಾಕೆಟ್ ಬಯಸುತ್ತವೆ ಮತ್ತು ಕರ್ನಲ್ ಅದನ್ನು ಮೊದಲು ಬೈಂಡ್ ಮಾಡಿದವರಿಗೆ ಕೊಡುತ್ತದೆ. ಮುಂದೆ ಇರುವ ಡಿಮಲ್ಟಿಪ್ಲೆಕ್ಸರ್ ಮಾತ್ರ, ಉದಾಹರಣೆಗೆ sslh ಅಥವಾ TLS ತಿಳಿದ ಪ್ರಾಕ್ಸಿ, ಅವುಗಳಿಗೆ ಆ ಪೋರ್ಟ್ ಹಂಚಿಕೊಳ್ಳಲು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಅದು ವೈಫಲ್ಯವು ಫೈರ್‌ವಾಲ್ ಸಮಸ್ಯೆಯಂತೆಯೇ ಕಾಣುವ ಘಟಕವನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಮಾಲೀಕರನ್ನು ನೋಡಿ: ss -lntup ಕೇಳುತ್ತಿರುವ ಪ್ರತಿ ಸಾಕೆಟ್‌ನ ಸ್ಥಳೀಯ ವಿಳಾಸ, ಪೋರ್ಟ್ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ತೋರಿಸುವ ಎರಡು ಸಾಲುಗಳು 0.0.0.0:443 ಎಂದರೆ ಎರಡನೇ ಸೇವೆ ಎಂದಿಗೂ ಬೈಂಡ್ ಆಗಿಲ್ಲ, ಅದರ init ಸ್ಕ್ರಿಪ್ಟ್ ಎಷ್ಟೇ ಉಲ್ಲಾಸದ್ದಾಗಿದ್ದರೂ. ಬ್ರಿಡ್ಜಿಂಗ್ ಕೂಡ ಮಾಲೀಕರನ್ನು ಸರಿಸುತ್ತದೆ. ಯಾವಾಗ eth0 ಮತ್ತು br0 ಸೇರಿದಾಗ, IP br0 ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು eth0 ಎಂದು ಹೆಸರಿಸುವ ಪ್ರತಿ ಫೈರ್‌ವಾಲ್ ನಿಯಮವೂ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸೇವೆಗಳನ್ನು ಬ್ರಿಡ್ಜ್‌ನಲ್ಲಿ ಬೈಂಡ್ ಮಾಡಿ ಮತ್ತು ip -br addr ನಿಂದ ದೃಢೀಕರಿಸಿ.

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

ಎರಡು LAN ನಡುವೆ ರೂಟ್ ಮಾಡಿ ಅಥವಾ ಒಂದು ಬದಿಯನ್ನು NAT ಮಾಡಿ

ಒಂದನ್ನೊಂದು ನೋಡದ ಎರಡು LAN ಪ್ರತಿಯೊಂದೂ ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್‌ಗೆ ಕರೆ ಮಾಡಬಹುದು, ಅದು ನಂತರ ಟನೆಲ್‌ಗಳ ನಡುವೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ಆ ರೂಟೆಡ್ ವಿನ್ಯಾಸಕ್ಕೆ ಮೂರು ವಿಷಯಗಳು ಬೇಕು: ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್, ಪ್ರತಿ ದೂರದ ಪೂರ್ವಪ್ರತ್ಯಯದ ಕಡೆಗೆ ರೂಟ್, ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಹಾದುಹೋಗಲು ಬಿಡುವ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ. sysctl -w net.ipv4.ip_forward=1 ಮೊದಲನೆಯದನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ip route add 10.20.0.0/24 dev wg1 ಎರಡನೆಯದನ್ನು, ಮತ್ತು nftables ಸಾಲು nft add rule inet filter forward iifname "wg0" oifname "wg1" accept ಮೂರನೆಯದನ್ನು.

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

ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ಅದೇ ಪೆಟ್ಟಿಗೆ ಒಳಬರುವ ಟನೆಲ್‌ಗಳನ್ನು ಕೊನೆಗೊಳಿಸುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಅತಿಕ್ರಮಿಸುವ ವಿಳಾಸಗಳು ಮಾತ್ರ ತಡೆಯುತ್ತವೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ವಿಳಾಸ ಯೋಜನೆ ಮುಖ್ಯವಾದ ದಾಖಲೆ.

ಎರಡು ಪಾತ್ರಗಳು ನಿಂತಿರುವಾಗ ವಿಭಜನೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ಮೂರು ಆದೇಶಗಳು ಆ ಪರೀಕ್ಷೆಯನ್ನು ಮೂರ್ತಗೊಳಿಸುತ್ತವೆ. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ ಬಾಹ್ಯ DNS ಇಲ್ಲದೆ ಸ್ಥಳೀಯ ಆಲಿಸುವವರು ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, wg show ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು tcpdump -ni any port 51820 ಹಬ್‌ನಲ್ಲಿ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಕೀ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಸೆರೆಹಿಡಿಯುವಿಕೆಯಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಹೋಸ್ಟ್‌ಗಿಂತ ಮೊದಲೇ ಸತ್ತಿದೆ: ಪೂರೈಕೆದಾರರ ಫೈರ್‌ವಾಲ್, ತಪ್ಪು ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಅಥವಾ ದಾರಿಯಲ್ಲಿ NAT ನಿಯಮ.

ಫಾರ್ವರ್ಡ್ ಆಗುವ LAN ಗಳಿಗೆ ಕಳೆಯುವಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಒಂದು ಪೀರ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಾಗ ಹಬ್ ಮೂಲಕ ಪಿಂಗ್ ವಿಫಲವಾಗಬೇಕು; ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡಾಗ ಪಿಂಗ್ ಯಾವುದೇ ನಿಯಮ ಮುಟ್ಟದೆ ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು. ಟನೆಲ್ ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ ಮಾತ್ರ ಚೇತರಿಸಿಕೊಳ್ಳುವ ಪಿಂಗ್ ತಲುಪುವಿಕೆಗಲ್ಲ, ನೀತಿಗೆ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆ.

ಪಾತ್ರಗಳನ್ನು ಕಳೆಯುವಾಗ ನಿಯಮ ಸಮೂಹವನ್ನು ಓದಬಹುದಾಗಿ ಇರಿಸಿ. nft list ruleset ನಿಜವಾಗಿ ಬೇಕಾದ ಪ್ರತಿ ದಿಕ್ಕಿಗೆ ಒಂದು ಸ್ವೀಕಾರ ನಿಯಮವನ್ನು ತೋರಿಸಬೇಕು, ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುವ ಫಾರ್ವರ್ಡ್ ಸರಪಳಿ ವಿಭಜನೆ ಅಲ್ಲ, ಅದು ಕೆಲಸ ಮಾಡುವ ಡೆಮೊ.

IPv6 ಮಾತ್ರ ಪ್ರವೇಶ ಮಾರ್ಗಗಳು ಮತ್ತು IPv4 ಸೇವೆಗಳು

ಕೆಲವು ಪ್ರವೇಶ ಮಾರ್ಗಗಳು IPv6 ತಲುಪುವಿಕೆಯನ್ನು ಮಾತ್ರ ನೀಡುತ್ತವೆ, ಮತ್ತು ಸೇವೆಗಳನ್ನು ಇನ್ನೂ IPv4 ಮೇಲೆ ಪ್ರಕಟಿಸಬೇಕು. ಟನೆಲ್ ಸ್ವತಃ ಇನ್ನೂ ಸಂಚಾರವನ್ನು ಹಾದುಹೋಗಲು ಬಿಡುವ ಕುಟುಂಬದ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಆದರೆ ಪ್ರಕಟಿತ ಸೇವೆ ಟನೆಲ್ ಒಳಗಿನ ವಿಳಾಸದಲ್ಲಿ ಕುಳಿತಿದೆ. ಇದು ಸಾಮಾನ್ಯ ಊಹೆಯನ್ನು ತಿರುಗಿಸುತ್ತದೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಮೌನವಾಗಿ ಮುರಿಯುತ್ತದೆ: IPv4 ಮಾರ್ಗಕ್ಕಾಗಿ ಬರೆದ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಅಥವಾ ಅಪ್ಟೈಮ್ ಪರಿಶೀಲನೆ ಈಗ ಏನನ್ನೂ ಸಾಗಿಸದ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಗಮನಿಸುತ್ತದೆ.

ಪ್ರತಿ ಕುಟುಂಬವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ curl -4 ಮತ್ತು curl -6 ನಿಂದ, ಏಕೆಂದರೆ ಒಂದು ಯಶಸ್ವಿ ವಿನಂತಿ ನೀವು ಪ್ರಯತ್ನಿಸದ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪೋರ್ಟ್ ಮಾಲೀಕತ್ವ ಕುಟುಂಬಗಳ ನಡುವೆ ಬದಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಆಲಿಸುವವರು ಬದಲಾಗುತ್ತಾರೆ: ss -lntup IPv4 ಮತ್ತು IPv6 ಸಾಕೆಟ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು 0.0.0.0:443 ಕವರ್ ಮಾಡುವುದಿಲ್ಲ [::]:443 ಅನ್ನು, ಪ್ರಕ್ರಿಯೆ dual-stack ಸಾಕೆಟ್ ಕೇಳದಿದ್ದರೆ.

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