NAT ಹಿಂದಿನ OpenVPN ಕ್ಲೈಂಟ್ ಹೇಗೆ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾಗುತ್ತದೆ

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

ಮುಂದಿನದು ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ರಮವಲ್ಲ, ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಯಾವ ಘಟಕ ಯಾವ ನಿರ್ಣಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ತಿಳಿದಾಗ ಮಾತ್ರ ಕಾನ್ಫಿಗರೇಶನ್ಗೆ ಅರ್ಥವಿದೆ. ಪ್ರತಿ ಪದರವೂ ನಿಖರವಾಗಿ ಒಂದು ನಿರ್ಣಯವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ತಪ್ಪುಗಳು ಎರಡು ಪದರಗಳನ್ನು ಒಂದೆಂದು ಪರಿಗಣಿಸುವಲ್ಲಿ ಸೇರುತ್ತವೆ.

ಎರಡು ಸಾಗಣೆ ಅಧಿವೇಶನಗಳು, ಒಂದು ಒಳಮಾರ್ಗ

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

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

iroute ಸರ್ವರ್ ಒಳಗೆ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ

ಹಬ್ ಮಾತ್ರ ಯಾವ ಸಹಚರ ಯಾವ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಿರ್ಧರಿಸುವ ಸಾಧನ, ಮತ್ತು ಆ ನಿರ್ಣಯವನ್ನು ಕರ್ನಲ್ನಲ್ಲಿ ಅಲ್ಲ, ತನ್ನದೇ ಬಳಕೆದಾರ ಸ್ಥಳ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನಿರ್ಗಮನಕ್ಕಾಗಿ exit-node ಎಂಬ client-config-dir ನಮೂದು ಅಲ್ಲಿ ಪೂರ್ವನಿರ್ಧಾರಿತ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಕೇಳಬಹುದು:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

ಆ ಸಾಲು ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಗೆ "ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನವಿರುವ ಒಳ ಪ್ಯಾಕೆಟ್ಗಳು ಈ ಕ್ಲೈಂಟ್ನವು" ಎಂದು ಹೇಳುತ್ತದೆ. ಅದು ಹಬ್ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂಗೆ ಪೂರ್ವನಿರ್ಧಾರಿತ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಹಬ್ ಅನ್ನು ಇಂಟರ್ನೆಟ್ ಗೇಟ್ವೇ ಮಾಡುವುದಿಲ್ಲ. OpenVPN 2.6 ಉಲ್ಲೇಖ ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಒಳ ರೂಟಿಂಗ್ ಮತ್ತು ಕರ್ನಲ್ ರೂಟಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಿಧಾನಗಳಾಗಿ ಇಡುತ್ತದೆ, ಮತ್ತು ಆ ಪ್ರತ್ಯೇಕತೆಯೇ ಹಬ್ನ ಪೂರ್ವನಿರ್ಧಾರಿತ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟದೆ ಈ ವಿನ್ಯಾಸ ಕೆಲಸ ಮಾಡುವ ಕಾರಣ.

ಗ್ರಾಹಕರಿಗೆ ಕನ್ನಡಿ ಸೂಚನೆ ಬೇಕು, push ಆಗಿ ತಲುಪಿಸಲ್ಪಟ್ಟು, ಅವರ ಸ್ವಂತ ಸಂಚಾರ ಸ್ಥಳೀಯ ಗೇಟ್ವೇ ಮೂಲಕ ಹೊರಡುವ ಬದಲು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸಬೇಕು. ಉಪಜಾಲ ಟೋಪಾಲಜಿಯಲ್ಲಿ ಪೂಲ್ ನಿರ್ಗಮನದ tun ಸಾಧನದಲ್ಲಿ ಸಂಪರ್ಕಿತ ಮಾರ್ಗ, ಆದ್ದರಿಂದ ಮರಳು ದಿಕ್ಕಿಗೆ ಹೆಚ್ಚುವರಿ push ಬೇಕಿಲ್ಲ; ನಿರ್ಗಮನ ಪಡೆಯಬಾರದ್ದು ಕೆಳಗಿನ ಮರುನಿರ್ದೇಶನ, ಅದು ಅದರ ಸ್ವಂತ ಮೇಲ್ಮುಖ ಸಂಚಾರವನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸುರಂಗಕ್ಕೆ ಮರಳಿ ಕಳುಹಿಸುತ್ತದೆ. ಅದನ್ನು ಗ್ರಾಹಕರಿಗೆ ಮಾತ್ರ ಕಳುಹಿಸಿ ಮತ್ತು CCD ಕಡತ ಆಯ್ಕೆಯಾಗಿದೆ ಎಂದು ನಂಬುವ ಬದಲು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅನ್ವಯಿಸಿದ ಮಾರ್ಗಗಳನ್ನು ಓದಿ.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾಡುವುದು ನಿರ್ಗಮನದ ಕರ್ನಲ್

ನಿರ್ಗಮನದ ಒಳಗೆ ಗ್ರಾಹಕರಿಂದ ಪ್ಯಾಕೆಟ್ tun ಇಂಟರ್ಫೇಸ್ಗೆ ಯಾವುದೋ ಇಂಟರ್ನೆಟ್ ಹೋಸ್ಟ್ ವಿಳಾಸದಲ್ಲಿ ಬರುತ್ತದೆ. ಕರ್ನಲ್ ತನ್ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ನೋಡಿ, ಉತ್ತಮ ಹೊಂದಾಣಿಕೆಯಾಗಿ ನಿಜವಾದ ಮೇಲ್ಮುಖ ಕೊಂಡಿಯನ್ನು ಕಂಡುಕೊಂಡು ನಂತರ ಎರಡು ಸ್ವತಂತ್ರ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ: ಈ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಾದರೂ ಫಾರ್ವರ್ಡ್ ಆಗಬಹುದೇ ಮತ್ತು ಅದು ಆ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಆ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಹೊರಡಬಹುದೇ. ಫಾರ್ವರ್ಡಿಂಗ್ ಒಂದು sysctl, ಮತ್ತು ಅನೇಕ ವಿತರಣೆಗಳಲ್ಲಿ ಪೂರ್ವನಿರ್ಧಾರಿತವಾಗಿ ಆಫ್ ಇರುತ್ತದೆ.

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

