ನಿಮ್ಮ VPN ಸರ್ವರ್ ವಾಸ್ತವವಾಗಿ ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು NAT ನಿರ್ಧರಿಸುತ್ತದೆ

ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನ ವಿಳಾಸ ಎಂದಿಗೂ VPN ಸರ್ವರ್ ತಲುಪುವುದಿಲ್ಲ. NAT ಕೊನೆಯ ಹಾಪ್ನಲ್ಲಿ ಅದನ್ನು ಮರುಬರೆಯುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ನ IP ನಂತರ ನಿಗದಿಯಾಗುತ್ತದೆ. ಎರಡೂ ತುದಿಗಳನ್ನು ಹೇಗೆ ಹೋಲಿಸುವುದು.

VPN ಸರ್ವರ್ ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನ ವಿಳಾಸವನ್ನು ಪ್ಯಾಕೆಟ್ನಿಂದ ಓದಿ ಲಾಗ್ನಲ್ಲಿ ಬರೆಯುತ್ತದೆ ಎಂದು ನೀವು ಊಹಿಸುತ್ತೀರಿ. ಅದು ಓದುವುದು ಕೊನೆಯ NAT ಹಾಪ್ ಹೊರಗಿನ ಹೆಡರ್ನಲ್ಲಿ ಹಾಕಿದ್ದನ್ನು, ಮತ್ತು ಹಾಟ್ಸ್ಪಾಟ್ ಆಗಿ ಬಳಸುವ ಫೋನ್ನಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನೂರಾರು ಇತರ ಚಂದಾದಾರರೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುವ ವಿಳಾಸವಾಗಿರುತ್ತದೆ. ನಿಮ್ಮ ಯಂತ್ರದ ಸ್ವಂತ 192.168.x.x ಆ ಹೆಡರ್ನಲ್ಲಿ ಎಂದಿಗೂ ಇಂಟರ್ನೆಟ್ ದಾಟುವುದಿಲ್ಲ, ಮತ್ತು ಟನೆಲ್ ವಿಳಾಸವನ್ನು ಸಂಪರ್ಕ ಈಗಾಗಲೇ ಸ್ಥಾಪಿತವಾದ ನಂತರ ಸರ್ವರ್ ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಸರ್ವರ್ ಲಾಗ್ ಮತ್ತು ಲ್ಯಾಪ್ಟಾಪ್ನ ip addr ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಯಾವುದೂ ತಪ್ಪಿಲ್ಲ; ಅವು ಒಂದೇ ಸೆಷನ್ನ ವಿವಿಧ ಪದರಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಮೂರು ವಿಳಾಸಗಳು, ಮತ್ತು ಲಾಗ್ನಲ್ಲಿ ಒಂದೇ

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

AddressWho assigns itWhere it sitsVisible to the VPN server
Device address, e.g. 192.168.1.24Your router via DHCPOuter header, before translationNo, rewritten in place
Translated address and portRouter, ISP CGNAT, or bothOuter header, after translationYes, this is the tuple it logs
Tunnel address, e.g. 10.8.0.6The VPN server itselfInner header, after decapsulationYes, but it chose it

ಸಂಪರ್ಕದ ಕ್ಷಣದಲ್ಲಿ ಮಧ್ಯದ ಸಾಲು ಮಾತ್ರ ಅಜ್ಞಾತವಾಗಿದೆ. ಸರ್ವರ್ ಅದನ್ನು ಡೀಮನ್ ಪ್ರಕಾರ ತನ್ನ ಪೀರ್ ಕೋಷ್ಟಕ, ಸ್ಥಿತಿ ಫೈಲ್ ಅಥವಾ ಫ್ಲೋ ಲಾಗ್ಗೆ ಬರೆಯುತ್ತದೆ: WireGuard ಅದನ್ನು ಎಂಡ್ಪಾಯಿಂಟ್ ಎನ್ನುತ್ತದೆ, OpenVPN ಸ್ಥಿತಿ ಫೈಲ್ ಅದನ್ನು Real Address ಎಂದು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು strongSwan ಅದನ್ನು IKE_SA ಯ ದೂರದ ಹೋಸ್ಟ್ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಆ ಮೌಲ್ಯವು ಬೇರೆ ಮೂಲದಿಂದ ಪ್ಯಾಕೆಟ್ ಬಂದಾಗಲೆಲ್ಲಾ ನವೀಕರಣಗೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾರೂ ಏನನ್ನೂ ಮರುಪ್ರಾರಂಭಿಸದೆ ಅದು ಬದಲಾಗುತ್ತದೆ.

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

