ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ ವಿರುದ್ಧ VPN ಪ್ರವೇಶ: ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ

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

DNAT ನಿಯಮ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಮರುಬರೆಯುತ್ತದೆ ಮತ್ತು ಅಲ್ಲೇ ನಿಲ್ಲುತ್ತದೆ

Linux ಗೇಟ್ವೇಯಲ್ಲಿ ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸುವುದು ಎಂದರೆ nat ಕೋಷ್ಟಕದ PREROUTING ಸರಣಿಯಲ್ಲಿ ನಿಯಮ, ಅಥವಾ nftablesನಲ್ಲಿ ಅದಕ್ಕೆ ಸಮಾನವಾದದ್ದು. ನಿಯಮ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ಹೊಂದಿಕೆಯಾಗಿ, ನಂತರ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಅಪ್ಲಿಕೇಶನ್ನ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯುತ್ತದೆ. ಮೂಲ ವಿಳಾಸ, ಮೂಲ ಪೋರ್ಟ್ ಮತ್ತು ಪೇಲೋಡ್ ಸ್ಪರ್ಶಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಮತ್ತು conntrack ನಕ್ಷೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಇದರಿಂದ ಉತ್ತರಗಳು ಹೊರಗೆ ಹೋಗುವಾಗ ಮರುಬರೆಯಲ್ಪಡುತ್ತವೆ. ಈ ವರ್ತನೆ RFC 3022 ನಲ್ಲಿ ವಿವರಿಸಲಾದ ಸಾಂಪ್ರದಾಯಿಕ ವಿಳಾಸ ಭಾಷಾಂತರ ಮಾದರಿ.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

ಅಪ್ಲಿಕೇಶನ್ನ ಕೇಳುಗ ಸಂಪರ್ಕವು ಭಾಷಾಂತರದ ಮೂಲಕ ಬಂದಿದೆ ಎಂದು ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ. ಅದು ಕ್ಲೈಂಟ್ನ ನಿಜವಾದ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಇದು ಪ್ರವೇಶ ಲಾಗ್ಗಳು ಮತ್ತು ದರ ಮಿತಿಗಳಿಗೆ ಉಪಯುಕ್ತ, ಮತ್ತು ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಏಕೆಂದರೆ conntrack ನಕ್ಷೆಯನ್ನು ತಿರುಗಿಸುತ್ತದೆ. ಆ ಮಾರ್ಗದಲ್ಲಿ ಯಾವುದೂ ಡೀಕ್ರಿಪ್ಟ್ ಅಥವಾ ಮತ್ತೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗುವುದಿಲ್ಲ: TLS ಇನ್ನೂ ಕ್ಲೈಂಟ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಪ್ರಮಾಣಪತ್ರದ ನಡುವೆ ಚಲಿಸುತ್ತದೆ.

ನಿಯಮವು ನಂತರ ಎದುರಿಸುವ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ. ಗೇಟ್ವೇ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದರೂ ಅಪ್ಲಿಕೇಶನ್ನ ಹೋಸ್ಟ್ಗೆ ಕ್ಲೈಂಟ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ, ಉತ್ತರಗಳು ತಪ್ಪು ಮೂಲದೊಂದಿಗೆ ಹೊರಡುತ್ತವೆ ಮತ್ತು ಹ್ಯಾಂಡ್ಶೇಕ್ ನಿಲ್ಲುತ್ತದೆ. ಎರಡನೇ ನಿಯಮ ಮೊದಲು ಹೊಂದಿಕೆಯಾದರೆ, ಕ್ರಮವೇ ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು iptables -t nat -L -n -v ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಯಾವ ನಿಯಮ ತೆಗೆದುಕೊಂಡಿತು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಕೌಂಟರ್ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಸುರಂಗ ಕೇಳುಗನಿಗಿಂತ ಮೊದಲು ಪ್ಯಾಕೆಟ್ ಸುತ್ತುತ್ತದೆ

