Pi ನಲ್ಲಿ ಹಾಟ್ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ಗಳು TUN VPN ಮೂಲಕ ಮನೆಯ LAN ತಲುಪುವುದಿಲ್ಲ

ವಿಳಾಸ ಸಿಗುತ್ತದೆ ಆದರೆ ಮನೆಯ ಹಂಚಿಕೆ ತೆರೆಯಲಾಗದ ಹಾಟ್ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಸೇತುವೆ ಅಲ್ಲ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು. TUN ಮಾರ್ಗ, ಪ್ರಿಫಿಕ್ಸ್ ಮಾಲೀಕರು ಮತ್ತು NAT ಅನ್ನು ಟ್ರೇಸ್ ಮಾಡಿ.

ಸ್ಥಳೀಯ Wi-Fi ಮತ್ತು Ethernet ಕ್ಲೈಂಟ್ಗಳು Pi ಯ ಹಾಟ್ಸ್ಪಾಟ್ಗೆ ಸೇರುತ್ತವೆ, ಅದರ DHCP ವ್ಯಾಪ್ತಿಯಿಂದ ವಿಳಾಸ ಪಡೆಯುತ್ತವೆ ಮತ್ತು ದೂರಿಲ್ಲದೆ ಇಂಟರ್ನೆಟ್ ಪುಟಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತವೆ. ನಂತರ ಅದೇ ಕ್ಲೈಂಟ್ಗಳು ಮನೆಯ LAN ನಲ್ಲಿ ಫೈಲ್ ಹಂಚಿಕೆ ಅಥವಾ ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ತೆರೆದಾಗ ಸಮಯ ಮೀರುತ್ತದೆ, ಆದರೆ Pi ಸ್ವತಃ ಸುರಂಗದ ಮೂಲಕ ಆ LAN ತಲುಪುತ್ತದೆ. ವೈರ್ಲೆಸ್ ಪದರದಲ್ಲಿ ಏನೂ ಮುರಿದಿಲ್ಲ. ಕೊರತೆಯಿರುವುದು ರೂಟ್ ಮಾಡಿದ ಒಪ್ಪಂದ: ಹಾಟ್ಸ್ಪಾಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು TUN ಇಂಟರ್ಫೇಸ್ಗೆ ಒಯ್ಯಬೇಕು, ಮತ್ತು ಮನೆಯ ಕಡೆ ಯಾವುದೋ ಉತ್ತರಗಳನ್ನು ಅಲ್ಲಿಗೆ ಹೇಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ತಿಳಿದಿರಬೇಕು. ಒಂದು ಪ್ಯಾಕೆಟ್ ಪ್ರಯಾಣ ಪೂರ್ಣಗೊಳಿಸುವ ಮೊದಲು ಎರಡೂ ಅರ್ಧಗಳು ಇರಬೇಕು.

ಮೂರು ವಿಭಿನ್ನ ಕೆಲಸಗಳೊಂದಿಗೆ ಮೂರು ಸಂಪರ್ಕಗಳು

Linux Ethernet ಸೇತುವೆ ಗಮ್ಯಸ್ಥಾನ MAC ವಿಳಾಸದ ಪ್ರಕಾರ ಫ್ರೇಮ್ಗಳನ್ನು ರವಾನಿಸುತ್ತದೆ. OpenVPN TUN ಮೋಡ್ನಲ್ಲಿ IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಒಯ್ಯುತ್ತದೆ ಮತ್ತು MAC ಪದರವೇ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಸ್ಥಳೀಯ ಸೇತುವೆ ಸೇರಿಸಿದರೆ ಸುರಂಗವು ಪೋರ್ಟ್ ಆಗಿ ಎಂದಿಗೂ ನೋಂದಾಯಿಸುವುದಿಲ್ಲ. ಕರ್ನಲ್ TUN/TAP ದಾಖಲೆಗಳು ಆ ವಿಭಜನೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ: TAP ಸಾಧನವು Ethernet ಇಂಟರ್ಫೇಸ್ನಂತೆ ಕಾಣುತ್ತದೆ, TUN ಸಾಧನವು ಹಾಗಲ್ಲ. ಎರಡು ಸ್ಥಳೀಯ ಪೋರ್ಟ್ಗಳನ್ನು ಸೇತುವೆ ಮಾಡಿ ನಂತರ ರೂಟ್ ಮಾಡುವ ವಿನ್ಯಾಸವು ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು ಏನೇ ಹೇಳಿದರೂ ರೂಟರ್ ಆಗಿದೆ.

