Docker ಕಂಟೇನರ್ ಗಳ ಸಂಚಾರವನ್ನು ಮಾತ್ರ OpenVPN ಮೂಲಕ ರೂಟ್ ಮಾಡುವುದು ಹೇಗೆ

ಹೋಸ್ಟ್ ಅನ್ನು ಸಾಮಾನ್ಯ ಅಪ್ಲಿಂಕ್ ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಒಂದು ಕಂಟೇನರ್ ಉಪಜಾಲವನ್ನು ಟನೆಲ್ ಗೆ ಹಾಕಿ: NAT ಕ್ರಮ, ಮೂಲ ನಿಯಮಗಳು, OpenVPN iroute ಮತ್ತು MSS ಪರಿಶೀಲನೆಗಳು.

ಕಂಟೇನರ್ ನ ಪ್ಯಾಕೆಟ್ ಎಂದಿಗೂ tun0 ಗೆ ತಲುಪುವುದಿಲ್ಲ, ಮತ್ತು ಕಂಟೇನರ್ ಮೇಲಿನ ಹೆಚ್ಚುವರಿ ಸಾಮರ್ಥ್ಯಗಳು ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಅತಿಥಿ ಮತ್ತು ಟನೆಲ್ ನಡುವೆ ಎರಡು ರೂಟ್ ಹುಡುಕಾಟಗಳಿವೆ: ಒಂದು ಅತಿಥಿಯ ಜಾಲ ನಾಮಸ್ಥಳದ ಒಳಗೆ, ಒಂದು ಫ್ರೇಮ್ ಸೇತುವೆ ಮೇಲೆ ಬಿದ್ದ ನಂತರ ಹೋಸ್ಟ್ ನಲ್ಲಿ, ಮತ್ತು ಎರಡನೆಯದು ಬೇರೆ ಹೊಂದಾಣಿಕೆ ನಿಯಮಗಳಿರುವ ಬೇರೆ ಕೋಷ್ಟಕವನ್ನು ಕೇಳುತ್ತದೆ। ನನ್ನ ಉಲ್ಲೇಖ ವಿನ್ಯಾಸವು Linux ಹೋಸ್ಟ್ ಆಗಿದ್ದು, ಅದರಲ್ಲಿ OpenVPN ಕ್ಲೈಂಟ್ ಚಲಿಸುತ್ತದೆ, ಅದು 10.8.0.10 ಅನ್ನು tun0 ನಲ್ಲಿ ಇಟ್ಟುಕೊಂಡಿದೆ, 172.18.0.0/16 ನಲ್ಲಿ Docker ಸೇತುವೆ, ಮತ್ತು ಟನೆಲ್ ಬದಿ ಮಾತ್ರ ತಲುಪಬಲ್ಲ ಖಾಸಗಿ ವಿಳಾಸವಿದೆ। ಗುರಿ ಸಂಕುಚಿತವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ: ಆ ಅತಿಥಿ ಉಪಜಾಲವು ಟನೆಲ್ ಮೂಲಕ ಹೊರ ಹೋಗುತ್ತದೆ, ಹೋಸ್ಟ್ ತನ್ನ ಸಾಮಾನ್ಯ ಅಪ್ಲಿಂಕ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ।

VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಕಂಟೇನರ್ ಒಳಗೆ ಚಲಾಯಿಸುವುದು ಬೇರೆ ವಿನ್ಯಾಸ, ಸಣ್ಣ ದಾರಿಯಲ್ಲ। ಆಗ ಕಂಟೇನರ್ ತನ್ನ ಟನೆಲ್ ಮತ್ತು ರುಜುವಾತುಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಕೆಲಸ iptables ನಲ್ಲಿ ಉಳಿಯದೆ Dockerfile ಗೆ ಹೋಗುತ್ತದೆ।

ಫಾರ್ವರ್ಡಿಂಗ್ ಗಮ್ಯಸ್ಥಾನದಿಂದ ಮಾರ್ಗವನ್ನು ಆರಿಸುತ್ತದೆ, ನಂತರ NAT ಮೂಲವನ್ನು ಮರುಬರೆಯುತ್ತದೆ