ಟನೆಲ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಲಾಗ್ ಮಾಡಿದ ಟ್ಯೂಪಲ್ ಏಕೆ ಬದಲಾಗುತ್ತದೆ

ವಿಳಾಸ ಅನುವಾದವು ಟೈಮರ್ನೊಂದಿಗೆ ಕೋಷ್ಟಕ, ಶಾಶ್ವತ ಬಂಧವಲ್ಲ. ಮನೆಯ ರೌಟರ್ ಕೊನೆಯ ಪ್ಯಾಕೆಟ್ನ ನಂತರ ಸ್ವಲ್ಪ ಸಮಯ ತನ್ನ UDP ಮ್ಯಾಪಿಂಗ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆಪರೇಟರ್ ಗೇಟ್ವೇ ತನ್ನದೇ ವೇಳಾಪಟ್ಟಿಯಂತೆ ಪೋರ್ಟ್ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು Wi-Fi ನಿಂದ LTE ಗೆ ಹೋಗುವ ಫೋನ್ ಸಂಪೂರ್ಣ ಬೇರೆ ಮೂಲದೊಂದಿಗೆ ಮರಳುತ್ತದೆ. ಇಲ್ಲಿ Linux conntrack ನ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು ಉಪಯುಕ್ತ ಮಾನದಂಡ: nf_conntrack_udp_timeout 30 ಸೆಕೆಂಡುಗಳು ಮತ್ತು ಸ್ಟ್ರೀಮಿಂಗ್ ರೂಪಾಂತರ 120, ಆದ್ದರಿಂದ ಶಾಂತ ಟನೆಲ್ ಬಳಕೆದಾರರು ಗಮನಿಸುವ ಮೊದಲೇ ತನ್ನ ಮ್ಯಾಪಿಂಗ್ ಕಳೆದುಕೊಳ್ಳಬಹುದು.

ಟನೆಲ್ ಉಳಿಯುವುದು ಪ್ರೋಟೋಕಾಲ್ ವಿಳಾಸವಲ್ಲ, ಪೀರ್ ಅನ್ನು ದೃಢೀಕರಿಸುವುದರಿಂದ. ಹ್ಯಾಂಡ್ಶೇಕ್ ನಂತರ WireGuard ಸ್ಥಿತಿರಹಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ದೃಢೀಕೃತ ಪ್ಯಾಕೆಟ್ ಸಂಗ್ರಹಿಸಿದ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಮರುಬಂಧ ಮುಂದಿನ ಪ್ಯಾಕೆಟ್ನಲ್ಲಿ ಸರಿಹೋಗುತ್ತದೆ; persistent-keepalive = 25 ಇರುವುದೇ ಇದಕ್ಕಾಗಿ, ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ ಮ್ಯಾಪಿಂಗ್ ಬೆಚ್ಚಗಿಡಲು. OpenVPN ನ --float ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ದೃಢೀಕೃತ ಕ್ಲೈಂಟ್ ಹೊಸ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ನಿಂದ ಮುಂದುವರಿಯಲು ಅನುಮತಿಸುತ್ತದೆ. float ಡೀಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಇರುವ 2.4 ಮತ್ತು 2.5 ಬಿಲ್ಡ್ಗಳಲ್ಲಿ, ಮರುಬಂಧ ಸೆಷನ್ ಅನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ.

IPsec ಅಲ್ಲಿಗೆ ಹೆಚ್ಚು ಚಲಿಸುವ ಭಾಗಗಳೊಂದಿಗೆ ತಲುಪುತ್ತದೆ. IKEv2 NAT ಪತ್ತೆ ಪೇಲೋಡ್ಗಳಲ್ಲಿ ಮೂಲ ಮತ್ತು ಗಮ್ಯದ ಹ್ಯಾಶ್ಗಳನ್ನು ಹೋಲಿಸಿ ಅನುವಾದವನ್ನು ಗುರುತಿಸುತ್ತದೆ, UDP 4500 ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ಗೆ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು keepalive ಗಳನ್ನು ಹೊಸ ಟ್ಯೂಪಲ್ವರೆಗೆ ಅನುಸರಿಸುತ್ತದೆ. keepalive ಗಳನ್ನು ನಿರ್ಬಂಧಿಸಿದಾಗ SA ಕಾಗದದ ಮೇಲೆ ಚಾಲನೆಯಲ್ಲಿದ್ದು ಒಂದು ದಿಕ್ಕಿನ ಸಂಚಾರ ಮೌನವಾಗಿ ನಿಲ್ಲುತ್ತದೆ.