ಆ ವ್ಯತ್ಯಾಸವು ಮಾಲೀಕತ್ವವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ಗಳ ಸಬ್ನೆಟ್, ಅವರ ಡಿಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಮತ್ತು ಆ ವ್ಯಾಪ್ತಿಯ DHCP ಅಧಿಕಾರ Pi ಯ ಸ್ಥಳೀಯ ಯೋಜನೆಗೆ ಸೇರಿದೆ. ಮನೆಯ DHCP ಪ್ರಸಾರಗಳು ರೂಟ್ ಮಾಡಿದ ಸುರಂಗವನ್ನು ದಾಟುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ಸೇತುವೆ ಸೆಟ್ಟಿಂಗ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ; ಕ್ಲೈಂಟ್ಗಳನ್ನು ಮನೆಯ DHCP ಸರ್ವರ್ಗೆ ತೋರಿಸುವುದು ತನ್ನದೇ ವೈಫಲ್ಯ ವಿಧಾನಗಳಿರುವ ಪ್ರತ್ಯೇಕ, ಉದ್ದೇಶಪೂರ್ವಕ ರಿಲೇ ವಿನ್ಯಾಸವಾಗಿದೆ.

ಮೋಡೆಮ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಸೇತುವೆಯ ಹೊರಗೂ ಇರಿಸಿ. PPP ಸಂಪರ್ಕವು ಬೇರೆ ಲೇಬಲ್ ಹೊತ್ತ Ethernet ಸಾಧನವಲ್ಲ, ಮತ್ತು pppd ನ ದಾಖಲಿತ ಡಿಫಾಲ್ಟ್-ರೂಟ್ ತರ್ಕವು IPCP ಮಾತುಕತೆಗಳ ನಂತರ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಆ ಕೊಂಡಿ ಬಿದ್ದಾಗ ತನ್ನ ಮಾರ್ಗವನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ. DHCP ಟೆಂಪ್ಲೇಟ್ ನಕಲಿಸಿ ಪ್ರತಿ usb0 ಅನ್ನು ppp0 ಎಂದು ಮರುನಾಮಕರಣ ಮಾಡುವುದು ಗೇಟ್ವೇ, ಮೆಟ್ರಿಕ್ ಅಥವಾ ಜೀವನಚಕ್ರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಯಾವುದೇ ಕಾನ್ಫಿಗ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿ

ಅತಿವ್ಯಾಪಿತ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಂಜೆಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ, ಏಕೆಂದರೆ ಅತಿವ್ಯಾಪನೆ ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿದ್ದಾಗಲೂ ಮಾರ್ಗ ಹುಡುಕಾಟವನ್ನು ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ. Pi ಯಲ್ಲಿ ಈಗಾಗಲೇ ಇರುವುದನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಫಲಿತಾಂಶವನ್ನು ನಾಲ್ಕು ಪ್ರತ್ಯೇಕ ಕೊಳಗಳಾಗಿ ಓದಿ.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