ಸೆಟ್ ಆಗಿರುವಾಗ net.ipv4.ip_forward=1 , ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್ ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನದಿಂದ ಮಾತ್ರ ರೂಟ್ ಆಗುತ್ತದೆ। ಆ ನಿರ್ಧಾರದಲ್ಲಿ ಮೂಲಕ್ಕೆ ಯಾವ ಪಾತ್ರವೂ ಇಲ್ಲ। ಮಾರ್ಗ ಆಯ್ಕೆಯಾದ ನಂತರವೇ ಕರ್ನಲ್ POSTROUTING ಅನ್ನು ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲಿಯೇ Docker ನ ಸ್ವಂತ ನಿಯಮ ಇದೆ: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE। ಸೇತುವೆಯನ್ನು ಬಿಟ್ಟು ಬೇರೆ ಇಂಟರ್ಫೇಸ್ ಗೆ ಹೋಗುವ ಎಲ್ಲವೂ ಅನುವಾದವಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ಯಾವ ವಿಳಾಸವಾಗುತ್ತದೆ ಎಂಬುದು ಮಾರ್ಗವು ಅದನ್ನು ಕಳುಹಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ।

ಈ ನಿಯಮವು ನನ್ನನ್ನು ಕೇಳುವ ಹೆಚ್ಚಿನ ಲಕ್ಷಣಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ। ಮುಖ್ಯ ಕೋಷ್ಟಕದಲ್ಲಿ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಹೋಸ್ಟ್ ನ ಭೌತಿಕ ವಿಳಾಸದೊಂದಿಗೆ ಅಪ್ಲಿಂಕ್ ಮೂಲಕ ಹೊರ ಹೋಗುತ್ತದೆ। ನಿಮ್ಮ ಪೂರೈಕೆದಾರರು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಬಿಡುತ್ತಾರೆ, ಅಥವಾ ದೂರದ ಸೈಟ್ ಎಂದೂ ನಿರೀಕ್ಷಿಸದ RFC 1918 ಮೂಲವನ್ನು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಮೇಲೆ ಮತ್ತು ಆರೋಗ್ಯಕರವಾಗಿರುವಾಗಲೇ ಕಂಟೇನರ್ ಸಮಯ ಮುಗಿಯುತ್ತದೆ। tun0 ನಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ಸೂಚನೆ। ಮಾರ್ಗವು ನಿಜವಾಗಿ tun0 ಕಡೆಗೆ ತೋರಿಸಿದರೆ, MASQUERADE ಮೂಲವನ್ನು 10.8.0.10 ಗೆ ಮರುಬರೆಯುತ್ತದೆ ಮತ್ತು ಅದೇ ಕಂಟೇನರ್ ನೀವು ಏನನ್ನೂ ಮುಟ್ಟದೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ।

ಅತಿಥಿಯ ಮೂಲವನ್ನು ಹೆಸರಿಸುವ ಹುಡುಕಾಟವನ್ನು ಕೇಳಿ। from ಮತ್ತು iif ಇಲ್ಲದೆ ಹೋಸ್ಟ್ ತನ್ನದೇ ಸಾಕೆಟ್ ಗಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್ ಎಂದೂ ತೆಗೆದುಕೊಳ್ಳದ ದಾರಿಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

ಆ ಉತ್ತರ ಅಪ್ಲಿಂಕ್ ಅನ್ನು ಹೆಸರಿಸಿದರೆ, ಟನೆಲ್ ಚಿತ್ರದಲ್ಲಿ ಇಲ್ಲ ಮತ್ತು ಟನೆಲ್ ಬದಿಯ ಯಾವ ಸೆಟ್ಟಿಂಗ್ ಸಹ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ।

ಅತಿಥಿಯನ್ನು ಟನೆಲ್ ನ ಸ್ವಂತ ವಿಳಾಸಕ್ಕೆ ಸರಿಸಿ

ಕೆಲಸ ಮಾಡುವ ಅತಿ ಚಿಕ್ಕ ಬದಲಾವಣೆ ಎಂದರೆ ಹೊರಹೋಗುವಾಗ ಸ್ಪಷ್ಟ ಮೂಲ ಮರುಬರವಣಿಗೆ। ಅದನ್ನು ಸೇರಿಸಿ, ಕೊನೆಗೆ ಸೇರಿಸಬೇಡಿ: Docker ಈಗಾಗಲೇ POSTROUTING ನ ತಲೆಯಲ್ಲಿ ಕುಳಿತಿದೆ, ಆದ್ದರಿಂದ -A ನಿಂದ ಸೇರಿಸಿದ ನಿಯಮವು Docker ನ ನಿಯಮದ ನಂತರ ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತದೆ ಮತ್ತು ಎಂದೂ ಚಾಲನೆಯಾಗುವುದಿಲ್ಲ।