ಸರ್ವರ್ ಏನನ್ನು ಆರೋಪಿಸಬಹುದು, ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ

ಕೊಲ್ಲಲು ಯೋಗ್ಯವಾದ ಪುರಾಣ ಎಂದರೆ ಅನುವಾದ ನಿಮ್ಮನ್ನು ಆಪರೇಟರ್ನಿಂದ ಮರೆಮಾಡುತ್ತದೆ ಎಂಬುದು. ಅದು ಲೇಬಲ್ ಬದಲಿಸುತ್ತದೆ, ವೀಕ್ಷಣೆಯನ್ನಲ್ಲ. ಆಪರೇಟರ್ NAT ಹಿಂದಿನ ಗೇಟ್ವೇ 100.64.0.0/10 ಜಾಗ ಅಥವಾ ಅನೇಕ ಚಂದಾದಾರರು ಹಂಚಿಕೊಳ್ಳುವ ಒಂದು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಹರಿವನ್ನು ಪ್ರಮಾಣಪತ್ರದ ವಿಷಯ, WireGuard ಸಾರ್ವಜನಿಕ ಕೀ, ನಿಗದಿಯಾದ ಟನೆಲ್ ವಿಳಾಸ, ಬೈಟ್ ಕೌಂಟರ್ಗಳು ಮತ್ತು ಸಮಯ ವಿಂಡೋಗೆ ಜೋಡಿಸಬಹುದು. ಇವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ನಿಮ್ಮ LAN ವಿಳಾಸ ಬೇಕಿಲ್ಲ.

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

ಊಹಿಸುವ ಬದಲು ಎರಡೂ ತುದಿಗಳನ್ನು ಹೋಲಿಸಿ

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

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

ನಂತರ ರೌಟರ್ ಅಥವಾ CGNAT ಗೇಟ್ವೇಯಲ್ಲಿ ಅನುವಾದ ನಮೂದನ್ನು ಮತ್ತು ಅಂತಿಮವಾಗಿ ಸರ್ವರ್ ತಲುಪುವುದನ್ನು ಓದಿ:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

ಮೂರು ಮಾದರಿಗಳು ಹೆಚ್ಚಿನ ಹೊಂದಾಣಿಕೆಯಲ್ಲದಿರುವಿಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಸರ್ವರ್ನಲ್ಲಿ ಮೂಲ ಪೋರ್ಟ್ ಸ್ಥಳೀಯ ಪೋರ್ಟ್ಗಿಂತ ಭಿನ್ನವಾಗಿದ್ದು ಗಮ್ಯ ಹೊಂದಿಕೆಯಾದರೆ: ಸಾಮಾನ್ಯ ಪೋರ್ಟ್ ಅನುವಾದ. ಸರ್ವರ್ನಲ್ಲಿ ಮೂಲ ವಿಳಾಸ ನಿಮ್ಮದಲ್ಲದ ISP ಬ್ಲಾಕ್ಗೆ ಸೇರಿದ್ದರೆ: ಕನಿಷ್ಠ ಒಂದು ಹೆಚ್ಚುವರಿ NAT ಪದರ. ನಿಷ್ಕ್ರಿಯತೆಯ ನಂತರ ಪ್ಯಾಕೆಟ್ಗಳು ನಿಲ್ಲುತ್ತವೆ ಮತ್ತು ಹೊಸ ಪೋರ್ಟ್ನೊಂದಿಗೆ ಮುಂದುವರಿಯುತ್ತವೆ: ಮ್ಯಾಪಿಂಗ್ ಅವಧಿ ಮುಗಿದಿದೆ, ರೌಟಿಂಗ್ ದೋಷವಲ್ಲ. ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ಗಳು ಒಂದು ಅಥವಾ ಎರಡು ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ದೂರವಿದ್ದರೆ, ನೀವು ಎರಡು ವಿಭಿನ್ನ ಪ್ರಯತ್ನಗಳನ್ನು ಹೋಲಿಸುತ್ತಿದ್ದೀರಿ.

ವ್ಯತ್ಯಾಸ ಎಲ್ಲಿ ವಿಷಯಗಳನ್ನು ಮುರಿಯುತ್ತದೆ