ಮೊದಲ ಕೊಳವು ಕ್ಯಾರಿಯರ್ ಮೋಡೆಮ್ಗೆ ನೀಡಿದ underlay ವಿಳಾಸ; ಅದು ಕ್ಲೈಂಟ್ ಕಡೆಗಿನ ಪ್ರತಿ ಯೋಜನೆಯ ಹೊರಗೆ ಇರಬೇಕು. ಎರಡನೆಯದು ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡಿದ ಸುರಂಗ ಸಬ್ನೆಟ್, ಸಾಮಾನ್ಯವಾಗಿ ಅದರದೇ ಖಾಸಗಿ /24 ನೆಟ್ವರ್ಕ್. ಮೂರನೆಯದು ಹಾಟ್ಸ್ಪಾಟ್ ಸೇತುವೆ, ಮತ್ತು ನಾಲ್ಕನೆಯದು ನೀವು ತಲುಪಲು ಬಯಸುವ ಮನೆಯ ಪ್ರಿಫಿಕ್ಸ್. ಈ ನಡಿಗೆಯಲ್ಲಿ ಹಾಟ್ಸ್ಪಾಟ್ಗೆ 172.28.90.0/24 ಸಿಗುತ್ತದೆ, ಸೇತುವೆ 172.28.90.1 ನಲ್ಲಿದೆ, ಮತ್ತು ಮನೆಯ ಸೇವಾ LAN 192.168.77.0/24 ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಇದು ಗ್ರಾಹಕ ರೂಟರ್ಗಳೊಂದಿಗೆ ಬರುವ 192.168.1.0/24 ಮತ್ತು 10.0.0.0/24 ಡಿಫಾಲ್ಟ್ಗಳನ್ನು ಮತ್ತು 100.64.0.0/10 ಕ್ಯಾರಿಯರ್ ವ್ಯಾಪ್ತಿಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ಹಾಟ್ಸ್ಪಾಟ್ನ DHCP ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಸೇತುವೆಯ ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಗೇಟ್ವೇ ಎಂದು ಘೋಷಿಸಿ, ಬೇರೇನೂ ಅಲ್ಲ. ಹಾಟ್ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಎಂದಿಗೂ ಗೇಟ್ವೇ ಆಗಿ ಮನೆಯ ವಿಳಾಸ ಕೊಡಬೇಡಿ; ಆ ವಿಭಾಗಕ್ಕೆ ಅವರಿಗೆ ಲಿಂಕ್-ಪದರದ ಮಾರ್ಗವಿಲ್ಲ.

ಪ್ರತಿ ದಿಕ್ಕನ್ನು ಅದನ್ನು ಹೊಂದಿರುವ ಬದಿಯಲ್ಲೇ ರೂಟ್ ಮಾಡಿ

Pi ಗೆ ಸುರಂಗದ ಮೂಲಕ ಮನೆಯ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಮಾರ್ಗ ಬೇಕು. ಸರ್ವರ್ ಮೋಡ್ನಲ್ಲಿರುವ ಸರ್ವರ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಆ ಮಾರ್ಗವನ್ನು ತಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಮೊದಲು ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಇದೆ ಎಂದು ಮತ್ತು ಕರ್ನಲ್ tun0 ನಿಂದ ಮನೆಯ ವಿಳಾಸವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get ಇನ್ನೂ underlay ಇಂಟರ್ಫೇಸ್ ವರದಿ ಮಾಡಿದರೆ, ಅಲ್ಲೇ ನಿಲ್ಲಿಸಿ; ಮಾರ್ಗದ ಮುಂದಿನ ಯಾವುದೂ ತಪ್ಪು ಹುಡುಕಾಟವನ್ನು ಸರಿಪಡಿಸಲಾಗದು.