VPN ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಕಟಿಸುವುದೇ ಇಲ್ಲ. ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇಯ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಉದ್ದೇಶಿಸಿದ ಹೊರ ಪ್ಯಾಕೆಟ್ ನಿರ್ಮಿಸಿ, ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅದರೊಳಗೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಗೇಟ್ವೇ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿ ಒಳ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ರೂಟ್ ಮಾಡುತ್ತದೆ. WireGuardನಲ್ಲಿ ಹೊರ ಸಾಗಣೆ UDP, ಸಾಮಾನ್ಯವಾಗಿ ಎತ್ತರದ ಪೋರ್ಟ್ನಲ್ಲಿ; OpenVPN TCP 443 ಮೇಲೆ ಇದ್ದಾಗ ಹೊರ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ಗಮನಿಸುವ ಯಾವುದಕ್ಕೂ TLSನಂತೆ ಕಾಣುತ್ತದೆ.

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

ಸುತ್ತುವಿಕೆ ಶೀರ್ಷಿಕೆ ಜಾಗವನ್ನು ವ್ಯಯಿಸುತ್ತದೆ, ಮತ್ತು ಇದೇ ಅಳೆಯಬಹುದಾದ ಪರಿಣಾಮವಿರುವ ಏಕೈಕ ಯಾಂತ್ರಿಕ ಮಟ್ಟದ ವ್ಯತ್ಯಾಸ. ಹೊರ IP ಶೀರ್ಷಿಕೆ ಜೊತೆಗೆ UDP ಜೊತೆಗೆ WireGuardನ ಸ್ವಂತ ಶೀರ್ಷಿಕೆ ಮಾರ್ಗದ MTU ಯಿಂದ ತಿನ್ನುತ್ತದೆ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಭಾಗಿಸಬೇಕು ಅಥವಾ ಒಳ TCP ಸ್ಟಾಕ್ ತನ್ನ MSS ಅನ್ನು ಮಿತಿಗೊಳಿಸಬೇಕು. ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಮಾರ್ಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ವರ್ಗಾವಣೆ ಸುರಂಗದಲ್ಲಿ ನಿಲ್ಲಬಹುದು, ಮಧ್ಯದ ಸಾಧನವು ಚಿಕ್ಕ MTU ಸೂಚಿಸುವ ICMP ಅನ್ನು ಬಿಟ್ಟಾಗ.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

ಒಡ್ಡುವಿಕೆ ಪ್ರವೇಶದ್ವಾರದಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತದೆ, ಸೈಫರ್ನಿಂದ ಅಲ್ಲ

ಎರಡೂ ವಿನ್ಯಾಸಗಳು ಒಂದೇ TLS ಕೇಳುಗನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಎರಡೂ ಒಂದೇ ಪ್ರಮಾಣಪತ್ರ, ಒಂದೇ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗಿನ್ ಅನ್ನು ಪಡೆಯುತ್ತವೆ. ಬದಲಾಗುವುದು ಯಾರಿಗೆ ಹ್ಯಾಂಡ್ಶೇಕ್ ಪ್ರಾರಂಭಿಸಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದು. ಸಾರ್ವಜನಿಕ ಫಾರ್ವರ್ಡ್ನಲ್ಲಿ, 203.0.113.10:443 ಅನ್ನು ತಲುಪುವ ಯಾವುದೇ ಹೋಸ್ಟ್ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅಧಿಕಾರವನ್ನು ಪರಿಗಣಿಸುವ ಮೊದಲೇ TCP ಹ್ಯಾಂಡ್ಶೇಕ್ ಮತ್ತು TLS ClientHello ಪಡೆಯುತ್ತದೆ. ಸುರಂಗದ ಮೂಲಕ ಮಾತ್ರ ಪ್ರವೇಶದಲ್ಲಿ, ಕೇಳುಗನನ್ನು ಗೇಟ್ವೇ ಸುರಂಗಕ್ಕೆ ರೂಟ್ ಮಾಡುವ ವಿಳಾಸಗಳಿಂದ ಮಾತ್ರ ತಲುಪಬಹುದು, ಮತ್ತು ಅಪರಿಚಿತನ SYN ಗೇಟ್ವೇ ನೀತಿಯಲ್ಲಿ ಸಾಯುತ್ತದೆ.