iptables -t nat -I POSTROUTING 1 -s 172.18.0.0/16 -o tun0 -j SNAT --to-source 10.8.0.10

ಇದು ಉಳಿಯುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಎರಡು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ। ವಿಳಾಸವು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಹೊಂದಿರುವುದೇ ಆಗಿರಬೇಕು, ಆದ್ದರಿಂದ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಗೆ ifconfig-push 10.8.0.10 255.255.255.0 ಹೊಂದಿರುವ ನಮೂದಿನಿಂದ ಅದನ್ನು ಪಿನ್ ಮಾಡಿ; ಎಂದೂ ಹಂಚದ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವ ನಿಯಮವು ಮೌನ ಬಿಡುವಿಕೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ದೋಷವನ್ನಲ್ಲ। ಮತ್ತು ದೂರದ ಬದಿಯು ಆ ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸಿ ಉತ್ತರಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು, ಆದ್ದರಿಂದ ಅಲ್ಲಿನ ಅನುಮತಿ ಪಟ್ಟಿ ಅತಿಥಿ ಉಪಜಾಲವನ್ನಲ್ಲ, ಟನೆಲ್ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ। ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಚಲನಶೀಲವಾದಾಗ, -j MASQUERADE ಜೊತೆಗೆ -o tun0 ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವುದನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಸ್ಥಿರ ಮೌಲ್ಯದ ವಿರುದ್ಧ ಬರೆಯಲಾಗದ ದೂರದ ನೀತಿಯ ವೆಚ್ಚದಲ್ಲಿ।

ಫಿಲ್ಟರಿಂಗ್ ಇನ್ನೊಂದು ಅರ್ಧ। Docker FORWARD ನೀತಿಯನ್ನು drop ಗೆ ಇಡುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಡೀಮನ್ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ತನ್ನ ಸರಪಳಿಗಳನ್ನು ಖಾಲಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಥಳೀಯ ನೀತಿಯನ್ನು DOCKER-USER ನಲ್ಲಿ ಇಡಿ, ಅದು ಉಳಿಯುತ್ತದೆ:

iptables -I DOCKER-USER -i br-appnet -o tun0 -j ACCEPT
iptables -I DOCKER-USER -i tun0 -o br-appnet -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ಹಿಂತಿರುಗುವ ನಿಯಮ ಮುಖ್ಯ: tun0 ಗೆ ಬರುವ ಉತ್ತರವು ಸೇತುವೆಯಿಂದ ತೆರೆದ ಸಂಪರ್ಕಕ್ಕೆ ಹೊರಹೋಗುವ ದಿಕ್ಕು ಸ್ವೀಕೃತವಾದ ಕಾರಣಕ್ಕೆ ಮಾತ್ರ ಸ್ವೀಕೃತವಾಗುವುದಿಲ್ಲ।

ಮೂಲ ನಿಯಮದಿಂದ ಹೋಸ್ಟ್ ಅನ್ನು ನೇರವಾಗಿ ಇರಿಸಿ

ಇಡೀ ಸೇತುವೆ ಟನೆಲ್ ಬಳಸಬೇಕು ಆದರೆ ಹೋಸ್ಟ್ ನಲ್ಲಿ ಬೇರೆ ಏನೂ ಬಳಸಬಾರದಾದಾಗ, NAT ಬಿಟ್ಟು ಆ ಮೂಲಕ್ಕೆ ಅದರ ಸ್ವಂತ ಕೋಷ್ಟಕ ಕೊಡಿ। ಅತಿಥಿ ವಿಳಾಸಗಳು ಆಗ ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಗೋಚರವಾಗಿ ಉಳಿಯುತ್ತವೆ।

echo "200 vpnbox" >> /etc/iproute2/rt_tables
ip rule add from 172.18.0.0/16 lookup vpnbox pref 1000
ip route add default dev tun0 table vpnbox