ಮನೆಯ ಸಾಧನಗಳಿಗೆ 172.28.90.0/24 ಗೆ ಮಾರ್ಗವಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವುಗಳ ಉತ್ತರಗಳು ಡಿಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಅನ್ನು ಅನುಸರಿಸಿ ರೂಟರ್ನಲ್ಲಿ ಸಾಯುತ್ತವೆ. ಎರಡು ಬೆಂಬಲಿತ ದುರಸ್ತಿಗಳಿವೆ. ಒಂದೋ ಮನೆಯ ರೂಟರ್ನಲ್ಲಿ ಹಾಟ್ಸ್ಪಾಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು VPN ಸರ್ವರ್ನ LAN ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ ಸ್ಥಿರ ಮಾರ್ಗ ಸೇರಿಸಿ, ಅಥವಾ ಸರ್ವರ್ ಸ್ವತಃ ಗೇಟ್ವೇ ಆಗಿದ್ದಾಗ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸರ್ವರ್ನ ಸ್ವಂತ ರೂಟಿಂಗ್ ಟೇಬಲ್ನಲ್ಲಿ ನೋಂದಾಯಿಸಿ. OpenVPN ನ ಬಹು-ಕ್ಲೈಂಟ್ ಮೋಡ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿ ಆ ಸಂಬಂಧವನ್ನು ಹೊತ್ತಿರುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರದ ಸಾಮಾನ್ಯ ಹೆಸರಿನಿಂದ ಹೆಸರಿಸಲಾದ ಫೈಲ್, ಅದರಲ್ಲಿ iroute 172.28.90.0 255.255.255.0 ಜೊತೆಗೆ ಅದನ್ನು ಸರ್ವರ್ ಕರ್ನಲ್ನಲ್ಲಿ ಸ್ಥಾಪಿಸುವ ಹೊಂದಿಕೆಯ route ಸಾಲು ಇರುತ್ತದೆ. ಸರ್ವರ್ನಲ್ಲಿ ಊಹಿಸಿದ ಕರ್ನಲ್ ಮಾರ್ಗವು ಯಾವ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂದು ಸರ್ವರ್ಗೆ ಹೇಳುವುದಕ್ಕೆ ಸಮಾನ ಹೇಳಿಕೆಯಲ್ಲ.

ಇದು ಕೆಲಸ ಮಾಡಲು ಮನೆಯ ನೆಟ್ವರ್ಕ್ನ DHCP ಸೇವೆಯನ್ನು VPN ಸರ್ವರ್ಗೆ ಸ್ಥಳಾಂತರಿಸಬೇಡಿ. ಇಡೀ ಮನೆಗೆ ಡಿಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಬದಲಾಯಿಸುವುದು ಒಂದು ಖಾಸಗಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಸೇರಿಸುವುದಕ್ಕಿಂತ ದೊಡ್ಡ ಬದಲಾವಣೆ, ಮತ್ತು ಅದು DNS, ವಿಳಾಸ ಕಾಯ್ದಿರಿಸುವಿಕೆಗಳು ಮತ್ತು ಹೊಸ ಗುತ್ತಿಗೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಪ್ರತಿ ಸಾಧನವನ್ನು ವೈಫಲ್ಯಕ್ಕೆ ಎಳೆಯುತ್ತದೆ.

ಫೈರ್ವಾಲ್ ಬಗ್ಗೆ ಊಹಿಸದೆ ಫಾರ್ವರ್ಡಿಂಗ್ ತೆರೆಯಿರಿ

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 ನಿಂದ tun0 ಗೆ ಅಂಗೀಕಾರ ನಿಯಮ ಮತ್ತು ಹೊಂದಿಕೆಯ ಉತ್ತರ ದಿಕ್ಕು, ಮತ್ತು ಮೂಲವನ್ನು ಮರುಬರೆಯಬಹುದಾದ postrouting ನಿಯಮವನ್ನು ಹುಡುಕಿ. ಸರಪಳಿ ನೀತಿ drop ಆಗಿದ್ದು ಯಾವ ನಿಯಮವೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ನೀತಿಯನ್ನು accept ಗೆ ತಿರುಗಿಸುವ ಬದಲು ಸಂಕುಚಿತ ಅಂಗೀಕಾರಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ.