ಈ ವ್ಯತ್ಯಾಸ ತಲುಪುವ ಸಾಮರ್ಥ್ಯದ ಬಗ್ಗೆ, ಗೋಪ್ಯತೆಯ ಬಗ್ಗೆ ಅಲ್ಲ. ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ HTTPS ಸೇವೆ ಸರಳ ಪಠ್ಯವಲ್ಲ, ಮತ್ತು VPN ಅಪ್ಲಿಕೇಶನ್ ದೃಢೀಕರಣದ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ: ಸುರಂಗಕ್ಕೆ ಪ್ರವೇಶ ಸಾಧನವು ಈ ನೆಟ್ವರ್ಕ್ಗೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಬಹುದೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ಫೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರು ದಾಖಲೆಯನ್ನು ಓದಬಹುದೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಎರಡನ್ನೂ ಬೆರೆಸುವುದೇ ತಂಡಗಳು ಇಡೀ LAN ನೀಡುವ VPN ಮತ್ತು ಒಂದೇ ಹಂಚಿದ ಪಾಸ್ವರ್ಡ್ನ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಬರುವ ದಾರಿ.

ಕೇಳುಗ ಮತ್ತು ನೀತಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಎರಡರಲ್ಲಿ ಯಾವುದಾದರೂ ನೀವು ಊಹಿಸುವುದಕ್ಕಿಂತ ವಿಶಾಲವಾಗಿರಬಹುದು:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

ss ಕೇಳುಗನು 0.0.0.0 ಗೆ ಬದ್ಧವಾಗಿದೆ ಎಂದು ತೋರಿಸಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ರೂಟಿಂಗ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿ ಅನುಮತಿಸುವ ಎಲ್ಲಿಂದಲಾದರೂ ತಲುಪಬಹುದು, ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಒಳಗೆ ಬರುವ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ. ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧಗೊಳಿಸುವುದು, ಅಥವಾ ಫೈರ್ವಾಲ್ನಲ್ಲಿ ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು, VPN ಆಯ್ಕೆಯಿಂದ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ, ಮತ್ತು ಅದೇ ಒಡ್ಡುವಿಕೆಯನ್ನು ನಿಜವಾಗಿ ಕಿರಿದಾಗಿಸುತ್ತದೆ.

ಮಾರ್ಗವನ್ನು ಅಳೆಯಿರಿ, ಲೇಬಲ್ ಅನ್ನಲ್ಲ

ಯಾರಾದರೂ ಫಾರ್ವರ್ಡ್ ವೇಗವಾಗಿದೆ ಎಂದು ಹೇಳಿದಾಗ, ಪ್ರಾಮಾಣಿಕ ಹೋಲಿಕೆ ಉಳಿದೆಲ್ಲವನ್ನೂ ಸ್ಥಿರವಾಗಿಡುತ್ತದೆ: ಅದೇ ಕ್ಲೈಂಟ್, ಅದೇ ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್, ಅದೇ ಫೈಲ್, ಅದೇ TLS ಸಂರಚನೆ, ಅದೇ ಅಪ್ಲಿಕೇಶನ್ ಹೋಸ್ಟ್. ಪ್ರತಿ ಮಾರ್ಗಕ್ಕೆ ವರ್ಗಾವಣೆಯನ್ನು ಎರಡು ಬಾರಿ ನಡೆಸಿ ಒಟ್ಟು ಸಮಯ, ವೈಫಲ್ಯಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯಾಶೀಲತೆಯನ್ನು ದಾಖಲಿಸಿ, ಸಂಬಂಧವಿಲ್ಲದ ವೇಗ ಪರೀಕ್ಷೆಯ ಔಟ್ಪುಟ್ ಅನ್ನಲ್ಲ.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

ಈ ಸಂಖ್ಯೆಗಳು ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯನ್ನು ವರ್ಗಾವಣೆ ಸಮಯದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಇದು ಮುಖ್ಯ ಏಕೆಂದರೆ ಎರಡು ಮಾರ್ಗಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸೈಫರ್ ವೆಚ್ಚದಲ್ಲಿ ಅಲ್ಲ, ಹೋಗಿ-ಬರುವ ವಿಳಂಬ ಮತ್ತು MTU ನಲ್ಲಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. TLS ಕೆಲಸ ಎರಡೂ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ತುದಿಗಳಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್, ಬೇರೆ ರೂಟ್ ಮತ್ತು ಬಹುಶಃ ಹೆಚ್ಚು ನಿರತ ಗೇಟ್ವೇ ಸೇರಿಸುತ್ತದೆ. ಸುರಂಗದ ಮಾರ್ಗ ಉದ್ದವಾಗಿದ್ದರೆ ಅಥವಾ ಅದರ ಗೇಟ್ವೇ ಭಾರವಾಗಿದ್ದರೆ, ವ್ಯತ್ಯಾಸ ಮಾರ್ಗದ್ದು, ಎನ್ಕ್ರಿಪ್ಶನ್ ಪದದ್ದಲ್ಲ.

ಸೇವೆಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಆರಿಸಿ, ನಂತರ ಅಳತೆ ಮಾಡಿದ ವ್ಯತ್ಯಾಸ ಅದನ್ನು ಬದಲಾಯಿಸಲು ಸಮರ್ಥನೆ ನೀಡುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ಸಾರ್ವಜನಿಕ ಫಾರ್ವರ್ಡ್ ಮುಕ್ತ ಇಂಟರ್ನೆಟ್ಗಾಗಿ ಉದ್ದೇಶಿಸಿದ ಸೇವೆಗೆ ಸರಿಹೊಂದುತ್ತದೆ, ಮೂಲ ನಿರ್ಬಂಧಗಳು, ನವೀಕೃತ TLS ಮತ್ತು ಮುಂದೆ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ. ಸುರಂಗದ ಮೂಲಕ ಮಾತ್ರ ಪ್ರವೇಶ ಬಳಕೆದಾರರು ಈಗಾಗಲೇ ನೋಂದಾಯಿಸಿಕೊಂಡಿರುವ ಆಂತರಿಕ ಸಾಧನಕ್ಕೆ ಸರಿಹೊಂದುತ್ತದೆ, ಗೇಟ್ವೇ ರೂಟಿಂಗ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿಗಳು ಎರಡೂ ಇಡೀ LAN ಗಿಂತ ಕಿರಿದಾಗಿದ್ದರೆ.

ವಿನ್ಯಾಸವನ್ನು ಪೂರ್ಣ ಎಂದು ಘೋಷಿಸುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ದೃಢೀಕರಿಸಿ: ಕೇಳುಗ ಯಾವ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ, ಯಾವ ನಿಯಮ ಅಥವಾ ಮಾರ್ಗ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಒಳಗೆ ಬಿಡುತ್ತದೆ, ಕ್ಲೈಂಟ್ನ ನಿಜವಾದ ವಿಳಾಸದಿಂದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ, ಮತ್ತು ದೊಡ್ಡ ಪೇಲೋಡ್ಗಳು MTU ದಾಟುತ್ತವೆಯೇ. ಅವುಗಳ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಮೇಲೆ ಆಜ್ಞೆ ಇದೆ, ಮತ್ತು ಯಾವುದಕ್ಕೂ «ಸುರಕ್ಷಿತ» ಪದ ಅಥವಾ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಚಾರ್ಟ್ ಉತ್ತರಿಸುವುದಿಲ್ಲ.