ಸರ್ವರ್ ದೋಷದಂತೆ ಕಾಣುವ ಅಡಚಣೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ನಿಮ್ಮ ಮನೆಯ ವಿಳಾಸಕ್ಕೆ ಪಿನ್ ಮಾಡಿದ ಪ್ರವೇಶ ನಿಯಮ ISP ಗುತ್ತಿಗೆ ಬದಲಾದ ನಂತರ ವಿಫಲವಾಗುತ್ತದೆ. ಅನುವಾದಿತ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುವ fail2ban ನಿಯಮ ಆ ಗೇಟ್ವೇ ಹಿಂದಿನ ಎಲ್ಲಾ ಚಂದಾದಾರರನ್ನು ಒಟ್ಟಿಗೆ ನಿಷೇಧಿಸುತ್ತದೆ. ಸ್ಥಿರ ದೂರದ ವಿಳಾಸವಿರುವ ಸೈಟ್-ಟು-ಸೈಟ್ ಪೀರ್ ಮೊಬೈಲ್ ಲಿಂಕ್ ಬದಲಾದ ನಂತರ ಕೀ ನವೀಕರಣ ನಿಲ್ಲಿಸುತ್ತದೆ. ಟನೆಲ್ ಪ್ರೋಟೋಕಾಲ್ ಸರಿಯಾಗಿತ್ತು; ಹೊರಗಿನ ಟ್ಯೂಪಲ್ ಬಗ್ಗೆ ಊಹೆ ಆಗಿರಲಿಲ್ಲ.

ಅದೇ ಗೊಂದಲ ಸರ್ವರ್ ಕಡೆಯಲ್ಲೂ ಕಾಣುತ್ತದೆ. VPN ಬಾಕ್ಸ್ ಸ್ವತಃ NAT ಹಿಂದೆ ಇದ್ದರೆ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗ ಬೇಕು; strongSwan ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ IPsec ಗಾಗಿ ಆ ಪ್ರಕರಣವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಕೇವಲ ಖಾಸಗಿ ವಿಳಾಸದಲ್ಲಿ ತಲುಪಬಹುದಾದ ಸರ್ವರ್ ತನ್ನ ಕ್ಲೈಂಟ್ಗಳು ಪ್ರಸ್ತುತಪಡಿಸುವ ಅನುವಾದಿತ ಟ್ಯೂಪಲ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ, ಮತ್ತು ಇದು ಕ್ಲೈಂಟ್ಗಳು ಅನುವಾದಗೊಳ್ಳುವುದಕ್ಕಿಂತ ಬೇರೆ ಸಮಸ್ಯೆ.

ಈ ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ವಿಫಲತೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಿ:

  • ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ; ಮೂಲ ಪೋರ್ಟ್, ಗಮ್ಯ ಪೋರ್ಟ್ ಮತ್ತು ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ಗಳು ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ದೃಢೀಕರಿಸಿ.
  • ನೀವು ನಿರೀಕ್ಷಿಸಿದ ವಿಳಾಸವನ್ನಲ್ಲ, ಸರ್ವರ್ ಈಗ ಹೊಂದಿರುವ ವಿಳಾಸವನ್ನು ಪೀರ್ ಪಟ್ಟಿಯಲ್ಲಿ ಓದಿ.
  • ನಮೂದು ಮತ್ತು ಅದರ ಉಳಿದ ಆಯುಷ್ಯಕ್ಕಾಗಿ conntrack ಅಥವಾ NAT ಕೋಷ್ಟಕವನ್ನು ಪರಿಶೀಲಿಸಿ.
  • ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸವು LAN ವಿಳಾಸವನ್ನಲ್ಲ, ಸರ್ವರ್ ನಿಗದಿಪಡಿಸಿದ್ದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ದೃಢೀಕರಿಸಿ.

ಎರಡೂ ಸೆರೆಹಿಡಿಯುವಿಕೆಗಳು ಟ್ಯೂಪಲ್ನಲ್ಲಿ ಒಪ್ಪಿದರೂ ಟನೆಲ್ ವಿಫಲವಾದರೆ, ಅನುವಾದ ನಿಮ್ಮ ಸಮಸ್ಯೆಯಲ್ಲ; ಹ್ಯಾಂಡ್ಶೇಕ್ ಮತ್ತು ಟನೆಲ್ ಒಳಗಿನ ರೌಟಿಂಗ್ ಕೋಷ್ಟಕಕ್ಕೆ ಮುಂದುವರಿಯಿರಿ.

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