ನಿಯಮಗಳನ್ನು ಮುಖ್ಯ ಕೋಷ್ಟಕಕ್ಕಿಂತ ಮೊದಲು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು from ಮೂಲಕ್ಕೆ ಹೊಂದುತ್ತದೆ। ಟನೆಲ್ ನ ಸ್ವಂತ ಹೊರ ಪ್ಯಾಕೆಟ್ ಗಳು ಹೋಸ್ಟ್ ನ ಭೌತಿಕ ಮೂಲವನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವು ಎಂದೂ from 172.18.0.0/16 ಗೆ ಹೊಂದುವುದಿಲ್ಲ ಮತ್ತು ಟನೆಲ್ ತನ್ನನ್ನೇ ಒಳಗೆ ಹಿಂತಿರುಗಿಸಲಾರದು। ಈ ಸ್ವಯಂ-ಹೊರಗಿಡುವಿಕೆಯೇ ವಿನ್ಯಾಸವನ್ನು ಸ್ಥಿರಗೊಳಿಸುತ್ತದೆ।

ಹಿಂತಿರುಗುವ ದಾರಿಗೆ ಈಗ ಸಹಾಯ ಬೇಕು। ದೂರದ ಬದಿ ಅನುವಾದವಾಗದ 172.18.0.x ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅದು ಎಲ್ಲಿದೆ ಎಂದು ತಿಳಿಯಲು ಕಾರಣವಿಲ್ಲ। ಸರ್ವರ್ ನಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಗೆ ಫೈಲ್ iroute 172.18.0.0 255.255.0.0 ಬೇಕು, ಸರ್ವರ್ ನ ಒಳ ಕೋಷ್ಟಕ ಆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಈ ಕ್ಲೈಂಟ್ ಗೆ ಕೊಡಲು, ಮತ್ತು ತಳ್ಳಿದ route 172.18.0.0 255.255.0.0 ಬೇಕು, ಬೇರೆ ಕ್ಲೈಂಟ್ ಗಳು ಅದು ಇದೆ ಎಂದು ತಿಳಿಯಲು।

ನಂಬುವ ಮೊದಲು ಎರಡು ಪರಿಶೀಲನೆ। ಚಲಾಯಿಸಿ ip route show default : redirect-gateway def1 ಜೊತೆ ಕೋಷ್ಟಕದಲ್ಲಿ 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಇವೆ tun0 ಮೂಲಕ, ಮತ್ತು ಹೋಸ್ಟ್ ಸ್ವಲ್ಪವೂ ನೇರವಲ್ಲ, ಏಕೆಂದರೆ ಆ ಅರ್ಧ-ಪೂರ್ವನಿಗದಿ ಮಾರ್ಗಗಳು default ಅನ್ನು ಬದಲಿಸದೆ ಗೆಲ್ಲುತ್ತವೆ। ip rule add ನಿಂದ ಸೇರಿಸಿದ ನಿಯಮಗಳು ಸಹ ಮರುಬೂಟ್ ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವನ್ನು up ಸ್ಕ್ರಿಪ್ಟ್ ನಲ್ಲಿ ಇಡಿ।

ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ ಎರಡನೇ ವೈಫಲ್ಯ, ಅದು ನಿಮಗೆ ಸಿಗುತ್ತದೆ

1500 ಬೈಟ್ ನ ಸೇತುವೆ ಇಂಟರ್ಫೇಸ್ ಹೊರ UDP ಮತ್ತು IP ಶೀರ್ಷಿಕೆಗಳು ಸೇರಿದ ನಂತರ ಟನೆಲ್ ಗೆ ಅದರ ಸಾಮರ್ಥ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೊಡುತ್ತದೆ। ಸಣ್ಣ ವಿನಿಮಯಗಳು ದಾಟುತ್ತವೆ, ಆದ್ದರಿಂದ DNS ಪರಿಹಾರವಾಗುತ್ತದೆ ಮತ್ತು TLS ಹಸ್ತಲಾಘವ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ನಂತರ ದೊಡ್ಡ ಅಪ್ಲೋಡ್ ಎಲ್ಲೂ ದೋಷವಿಲ್ಲದೆ ನೇತಾಡುತ್ತದೆ। ಕಳುಹಿಸುವವನು ಅದೇ ವಿಭಾಗದ ಗಾತ್ರವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ, ಏಕೆಂದರೆ ಚೂರುಮಾಡುವಿಕೆಯ ಅಗತ್ಯದ ICMP ಸಂದೇಶ, ಅದು ಚಿಕ್ಕದಾಗುವಂತೆ ಹೇಳುತ್ತಿತ್ತು, ಎಂದೂ ತಲುಪುವುದಿಲ್ಲ।