ಮರಳು ಮಾರ್ಗವನ್ನು ಮೂಲ ಅನುವಾದ ಕೊಳ್ಳುತ್ತದೆ

ಇಂಟರ್ನೆಟ್ ಹೋಸ್ಟ್ಗೆ 10.90.0.x ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವಿಲ್ಲ, ಆದ್ದರಿಂದ ಉತ್ತರಗಳು ನಿರ್ಗಮನವನ್ನು ತಲುಪುವ ಮೊದಲೇ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆ. ಪ್ಯಾಕೆಟ್ ಮೇಲ್ಮುಖ ಕೊಂಡಿಯನ್ನು ಬಿಡುವಾಗ ಮೂಲವನ್ನು ಮರುಬರೆಯುವುದು ಅದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಮರಳುವಾಗ ಮರುಬರವಣಿಗೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

ಮೇಲಿನ ನಿಯಮ ಒಂದು ಮೇಲ್ಮುಖ ಇಂಟರ್ಫೇಸ್ಗೆ ಆರಂಭಿಕ ಬಿಂದು, ಫೈರ್ವಾಲ್ ನೀತಿಯಲ್ಲ. ಮೂಲವನ್ನು ನೀವು ನಿಜವಾಗಿ ಅಧಿಕಾರ ನೀಡಿದ ನಿಯೋಜನೆಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು ನಿರ್ಗಮನದ ಸ್ವಂತ ಇನ್ಪುಟ್ ನೀತಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಸುರಂಗ ಸಂಚಾರದ ಮಸ್ಕರೇಡಿಂಗ್ ಸ್ಥಳೀಯ ಸೇವೆಗಳನ್ನು ಮೌನವಾಗಿ ಬಯಲು ಮಾಡದಂತೆ. ಕ್ರಿಯಾತ್ಮಕ ಮೇಲ್ಮುಖ ವಿಳಾಸವಿರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಮಸ್ಕರೇಡ್ ವಿಳಾಸವನ್ನು ಕೈಯಿಂದ ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದನ್ನೂ ಉಳಿಸುತ್ತದೆ.

ಹಬ್ ಎಲ್ಲಿ ಜಾರಿಗೊಳಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲಿ ಸಾಧ್ಯವಿಲ್ಲ

client-to-client ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ ಬಳಕೆದಾರ ಸ್ಥಳ ದತ್ತ ಮಾರ್ಗದೊಂದಿಗೆ ಹಬ್ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಯ ಒಳಗೇ ಸಹಚರರ ನಡುವೆ ಒಳ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಹಸ್ತಾಂತರಿಸುತ್ತದೆ. ಅವು ಎಂದೂ ಹಬ್ನ ಕರ್ನಲ್ FORWARD ಸರಪಳಿಯನ್ನು ದಾಟುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅಲ್ಲಿನ ಕರ್ನಲ್ ನಿಯಮ ಎಷ್ಟೇ ಎಚ್ಚರಿಕೆಯಿಂದ ಬರೆಯಲ್ಪಟ್ಟರೂ ಸಹಚರರ ನಡುವಿನ ಸಂಚಾರವನ್ನು ಸೀಮಿತಗೊಳಿಸಲಾರದು. ಜಾರಿಗೊಳಿಸುವಿಕೆ ಸರ್ವರ್ನ ಸ್ವಂತ ನೀತಿಯಲ್ಲೇ ಇರಬೇಕು: ಯಾರಿಗೆ ಸಂಪರ್ಕಿಸಲು ಅನುಮತಿ, ಯಾವ CCD ಕಡತ ಸಿಗುತ್ತದೆ ಮತ್ತು ನಿರ್ಗಮನದ ಪೂರ್ವನಿರ್ಧಾರಿತ ಮಾಲೀಕತ್ವ ಎಲ್ಲಾದರೂ ನೀಡಲ್ಪಡುತ್ತದೆಯೇ.

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

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

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

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

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

ನಿರ್ಗಮನ ಹೋದ ನಂತರವೂ ಗ್ರಾಹಕರ ಸಂಚಾರ ಇಂಟರ್ನೆಟ್ ತಲುಪಿದರೆ, ಬೇರೆ ಯಾವುದೋ ಅದನ್ನು ಸಾಗಿಸುತ್ತಿದೆ ಮತ್ತು ನೀವು ಉದ್ದೇಶಿಸಿದ ಗಡಿ ಇಲ್ಲ. DNS ಮತ್ತು IPv6 ಅನ್ನು ಸಹ ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳಾಗಿ ಪರಿಗಣಿಸಿ: IPv4 ಮಾರ್ಗ ಮತ್ತು ಮಸ್ಕರೇಡ್ AAAA ಸಂಚಾರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಹಬ್ ತಳ್ಳಿದ ರಿಜಾಲ್ವರ್ ಪ್ರಶ್ನೆ ನಿಜವಾಗಿ ಎಲ್ಲಿಂದ ಹೊರಡುತ್ತದೆಯೋ ಅಲ್ಲಿಂದಲೇ ಉತ್ತರಿಸುತ್ತದೆ.