ನಿಮ್ಮ ಸಾರ್ವಜನಿಕ Linux ಸೇವೆ ಏಕೆ VPN ಮೂಲಕ ಉತ್ತರಿಸುತ್ತದೆ

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

ತಪ್ಪು ಗ್ರಹಿಕೆ: ಉತ್ತರಗಳು ಬಂದ ಇಂಟರ್ಫೇಸನ್ನು ಅನುಸರಿಸುತ್ತವೆ

eth0 ನಲ್ಲಿ ಬರುವ ಪ್ಯಾಕೆಟ್ eth0 ಮೂಲಕವೇ ಹೋಗಬೇಕು ಎಂದು ತಾರ್ಕಿಕವಾಗಿ ತೋರುತ್ತದೆ. ಸ್ಥಿತಿರಹಿತ ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಹಾಗೆ ಬರೆಯಬಹುದು, ಮತ್ತು ಒಳಬರುವ ಬದಿಯ tcpdump ವಿನಂತಿಯನ್ನು ನಿರೀಕ್ಷಿಸಿದ ಸ್ಥಳದಲ್ಲೇ ತೋರಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ಸ್ವತಃ ರಚಿಸುವ ಸಂಚಾರಕ್ಕೆ ಮಾರ್ಗದರ್ಶನ ಹಾಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

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

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

ಕರ್ನಲ್ ನಿಜವಾಗಿ ಏನನ್ನು ಮಾರ್ಗದರ್ಶನ ಮಾಡುತ್ತದೆ: ಮೂಲ ವಿಳಾಸ

ನಿಮಗೆ ಬೇಕಾದ ಹಿಡಿಕೆ ಎಂದರೆ ಸೇವೆ ಉತ್ತರಗಳಿಗೆ ಬಳಸುವ ಸ್ಥಳೀಯ ವಿಳಾಸ. eth0 ವಿಳಾಸ ಉದಾಹರಣೆಗೆ 192.0.2.10/24 ಮತ್ತು ಗೇಟ್‌ವೇ 192.0.2.1 ಇರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಆ ವಿಳಾಸ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಇರುತ್ತದೆ. ಕ್ಲೌಡ್ VM ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಅನುವಾದಗೊಂಡು ಅತಿಥಿಯಲ್ಲಿ ಇಲ್ಲದಿರಬಹುದು, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ನಿಜವಾಗಿ ಹೊಂದಿರುವ ವಿಳಾಸವನ್ನೇ ಬಳಸಿ.

ಕೋಷ್ಟಕ ಸಂಖ್ಯೆ ಅಥವಾ ನಿಯಮ ಆದ್ಯತೆಯನ್ನು ಕಾಯ್ದಿರಿಸುವ ಮೊದಲು ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಇರುವ ನೀತಿ ನಿಯಮಗಳು ಹೊಸದನ್ನು ಮರೆಮಾಡಬಹುದು, ಮತ್ತು ಅದೇ ಸಂಖ್ಯೆಯ ಹಳೆಯ ಕೋಷ್ಟಕ ಈಗಾಗಲೇ ಸಂಬಂಧವಿಲ್ಲದ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿರಬಹುದು:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

ಅರ್ಧ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ, ಪೂರ್ಣ ಮರಳು ಕೋಷ್ಟಕವನ್ನು ನಿರ್ಮಿಸಿ

ಕೇವಲ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವಿರುವ ಕೋಷ್ಟಕ ಸಾಕಾಗುವುದಿಲ್ಲ. ಕರ್ನಲ್ ಇನ್ನೂ ಗೇಟ್‌ವೇಯನ್ನು ಪರಿಹರಿಸಬೇಕು, ಮತ್ತು ಆ ಪರಿಹಾರಕ್ಕೆ ಅದೇ ಕೋಷ್ಟಕದಲ್ಲಿ ಸಂಪರ್ಕಿತ ಪ್ರಿಫಿಕ್ಸ್ ಬೇಕು. ಆ ಪ್ರಿಫಿಕ್ಸ್ ಇಲ್ಲದ ಕೋಷ್ಟಕವು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಸರಿಯಾಗಿ ಕಂಡರೂ ಗೇಟ್‌ವೇ ಪರಿಹಾರದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡನ್ನೂ ಸೇರಿಸಿ, ನಂತರ ಮೂಲ ನಿಯಮವನ್ನು ಕೋಷ್ಟಕದ ಕಡೆಗೆ ತೋರಿಸಿ:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

ಉದಾಹರಣೆಯನ್ನು ನಕಲಿಸುವ ಬದಲು ನಿಜವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಗೇಟ್‌ವೇ ಬಳಸಿ. ಆನ್-ಲಿಂಕ್ ಗೇಟ್‌ವೇ ಸಹಿತ /32 ಆಗಿ ಸಂರಚಿಸಿದ ಕ್ಲೌಡ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬೇರೆ ಸಂಪರ್ಕಿತ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ತಪ್ಪು ಪ್ರಿಫಿಕ್ಸ್‌ನಿಂದ ನಿರ್ಮಿಸಿದ ಕೋಷ್ಟಕ ಮೊದಲ ಹೆಜ್ಜೆಯಲ್ಲೇ ವಿಫಲವಾಗುತ್ತದೆ. src ಗುಣಲಕ್ಷಣ ಆ ಮಾರ್ಗದ ಆದ್ಯತೆಯ ಮೂಲವನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಅದು ಮೂಲ ನಿಯಮವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಕ್ರಮವೂ ಮುಖ್ಯ. ಕಡಿಮೆ ಆದ್ಯತೆ ಸಂಖ್ಯೆಯ ವಿಶಾಲ ನಿಯಮ ಮೊದಲು ಮೌಲ್ಯಮಾಪನ ಆಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಸಂಚಾರವನ್ನು ಮುಖ್ಯ ಕೋಷ್ಟಕಕ್ಕೆ ಹಿಂತಿರುಗಿಸಬಹುದಾದ ಯಾವುದೇ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ಮೂಲ ನಿಯಮವನ್ನು ತಲುಪಬೇಕು. ಸೇರಿಸಿದ ನಂತರ ip rule show ನಿಂದ ಆದ್ಯತೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಬೂಟ್‌ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲ.

ಮೂಲ-ನಿರ್ದಿಷ್ಟ ಹುಡುಕಾಟದಿಂದ ಪರಿಶೀಲಿಸಿ

ಕರ್ನಲ್‌ಗೆ ಸೇವೆಯ ವಿಳಾಸದಿಂದ ಪರೀಕ್ಷಾ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಮಾರ್ಗದರ್ಶನ ಮಾಡಲು ಹೇಳಿ. ಉತ್ತರದಲ್ಲಿ ಟನೆಲ್ ಅಲ್ಲ, eth0 ಮತ್ತು WAN ಗೇಟ್‌ವೇಯ ಹೆಸರು ಇರಬೇಕು:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

ಅಂತಿಮ ಮಾರ್ಗಗಳು ಮತ್ತು ನಿಯಮವನ್ನು ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ ಅಡಿಯಲ್ಲಿ ಇರಿಸಿ. ವಿಳಾಸ ಬದಲಾವಣೆಗಳು, DHCP ನವೀಕರಣ ಮತ್ತು VPN ಮರುಸಂಪರ್ಕಗಳು ಎಲ್ಲವೂ ಕರ್ನಲ್ ಸ್ಥಿತಿಯನ್ನು ಮರುಬರೆಯುತ್ತವೆ, ಮತ್ತು ಕೈಯಿಂದ ಸೇರಿಸಿದ ನಿಯಮವು ಮುಂದಿನ ಘಟನೆಯ ನಂತರ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ ಅಥವಾ ಹಳೆಯ ಗೇಟ್‌ವೇಯನ್ನು ತೋರಿಸುತ್ತದೆ.

ಈ ವಿನಾಯಿತಿ ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ

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

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

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

ಮೂಲ-ನಿರ್ದಿಷ್ಟ ಹುಡುಕಾಟ ಯಶಸ್ವಿಯಾದ ನಂತರವೂ ಸೇವೆ ತಪ್ಪು ಮಾರ್ಗದಲ್ಲಿ ಉತ್ತರಿಸಿದರೆ, ಲೈವ್ ಸಾಕೆಟ್‌ನ ಮೂಲ ವಿಳಾಸವನ್ನು ನಿಯಮದಲ್ಲಿರುವುದಕ್ಕೆ ಹೋಲಿಸಿ. ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಸೇವೆ ನೀವು ಪರೀಕ್ಷಿಸಿದ ವಿಳಾಸಕ್ಕಿಂತ ಬೇರೆ ಮೂಲವನ್ನು ಆಯ್ಕೆಮಾಡಬಹುದು, ಮತ್ತು ಆ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆಯೇ ಉಳಿದಿರುವ ಕೊರತೆ.