ಅದನ್ನು ಇಂಟರ್ಫೇಸ್ ನಲ್ಲಿ, MSS ನಲ್ಲಿ, ಅಥವಾ ಎರಡರಲ್ಲೂ ಸರಿಪಡಿಸಿ। ಕ್ಲ್ಯಾಂಪಿಂಗ್ ಗೆ ಅತಿಥಿಯ ಸಹಕಾರ ಬೇಕಿಲ್ಲ:

ip link set dev tun0 mtu 1400
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ಕ್ಲ್ಯಾಂಪ್ TCP ಅನ್ನು ಮಾತ್ರ ಮರುಬರೆಯುತ್ತದೆ। UDP, QUIC ಸೇರಿದಂತೆ, ಬದಲಿಗೆ ಅತಿಥಿ ಇಂಟರ್ಫೇಸ್ ಕಡಿಮೆ ಮಾಡುವುದು ಬೇಕು, --opt com.docker.network.driver.mtu=1400 ಜೊತೆ ಜಾಲ ರಚಿಸುವಾಗ ಅಥವಾ ಹೊಂದುವ compose ಕೀ।

DNS ಮತ್ತು ಪುನರಾವರ್ತಿಸಲು ಯೋಗ್ಯವಾದ ಪರಿಶೀಲನೆಗಳು

ಹೆಸರಿನ ಪರಿಹಾರ ಅದೇ ದಾರಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ। Docker ನ ಒಳಗೊಂಡ ರಿಜಾಲ್ವರ್ 127.0.0.11 ನಲ್ಲಿ ಹೋಸ್ಟ್ ನ ಸಂರಚಿತ ಸರ್ವರ್ ಗಳಿಗೆ ರವಾನಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಟೇನರ್ ಹೋಸ್ಟ್ ಬಳಸುವುದನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ। ಖಾಸಗಿ ವಲಯಕ್ಕೆ ಟನೆಲ್ ಮೂಲಕ ತಲುಪಬಲ್ಲ ರಿಜಾಲ್ವರ್ ಮಾತ್ರ ಉತ್ತರಿಸಿದರೆ, ಅತಿಥಿಯನ್ನು ಆ ವಿಳಾಸಕ್ಕೆ ತಿರುಗಿಸಿ, ಮತ್ತು getent hosts ನಿಂದ ಕಂಟೇನರ್ ಒಳಗೆ ಪರೀಕ್ಷಿಸಿ, ಹೋಸ್ಟ್ ನಲ್ಲಿ ಅಲ್ಲ।

  • ವಿಫಲವಾಗುವ ವಿನಂತಿಯನ್ನು ಅತಿಥಿಯ ಒಳಗೆ ಚಲಾಯಿಸಿ; ಹೋಸ್ಟ್ ಬದಿಯ ಪರೀಕ್ಷೆ ಬೇರೆ ಮೂಲ ವಿಳಾಸ ಬಳಸುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ।
  • ನೀವು ಸೇರಿಸಿದ NAT ಮತ್ತು ಫಿಲ್ಟರ್ ನಿಯಮಗಳ ಕೌಂಟರ್ ಗಳನ್ನು ಓದಿ। ಶೂನ್ಯ ಹೊಂದಾಣಿಕೆಯ ನಿಯಮ ರೂಟಿಂಗ್ ತಪ್ಪು, ನೀತಿ ತಪ್ಪಲ್ಲ।
  • ನಿಮ್ಮ SNAT ನಿಯಮದಲ್ಲಿನ ಟನೆಲ್ ವಿಳಾಸವು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಹೊಂದಿರುವುದೇ ಎಂದು ಖಚಿತಪಡಿಸಿ।
  • ಸರ್ವರ್ ಅನ್ನು ನಿಲುಗಡೆಗೆ ದೂಷಿಸುವ ಮೊದಲು ಅತಿಥಿಯ MTU ಕಡಿಮೆ ಮಾಡಿ ಅಥವಾ MSS ಕ್ಲ್ಯಾಂಪ್ ಮಾಡಿ।

ಪಟ್ಟಿಯನ್ನು ಇಳಿದು ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲಿಸಿ। ಆ ಪದರವೇ ಸರಿಪಡಿಸಬೇಕಾದದ್ದು; ಕೆಳಗೆ ಸೇರಿಸಿದ ಯಾವುದೂ ಮುರಿಯುತ್ತಿರುವ ಗಡಿಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ ಅಷ್ಟೇ।

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