ಅನುವಾದವು ಅಗತ್ಯವಲ್ಲ, ನೀತಿಯ ಆಯ್ಕೆ. ಮನೆಯ LAN ಕಡೆಗೆ ಮೂಲ NAT ಪ್ರತಿ ಹಾಟ್ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ ಅನ್ನು Pi ಯ ಸುರಂಗ ವಿಳಾಸದಂತೆ ತೋರಿಸುತ್ತದೆ, ಇದು ಮನೆಯ ಲಾಗ್ಗಳಲ್ಲಿ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಆರೋಪಣೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಮೂಲ ಮೂಲವನ್ನು ನಿರೀಕ್ಷಿಸುವ ಸೇವೆಗಳನ್ನು ಮುರಿಯುತ್ತದೆ. NAT ಇಲ್ಲದ ರೂಟಿಂಗ್ ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ಗೋಚರವಾಗಿ ಇಡುತ್ತದೆ ಆದರೆ ಮೇಲಿನ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು DNS ಹಾಗೂ IPv6 ಅನ್ನು ಅದೇ ರೀತಿ ನಿರ್ವಹಿಸಿ, ಏಕೆಂದರೆ ಮುರಿದ IPv6 ಮಾರ್ಗದ ಪಕ್ಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ IPv4 ಮಾರ್ಗವು ಬ್ರೌಸರ್ನಲ್ಲಿ ಇನ್ನೂ ಅರ್ಧ ಮುರಿದಂತೆಯೇ ಓದಲ್ಪಡುತ್ತದೆ.

ಬರುವ-ಹೋಗುವ ಪ್ರಯಾಣವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮುರಿಯಿರಿ

ಹಾಟ್ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಎಂದಿಗೂ Pi ಯಿಂದ ಅಲ್ಲ, ಏಕೆಂದರೆ Pi ಯ ಸ್ವಂತ ಸಂಚಾರವು ಮುಂದಿನ ಮತ್ತು ಹಿಂತಿರುಗುವ ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ. ಒಬ್ಬ ಕ್ಲೈಂಟ್ ಮನೆಯ ಸೇವೆ ತಲುಪಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಎರಡೂ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಗಮನಿಸಿ.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

ಎರಡೂ ಕ್ಯಾಪ್ಚರ್ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ. br0 ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡು tun0 ನಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣದ ವಿನಂತಿಗಳು Pi ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತಿಲ್ಲ ಅಥವಾ ಮಾರ್ಗ ಬೇರೆಡೆ ತೋರಿಸುತ್ತದೆ ಎಂದು ಅರ್ಥ. tun0 ನಲ್ಲಿ ಉತ್ತರವಿಲ್ಲದ ವಿನಂತಿಗಳು ಮನೆಯ ಕಡೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲ ಅಥವಾ ಸರ್ವರ್ ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ ಮಾಡಿದೆ ಎಂದು ಅರ್ಥ. tun0 ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡು br0 ನಲ್ಲಿ ಮತ್ತೆ ಕಾಣದ ಉತ್ತರಗಳು ವಿರುದ್ಧ ಫಿಲ್ಟರ್ ನಿಯಮ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ಅರ್ಥ, ಅಲ್ಲಿ ಸುರಂಗ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಏನನ್ನೂ ಕಾಣುವುದಿಲ್ಲ.

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

ಹಾಟ್ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ ಮನೆಯ ಹೆಸರನ್ನು ಪರಿಹರಿಸಬಹುದು, TCP ಸೇವೆ ತೆರೆಯಬಹುದು ಮತ್ತು ಒಂದು ಮೋಡೆಮ್ ಮರುಸಂಪರ್ಕದ ಉದ್ದಕ್ಕೂ ಸೆಷನ್ ಜೀವಂತವಾಗಿ ಇಡಬಹುದು ಆಗ ಮಾತ್ರ ವಿನ್ಯಾಸವನ್ನು ಸ್ವೀಕರಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿಯೂ ಮನೆಯ ವಿಭಾಗದಲ್ಲಿ Ethernet ಮಟ್ಟದ ಅನ್ವೇಷಣೆ ಬಯಸಿದರೆ, ಸ್ಥಳೀಯ ಸೇತುವೆಯನ್ನು ಸೇತುವೆ ಎಂದು ವಿವರಿಸಿ ಪ್ರಸಾರ ಬರುವವರೆಗೆ ಕಾಯುವ ಬದಲು ಬೆಂಬಲಿತ Layer 2 ವಿನ್ಯಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು