NAT ಅಥವಾ ಬ್ರಿಡ್ಜ್ VM ನೆಟ್ವರ್ಕ್: VPN ಸಂಚಾರವನ್ನು ಯಾವುದು ಸಾಗಿಸುತ್ತದೆ?

NAT ಅತಿಥಿಗಳು ಹೋಸ್ಟ್ನ ಸುರಂಗವನ್ನು ಎರವಲು ಪಡೆಯುವುದು ಕ್ಲೈಂಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಸುರಂಗ ಮಾಡಿದಾಗ ಮಾತ್ರ; ಬ್ರಿಡ್ಜ್ ಅತಿಥಿಗಳು ತಾವೇ ಮಾರ್ಗ ನಿರ್ಧರಿಸುತ್ತವೆ. ಅತಿಥಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಸರಿಹೊಂದುವ ಮೋಡ್ ಆಯ್ಕೆಮಾಡಿ.

ಬ್ರಿಡ್ಜ್ ಮತ್ತು NAT ಒಂದೇ ಅತಿಥಿಯನ್ನು ನಿಮ್ಮ VPN ಗೆ ಜೋಡಿಸುವ ಎರಡು ವಿಧಾನಗಳಲ್ಲ; ಅವು ಸುರಂಗ ಬರುವ ಮೊದಲೇ ಅತಿಥಿಯ ಪ್ಯಾಕೆಟ್ಗಳು ಯಾರವು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. NAT ಮೋಡ್ನಲ್ಲಿ ಹೈಪರ್ವೈಸರ್ ಅತಿಥಿಯ ಸಂಚಾರವನ್ನು ಪುನಃ ಬರೆದು ಹೋಸ್ಟ್ ಬದಿಯ ಕೋಡ್ನಿಂದ ಹೊರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅತಿಥಿ ಹೋಸ್ಟ್ ಆ ಕೋಡ್ಗೆ ನೀಡುವ ಮಾರ್ಗದಲ್ಲಿ ಸಾಗುತ್ತದೆ. ಬ್ರಿಡ್ಜ್ ಮೋಡ್ನಲ್ಲಿ ಅತಿಥಿ ಭೌತಿಕ ವಿಭಾಗದಲ್ಲಿ ತನ್ನದೇ ಲಿಂಕ್ ಪದರದ ಗುರುತನ್ನು ಪಡೆದು ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಇದು ಹೋಸ್ಟ್ನ ಸುರಂಗವನ್ನು ಅದಕ್ಕೆ ಅಪ್ರಸ್ತುತವಾಗಿಸುತ್ತದೆ, LAN ರೌಟರ್ ಸುರಂಗ ಮಾಡುತ್ತಿದ್ದರೆ ಹೊರತುಪಡಿಸಿ. ನಾನು VM ಅನ್ನು VPN ನಲ್ಲಿದೆ ಎಂದು ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಆ ಅತಿಥಿಯ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಎಲ್ಲಿಗೆ ತೋರಿಸುತ್ತದೆ ಎಂಬ ಪ್ರಶ್ನೆಯಾಗಿ ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಕೆಳಗಿನ ಪರೀಕ್ಷೆ ಪ್ರತಿ ಮೋಡ್ಗೆ ಕೆಲವು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಊಹೆ ಇಲ್ಲದೆ ಅದನ್ನು ತೀರ್ಮಾನಿಸುತ್ತದೆ.

NAT ಅತಿಥಿಯನ್ನು ಹೈಪರ್ವೈಸರ್ ಕೋಡ್ನ ಹಿಂದೆ ಇಡುತ್ತದೆ, ಅಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾರ್ಗಗಳು ಅನ್ವಯವಾಗುತ್ತವೆ

VirtualBox ನಲ್ಲಿ NAT ಅತಿಥಿ 10.0.2.0/24 ನಲ್ಲಿ ಕುಳಿತು, 10.0.2.2 ನಲ್ಲಿ ವರ್ಚುವಲ್ ಗೇಟ್ವೇ, 10.0.2.3 ನಲ್ಲಿ DNS ಪ್ರಾಕ್ಸಿ ಇದೆ ಮತ್ತು ಭೌತಿಕ ನೆಟ್ವರ್ಕ್ಗೆ ತನ್ನದೇ ಮಾರ್ಗವಿಲ್ಲ. ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು NAT ಇಂಜಿನ್ ತೆಗೆದುಕೊಂಡು, ಮೂಲ ಹೋಸ್ಟ್ ಆಗುವಂತೆ ಪುನಃ ಬರೆದು ಹೋಸ್ಟ್ನ IP ಸ್ಟ್ಯಾಕ್ಗೆ ನೀಡುತ್ತದೆ. ಅಲ್ಲಿಂದ ಅತಿಥಿಯ ಸಂಚಾರ ಹೋಸ್ಟ್ ಹರಿವು, ಮತ್ತು ಮಾರ್ಗ ಹುಡುಕಾಟ ಗಮ್ಯಸ್ಥಾನದ ಪ್ರಕಾರ ನಡೆಯುತ್ತದೆ: 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಅನ್ನು ಹೋಸ್ಟ್ನಲ್ಲಿ ಸ್ಥಾಪಿಸುವ ಪೂರ್ಣ ಸುರಂಗ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಹಿಡಿಯುತ್ತದೆ, VM ಇದೆ ಎಂದು ಎಂದಿಗೂ ತಿಳಿಯದೆ. Oracle ನ VirtualBox ನೆಟ್ವರ್ಕಿಂಗ್ ಅಧ್ಯಾಯ ಈ ಡೀಫಾಲ್ಟ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ನಿಮ್ಮ ನಿರ್ಮಾಣದಲ್ಲಿ ವಿಳಾಸಗಳನ್ನು ಖಚಿತಪಡಿಸಲು ಬಯಸಿದರೆ.

libvirt ನ ಡೀಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ 192.168.122.0/24 ರಿಂದ ಅದೇ ಸ್ಥಳವನ್ನು ತಲುಪುತ್ತದೆ, ಅಲ್ಲಿ dnsmasq ಲೀಸ್ಗಳನ್ನು ಹಂಚಿ ಹೋಸ್ಟ್ ಉಪಜಾಲವನ್ನು ಮಾಸ್ಕರೇಡ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅತಿಥಿಯ ಪ್ಯಾಕೆಟ್ಗಳು ಮತ್ತೆ ಹೋಸ್ಟ್ನ ಮಾರ್ಗ ನಿರ್ಧಾರಕ್ಕೆ ಬರುತ್ತವೆ. ಅಪವಾದ ಎಂದರೆ ಮಾರ್ಗದ ಬದಲು ಪ್ರಕ್ರಿಯೆಯಿಂದ ಸಂಚಾರವನ್ನು ಆಯ್ಕೆಮಾಡುವ ಕ್ಲೈಂಟ್. ವಿಭಜಿತ ಸುರಂಗದ ಪಟ್ಟಿಯಲ್ಲಿ ನಿಮ್ಮ ಬ್ರೌಸರ್ ಮಾತ್ರ ಇದ್ದು ಬೇರೆ ಏನೂ ಇಲ್ಲದಿದ್ದರೆ, NAT ಇಂಜಿನ್ ಆ ಪಟ್ಟಿಯಲ್ಲಿಲ್ಲ, ಮತ್ತು ಅತಿಥಿ ಸುರಂಗವಿಲ್ಲದೆ ಯಂತ್ರವನ್ನು ಬಿಡುತ್ತದೆ, ಆದರೆ ಹೋಸ್ಟ್ನ ಬ್ರೌಸರ್ ಇನ್ನೂ ಆವರಿಸಿದಂತೆ ಕಾಣುತ್ತದೆ. ಅದೇ ಉಪಜಾಲ, ವಿರುದ್ಧ ಫಲಿತಾಂಶ.

ಬ್ರಿಡ್ಜ್ ಅತಿಥಿಗೆ ಭೌತಿಕ LAN ನಲ್ಲಿ ತನ್ನದೇ ಸ್ಥಾನ ನೀಡುತ್ತದೆ

ಬ್ರಿಡ್ಜ್ ಅತಿಥಿಗೆ ನಿಜವಾದ ಅಡಾಪ್ಟರ್ಗೆ ಜೋಡಿಸಿದ ವರ್ಚುವಲ್ NIC ನೀಡಲಾಗುತ್ತದೆ, ಅದು ತನ್ನದೇ MAC ವಿಳಾಸ ಪಡೆದು ಭೌತಿಕ ನೆಟ್ವರ್ಕ್ನಿಂದ DHCP ಲೀಸ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದರ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ LAN ರೌಟರ್, ಹೈಪರ್ವೈಸರ್ ಅಲ್ಲ, ಮತ್ತು ಅದರ ಫ್ರೇಮ್ಗಳು ಆ ಅಡಾಪ್ಟರ್ ಮೂಲಕ ತಂತಿಗೆ ಹೋಗುತ್ತವೆ. ಹೋಸ್ಟ್ನ ಸುರಂಗ ಮಾರ್ಗಗಳು ಹೋಸ್ಟ್ನ ಕೋಷ್ಟಕದಲ್ಲಿರುತ್ತವೆ ಮತ್ತು ಎಂದಿಗೂ ಕೇಳಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅತಿಥಿಯ ಫ್ರೇಮ್ಗಳು ಎಂದಿಗೂ ಹೋಸ್ಟ್ನ IP ಸ್ಟ್ಯಾಕ್ಗೆ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ.

ಇದು ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಕತ್ತರಿಸುತ್ತದೆ. mDNS ಮತ್ತು SMB ಬ್ರೌಸಿಂಗ್ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಅತಿಥಿ LAN ನ ಪ್ರಸಾರ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಅತಿಥಿ ನಡುವೆ ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ ಇಲ್ಲದೆ ಅದೇ ವಿಭಾಗದ ಇತರ ಯಂತ್ರಗಳಿಂದ ತಲುಪಬಹುದಾಗುತ್ತದೆ. ಬ್ರಿಡ್ಜ್ ಇರುವ ಸುರಂಗದ ಮೂಲಕ ಅತಿಥಿಯನ್ನು ತಳ್ಳುವ ವಿಧಾನವೂ ಅಲ್ಲ: VM ಅನ್ನು ಹೋಸ್ಟ್ನ WireGuard ಅಥವಾ OpenVPN ಇಂಟರ್ಫೇಸ್ಗೆ ಜೋಡಿಸುವುದು VirtualBox ಅಥವಾ libvirt ನಿಮಗಾಗಿ ಮಾಡುವ ಕೆಲಸವಲ್ಲ. ಬ್ರಿಡ್ಜ್ ಅತಿಥಿ ಸುರಂಗದ ಮೂಲಕ ಹೋಗಬೇಕಿದ್ದರೆ, ಸುರಂಗ ಆ LAN ನ ಎಲ್ಲಾದರೂ ಕೊನೆಗೊಳ್ಳಬೇಕು.

ವಾದವನ್ನು ಮುಗಿಸುವ ಪರೀಕ್ಷೆ

ಎರಡೂ ಮೋಡ್ಗಳಲ್ಲಿ ಅದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ನಡೆಸಿ ಉತ್ತರಗಳನ್ನು ಬರೆಯಿರಿ:

  • ಹೋಸ್ಟ್ನಲ್ಲಿ curl -s https://ifconfig.me ಸಾರ್ವಜನಿಕ v4 ವಿಳಾಸ ನೀಡುತ್ತದೆ.
  • ಅತಿಥಿಯಲ್ಲಿ ಅದೇ ಆಜ್ಞೆ, ಜೊತೆಗೆ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇಗಾಗಿ Linux ನಲ್ಲಿ ip route ಅಥವಾ Windows ನಲ್ಲಿ Get-NetRoute -DestinationPrefix 0.0.0.0/0.
  • ರಿಜಾಲ್ವರ್ನ ಗುರುತು: ಅತಿಥಿಯಲ್ಲಿ resolvectl status ಅಥವಾ cat /etc/resolv.conf, ಅದು 10.0.2.3 ಗೆ ಅಥವಾ LAN ಸರ್ವರ್ಗೆ ತೋರಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡಲು.
  • ವಿಳಾಸ ಕುಟುಂಬ: ip -6 addr show scope global ಮತ್ತು ಒಂದು v6 ವಿನಂತಿ, ಏಕೆಂದರೆ v4 ಸುರಂಗವು ಅತಿಥಿಯಲ್ಲಿ ಇರಬಹುದಾದ ಜಾಗತಿಕ v6 ವಿಳಾಸದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

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

ಎರಡು ಸಂಕೇತಗಳು ಸುಳ್ಳು ಹೇಳುತ್ತವೆ. ಯಶಸ್ವಿ ping ತಲುಪುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ನಿರ್ಗಮನ ಮಾರ್ಗವನ್ನಲ್ಲ. ಮತ್ತು DNS ಗೆ 10.0.2.3 ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್ನ ರಿಜಾಲ್ವರ್ ಮೂಲಕ ಉತ್ತರಿಸಬಹುದು, ಆಗ TCP ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಹೀಗೆ ಲೋಡ್ ಆಗುವ ಪುಟ ಮತ್ತು ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳದ ಲಾಗಿನ್ ಸಿಗುತ್ತದೆ.

ಕೆಲಸಕ್ಕೆ ಯಾವ ಮೋಡ್ ಸರಿಹೊಂದುತ್ತದೆ

ಮೋಡ್ ಒಂದು ಮಾರ್ಗ ನಿರ್ಧಾರ, ಆದ್ದರಿಂದ ಅದನ್ನು ಅಭ್ಯಾಸದ ಬದಲು ಅಗತ್ಯದಿಂದ ಆಯ್ಕೆಮಾಡಿ:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

ಮೊದಲ ಸಾಲು ಜನರು ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುವ ಸ್ಥಳ: NAT ಜೊತೆಗೆ ಹೋಸ್ಟ್ನಲ್ಲಿ ಪೂರ್ಣ ಸುರಂಗ ಕ್ಲೈಂಟ್ ಅತಿಥಿಯನ್ನು ಆವರಿಸುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಸುರಂಗ ಮಾಡುತ್ತಿರುವ ಮತ್ತು ಹೋಸ್ಟ್ನ ಮೇಲ್ಮುಖ ಸಂಪರ್ಕ ಆ ಸುರಂಗವಾಗಿರುವವರೆಗೆ ಮಾತ್ರ. ಕ್ಲೈಂಟ್ ಅನ್ನು ಬ್ರೌಸರ್ಗೆ ಮಾತ್ರ ಅನುಮತಿಸುವ ಪಟ್ಟಿಗೆ ಸರಿಸಿದರೆ, ಎಲ್ಲಿಯೂ ಯಾವುದೇ ದೋಷವಿಲ್ಲದೆ ಆವರಣ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ನಾಲ್ಕನೇ ಸಾಲು ವಿರುದ್ಧ ತಪ್ಪು: ಸೌಲಭ್ಯಕ್ಕಾಗಿ ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ ಅತಿಥಿ ಕಚೇರಿಯ LAN ನಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ SMB ಅಥವಾ SSH ಗೆ ಉತ್ತರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

VPN ಮೇಲೆ ಹೊರಿಸಲಾಗುವ ವೈಫಲ್ಯಗಳು

Windows ನಲ್ಲಿ NAT ಅನುವಾದ VirtualBox VM ಪ್ರಕ್ರಿಯೆಯ ಒಳಗೆ ಚಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಕ್ಲೈಂಟ್ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಗೆ ಸಾಮಾನ್ಯ ನಿಯಮದ ಬದಲು ತನ್ನ ಪಟ್ಟಿಯಲ್ಲಿ ಅದೇ ಚಿತ್ರವನ್ನು ಹೊಂದಿರಬೇಕು. ಕ್ಲೈಂಟ್ ನವೀಕರಣ ತನ್ನ ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸಿದಾಗ, NAT ಅತಿಥಿಗಳು ಮೊದಲು ಆವರಣ ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ವರದಿಯು ಹೋಸ್ಟ್ ಸರಿಯಾಗಿದ್ದಾಗ LAN ತಲುಪುವ ಆದರೆ ಇಂಟರ್ನೆಟ್ ತಲುಪದ VM ನಂತೆ ಓದುತ್ತದೆ.

Wi-Fi ಗೆ ಬ್ರಿಡ್ಜ್ ಮಾಡುವುದು ಇನ್ನೊಂದು ಕ್ಲಾಸಿಕ್. ಪ್ರವೇಶ ಬಿಂದುಗಳು ಹೊರಗಿನ ಮೂಲ MAC ಇರುವ ಫ್ರೇಮ್ಗಳನ್ನು ಅಪರೂಪವಾಗಿ ರವಾನಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ wlan0 ಗೆ ಬ್ರಿಡ್ಜ್ ಸಂಪೂರ್ಣವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ AP ಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪ್ರತ್ಯೇಕತೆ ಅದನ್ನು ಬೀಳಿಸಲು ಪ್ರಾರಂಭಿಸುವವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. VirtualBox ತನ್ನ ಪಟ್ಟಿಯಲ್ಲಿ ನಿಸ್ತಂತು ಅಡಾಪ್ಟರ್ ಅನ್ನು ಇನ್ನೂ ನೀಡುತ್ತದೆ. ಹೋಸ್ಟ್ Wi-Fi ನಲ್ಲಿದ್ದು ಅತಿಥಿ ಬ್ರಿಡ್ಜ್ ಆಗಬೇಕಿದ್ದರೆ, ಊಹಿಸುವ ಬದಲು ಪರೀಕ್ಷಿಸಲು ಯೋಜಿಸಿ.

MTU ಮೂರನೆಯದು. ಬ್ರಿಡ್ಜ್ ಅತಿಥಿ LAN ನ 1500 ಬೈಟ್ MTU ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದು ತನ್ನದೇ WireGuard ಕ್ಲೈಂಟ್ ಅನ್ನು 1420 ನಲ್ಲಿ ಚಲಾಯಿಸಿದರೆ, ದೊಡ್ಡ TLS ಹ್ಯಾಂಡ್ಶೇಕ್ಗಳು ನಿಂತುಕೊಳ್ಳುತ್ತವೆ, ಸಣ್ಣ ವಿನಂತಿಗಳು ಯಶಸ್ವಿಯಾಗುತ್ತವೆ. NAT ಅಡಿಯಲ್ಲಿ ಹೋಸ್ಟ್ ಸುರಂಗದ MTU ಹೋಸ್ಟ್ನ ಸಮಸ್ಯೆ, ಆದರೆ ಅತಿಥಿ ಇನ್ನೂ 1500 ಅನ್ನು ನಂಬುತ್ತದೆ, ಮತ್ತು don't-fragment ಬಿಟ್ ಸೆಟ್ ಆಗಿರುವ UDP ಅದೇ ರೀತಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ.

ಮೋಡ್ ಬರೆಯಿರಿ, ನಂತರ ಪ್ರತಿ ಅಡಾಪ್ಟರ್ ಬದಲಾವಣೆಯ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

ಮೋಡ್, ಬ್ರಿಡ್ಜ್ ಬಳಸುವ ಹೋಸ್ಟ್ ಇಂಟರ್ಫೇಸ್, ಅತಿಥಿಯ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ, ಅದರ ರಿಜಾಲ್ವರ್ ಮತ್ತು ಅದರ v4 ಹಾಗೂ v6 ನಿರ್ಗಮನ ವಿಳಾಸಗಳನ್ನು ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆಯೇ ಮುಂದಿನ ವೈಫಲ್ಯವನ್ನು ಅಗ್ಗವಾಗಿಸುತ್ತದೆ: ಲ್ಯಾಪ್ಟಾಪ್ ಡಾಕ್ನಿಂದ Wi-Fi ಗೆ ಹೋದಾಗ, ಬ್ರಿಡ್ಜ್ ಅತಿಥಿ ಬ್ರಿಡ್ಜ್ ಜೊತೆಗೆ ಬೇರೆ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ಗೆ ಹೋಗಿ ಬೇರೆ ಉಪಜಾಲದಲ್ಲಿ ಮತ್ತೆ ಲೀಸ್ ಪಡೆಯಬಹುದು, ಆದರೆ NAT ಅತಿಥಿ ತನ್ನ 10.0.2.x ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಂಡು ಸದ್ದಿಲ್ಲದೆ ಬೇರೆ ಮೇಲ್ಮುಖ ಸಂಪರ್ಕವನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ.

ಟಿಕೆಟ್ ಮುಚ್ಚುವ ಮೊದಲು, ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನು ಖಚಿತಪಡಿಸಿ:

  • ಅತಿಥಿಯ ನಿರ್ಗಮನ ವಿಳಾಸ ಹೋಸ್ಟ್ನ ನಿರ್ಗಮನ ವಿಳಾಸಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿದೆ, ಆದ್ದರಿಂದ ಅದು ಹೋಸ್ಟ್ನ ಸುರಂಗದಲ್ಲಿಲ್ಲ.
  • ರಿಜಾಲ್ವರ್ 10.0.2.3 ಪ್ರಾಕ್ಸಿ ಅಥವಾ LAN ಸರ್ವರ್, ಮತ್ತು ಯಾವುದು ಉತ್ತರಿಸಿತು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ.
  • ಸುರಂಗದ ವಿನ್ಯಾಸ ಕೇವಲ v4 ಆಗಿದ್ದರೆ ಅತಿಥಿಯಲ್ಲಿ ಯಾವುದೇ ಜಾಗತಿಕ v6 ವಿಳಾಸವಿಲ್ಲ.
  • ಹೋಸ್ಟ್ನ ಸುರಂಗ ಇಳಿದಾಗ ಅತಿಥಿ ಬ್ರೌಸ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಅಥವಾ ಅದು ಎಂದಿಗೂ ಅದನ್ನು ಅವಲಂಬಿಸಿರಲಿಲ್ಲ ಎಂದು ಈಗ ನಿಮಗೆ ತಿಳಿದಿದೆ.
  • ಅತಿಥಿಗೆ ಸಂಬಂಧವಿಲ್ಲದ LAN ಪ್ರಸಾರ ಸಂಚಾರ ಕಾಣುವುದಿಲ್ಲ.

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