ಸೈಟ್-ಟು-ಸೈಟ್ VPN ನ ಉತ್ತರ ಸುರಂಗದ ಮೂಲಕ ಹೋಗುತ್ತಿಲ್ಲ
ಸುರಂಗವನ್ನು ಬಳಸದ ಉತ್ತರವು ದೂರದ ಬದಿಯ ಮಾರ್ಗನಿರ್ದೇಶನ ನಿರ್ಣಯವಾಗಿದೆ. ಹೋಸ್ಟ್ ಕೋಷ್ಟಕ, ಸೆಲೆಕ್ಟರ್‌ಗಳು ಮತ್ತು rp_filter ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮಾರ್ಗ ಅಥವಾ NAT ಆಯ್ಕೆಮಾಡಿ.
ಒಂದು ಬೆಳಗನ್ನು ಸುರಂಗಕ್ಕೆ ಮೀಸಲಿಟ್ಟೆ: ಅದು ಸ್ವಚ್ಛವಾಗಿ ಮೇಲೆ ಬಂದು ಸಂಚಾರವನ್ನು ನಿಖರವಾಗಿ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಸಾಗಿಸಿತು — ಶಾಖೆ ಪ್ರಧಾನ ಕಚೇರಿಯ ಫೈಲ್ ಸರ್ವರ್ ತಲುಪುತ್ತಿತ್ತು, ಮತ್ತು ಪ್ರಧಾನ ಕಚೇರಿಯಿಂದ ಶಾಖೆಗೆ ತೆರೆದ ಪ್ರತಿ ಸಂಪರ್ಕವೂ ಮೊದಲ SYN ನಲ್ಲೇ ಸಾಯುತ್ತಿತ್ತು. SA ಗಳು ಸಕ್ರಿಯವಾಗಿದ್ದವು, ಸುರಂಗದ ಕೌಂಟರ್‌ಗಳು ಏರುತ್ತಿದ್ದವು, ಮತ್ತು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಎಂದೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ. ಉತ್ತರವು ಸುರಂಗ ಆವರಿಸದ ಜಾಗಕ್ಕೆ ಮಾರ್ಗನಿರ್ದೇಶನವಾಗುತ್ತಿತ್ತು, ಮತ್ತು ಆ ಆಯ್ಕೆ ದೂರದ ಬದಿಯದು. ಸೈಟ್-ಟು-ಸೈಟ್ VPN ಹೋಸ್ಟ್ ಗೇಟ್‌ವೇಗೆ ಒಪ್ಪಿಸುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಹೋಸ್ಟ್ ಆ ಆಯ್ಕೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ, ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲಿ, ತನ್ನದೇ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕದಿಂದ ಮಾಡುತ್ತದೆ.
ಎರಡೂ ದಿಕ್ಕುಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾರ್ಗನಿರ್ದೇಶನಗೊಳ್ಳುತ್ತವೆ
IP ಸಂಭಾಷಣೆಯ ದಿಕ್ಕಿನ ಯಾವುದೇ ಜ್ಞಾಪಕವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ. ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುವ ಪ್ರತಿ ಹೋಸ್ಟ್ ತನ್ನದೇ ದೀರ್ಘತಮ ಪ್ರಿಫಿಕ್ಸ್ ಹುಡುಕಾಟ ನಡೆಸಿ, ಒಂದು ಮುಂದಿನ ಹಾಪ್ ಆಯ್ಕೆಮಾಡಿ, ನಿರ್ಣಯವನ್ನು ಮರೆತುಬಿಡುತ್ತದೆ. ವಿನಂತಿ ಮತ್ತು ಉತ್ತರ ಒಂದೇ ಸಂಪರ್ಕಕ್ಕೆ ಆಕಸ್ಮಿಕವಾಗಿ ಸೇರಿದ ಎರಡು ಸಂಬಂಧವಿಲ್ಲದ ಪ್ಯಾಕೆಟ್‌ಗಳು, ಮತ್ತು ಸುರಂಗ ಎರಡರಲ್ಲಿ ಯಾವುದಾದರೂ ಬಳಸಬಹುದಾದ ಅಥವಾ ಬಳಸದಿರಬಹುದಾದ ಒಂದು ಹಾಪ್. IKE ವಿನಿಮಯದಲ್ಲಿ ಏನೂ ದೂರದ ಸರ್ವರ್‌ಗೆ ನಿಮ್ಮ ಸಬ್‌ನೆಟ್ ತಲುಪುವ ಬಗೆಯನ್ನು ಕಲಿಸುವುದಿಲ್ಲ; ಮಾತುಕತೆ ಯಾವ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಗೂಢಲಿಪೀಕರಿಸಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ಮಾತ್ರ ಒಪ್ಪುತ್ತದೆ.
ಆ ಒಪ್ಪಂದವೇ ಎರಡನೇ ದ್ವಾರ. strongSwan ನಲ್ಲಿ ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್‌ಗಳು leftsubnet ಮತ್ತು rightsubnet, ಮತ್ತು ಮೂಲ ಅಥವಾ ಗಮ್ಯಸ್ಥಾನ ಒಪ್ಪಿದ ಜೋಡಿಯ ಹೊರಗೆ ಬೀಳುವ ಪ್ಯಾಕೆಟ್ ಗೂಢಲಿಪೀಕರಣಗೊಳ್ಳುವುದಿಲ್ಲ, ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕ ಏನೇ ಹೇಳಲಿ. ಸುರಂಗಕ್ಕೆ ಮಾರ್ಗನಿರ್ದೇಶನಗೊಂಡರೂ ಸೆಲೆಕ್ಟರ್‌ಗಳಲ್ಲಿ ಇಲ್ಲದ ಪ್ರಿಫಿಕ್ಸ್ ಶಾಂತ ಏಕಮುಖ ವೈಫಲ್ಯ: ಮಾರ್ಗ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಹೇಗಿದ್ದರೂ ಬಯಲಿನಲ್ಲಿ ಹೊರಡುತ್ತದೆ ಅಥವಾ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ, ಮತ್ತು charon ಲಾಗ್ ಮಾತ್ರ ದೂರುತ್ತದೆ.
ದೂರದ ಹೋಸ್ಟ್ ನಿಮ್ಮ ಸುರಂಗದ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ
ದೂರದ LAN ಒಳಗೆ ಉತ್ತರ ನಿಮ್ಮ ಕ್ಲೈಂಟ್‌ಗೆ ವಿಳಾಸಗೊಂಡ ಸಾಮಾನ್ಯ ಪ್ಯಾಕೆಟ್. ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್ ಯಾವುದೇ IPsec ಶೀರ್ಷಿಕೆ ನೋಡುವುದಿಲ್ಲ ಮತ್ತು VPN ಗೇಟ್‌ವೇಗೆ ಆದ್ಯತೆ ನೀಡಲು ಕಾರಣವಿಲ್ಲ; ಅದು ನಿಮ್ಮ ಪ್ರಿಫಿಕ್ಸ್ ಹುಡುಕಿ, ತನ್ನ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗಕ್ಕಿಂತ ನಿರ್ದಿಷ್ಟವಾದದ್ದು ಸಿಗದೆ ಅದನ್ನೇ ಅನುಸರಿಸುತ್ತದೆ. ಡಿಫಾಲ್ಟ್ ಮುಖ್ಯ ಫೈರ್‌ವಾಲ್‌ಗೆ ಸೂಚಿಸಿದರೆ, ಫೈರ್‌ವಾಲ್‌ಗೆ ಸುರಂಗಕ್ಕೆ ಮರಳುವ ಮಾರ್ಗ ಇದೆಯೋ ಇಲ್ಲವೋ. ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಶಾಂತ ತಿರಸ್ಕಾರ, ICMP unreachable, ಅಥವಾ ಇಂಟರ್ನೆಟ್ ಕಡೆಗಿನ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ ಹೊರಟು ಸಾಯುವ ಉತ್ತರ ಪಡೆಯುತ್ತೀರಿ.
ಮಾರ್ಗ ಇದ್ದರೂ ಎರಡನೇ ಇಂಟರ್‌ಫೇಸ್ ಇದನ್ನು ಮುರಿಯಲು ಸಾಕು. ಬೇರೆ VLAN ನಲ್ಲಿ ನಿರ್ವಹಣಾ ಕೊಂಡಿ ಇರುವ NAS, ಬ್ಯಾಕಪ್ uplink ಇರುವ ಸರ್ವರ್, ಒಂದು ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ಎರಡನೇ ಕೋಷ್ಟಕಕ್ಕೆ ಕಳುಹಿಸುವ ನೀತಿ ನಿಯಮ: ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಉತ್ತರವನ್ನು ಹಿಡಿಯಬಹುದು. Linux ನಲ್ಲಿ, ip rule show ಮತ್ತು ip route show table all ಡಿಫಾಲ್ಟ್ ಪಟ್ಟಿ ಮರೆಮಾಡುವ ನಿಯಮಗಳು ಮತ್ತು ಕೋಷ್ಟಕಗಳನ್ನು ತೋರಿಸುತ್ತವೆ.
ಉತ್ತರ ಕಳುಹಿಸುವ ಯಂತ್ರದಲ್ಲಿ ನಿರ್ಣಯವನ್ನು ಓದಿ
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಕರ್ನೆಲ್‌ಗೆ ಕೇಳಿ, ಮತ್ತು ಅದಕ್ಕೆ ಮೂಲ ವಿಳಾಸ ಕೊಡಿ, ಏಕೆಂದರೆ ಮೂಲಾಧಾರಿತ ನಿಯಮಗಳು ಉತ್ತರವನ್ನು ಬದಲಿಸುತ್ತವೆ.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"ಔಟ್‌ಪುಟ್ ಹೊರಹೋಗುವ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಹೆಸರಿಸುತ್ತದೆ. ಇಂಟರ್‌ಫೇಸ್ VPN ಗೇಟ್ವೇ ಕಡೆಗಿನದು ಅಲ್ಲದಿದ್ದರೆ, ನೀವು ದೋಷ ಕಂಡುಕೊಂಡಿದ್ದೀರಿ, ಮತ್ತು ಉಳಿದ ಕೆಲಸ ಮಾರ್ಗ ಎಲ್ಲಿರಬೇಕೆಂದು ಆಯ್ಕೆಮಾಡುವುದು. ಗೇಟ್‌ವೇಯಿಂದ ಮಾಡಿದ ping ಇಲ್ಲಿ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ಅದು ದೂರದ ಹೋಸ್ಟ್ ಇರಿಸಬಹುದಾದ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತದೆ, ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ ವಿಳಾಸದಿಂದ ಅಲ್ಲ.
Windows ನಲ್ಲಿ ಸಮಾನವಾದವು ನಿರ್ಣಯಕ್ಕೆ Find-NetRoute -RemoteIPAddress 10.10.5.10 ಮತ್ತು ಕೋಷ್ಟಕಕ್ಕೆ Get-NetRoute. ಡಿಫಾಲ್ಟ್‌ಗಿಂತ ಹೆಚ್ಚಿನ ಮೆಟ್ರಿಕ್ ಹೊತ್ತ New-NetRoute ನಿಂದ ಸೇರಿಸಿದ ಮಾರ್ಗ ಶಾಂತವಾಗಿ ಸೋಲುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೆಟ್ರಿಕ್ ಕಾಲಮ್ ಓದಿ, ನಮೂದು ಅಲ್ಲ. ನಂತರ ಪ್ಯಾಕೆಟ್‌ಗಳಿಂದ ಖಚಿತಪಡಿಸಿ: ದೂರದ LAN ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ tcpdump -ni any "host 10.10.5.10 and tcp port 445" ವಿನಂತಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗದ ಬದಿಯಲ್ಲಿ ಅದೇ ಫಿಲ್ಟರ್ ಉತ್ತರ ಮರಳಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ವಿನಂತಿ ಕಾಣುತ್ತದೆ, ಉತ್ತರವಿಲ್ಲ — ಉತ್ತರ ಬೇರೆಡೆ ಮಾರ್ಗನಿರ್ದೇಶನಗೊಂಡಿದೆ ಅಥವಾ ಬಿಸಾಡಲ್ಪಟ್ಟಿದೆ; ತಪ್ಪು ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಉತ್ತರ ಬಂದರೆ ಮಾರ್ಗ ಮುಟ್ಟುವ ಮೊದಲೇ ಅಪರಾಧಿಯನ್ನು ನೀಡುತ್ತದೆ.
ಸರ್ವರ್‌ನ ಗೇಟ್ವೇ VPN ಅಂತ್ಯಬಿಂದು ಅಲ್ಲದಿದ್ದಾಗ
ಅನೇಕ ಸೈಟ್‌ಗಳು ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಕೇಂದ್ರೀಕರಣ ಸಾಧನದ ನಡುವೆ ಫೈರ್‌ವಾಲ್ ಇಡುತ್ತವೆ. ಆ ಫೈರ್‌ವಾಲ್ ಉತ್ತರವನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್‌ಗಾಗಿ VPN ಗೇಟ್ವೇ ಕಡೆಗೆ ತೋರುವ ಮಾರ್ಗ ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನೀತಿ ಬೇಕು. ಸ್ಥಿತಿ ಉಳಿಸುವ ಸಾಧನಗಳು ಇನ್ನೂ ಕೆಡಿಸುತ್ತವೆ: ವಿನಂತಿ ಫೈರ್‌ವಾಲ್ ದಾಟಿ ಬಂತು ಅದು ಅನುಮತಿಸಿದ LAN ಹೋಸ್ಟ್‌ನಿಂದ, ಉತ್ತರ ಈಗ ಬೇರೆ ದಿಕ್ಕಿನಿಂದ ಬರುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ನಮೂದು ಇನ್ನು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ಯಾಕೆಟ್ ನಿರಾಕರಿಸಲ್ಪಡುವ ಬದಲು ಅಮಾನ್ಯ ಎಂದು ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ. ಸಂಚಾರ ಮಾಯವಾಗುತ್ತಿರುವಾಗ ನೀತಿ ಲಾಗ್ ಖಾಲಿ ಕಾಣಲು ಇದೇ ಕಾರಣ.
ಗೇಟ್‌ವೇಗೆ ಅದರದೇ ಎರಡನೇ ಫಿಲ್ಟರ್ ಇದೆ. Linux ನ ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಫಿಲ್ಟರಿಂಗ್, ತಾವು ಬಂದ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಮೂಲ ತಲುಪಲಾಗದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಿಸಾಡುತ್ತದೆ, ಮತ್ತು ಇದು ಕಾನೂನುಬದ್ಧ ಅಸಮಮಿತೀಯ ಹಿಂತಿರುಗು ಮಾರ್ಗದ ನಿಖರ ರೂಪ. strongSwan ನ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮಾರ್ಗದರ್ಶಿ ಅದೇ ಕಾರಣಕ್ಕೆ net.ipv4.ip_forward ಮತ್ತು ಸಡಿಲಿಸಿದ net.ipv4.conf.all.rp_filter ಕೇಳುತ್ತದೆ. ಯಾವುದೇ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಿನ 1 ಮೌಲ್ಯ ಸರಿಯಾದ ಮಾರ್ಗವನ್ನು ಶಾಂತವಾಗಿ ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ತಿಳಿದಿದ್ದರೆ nstat -az ತಿರಸ್ಕಾರಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
ಮಾರ್ಗ ಮಾಡಿ ಅಥವಾ ಅನುವಾದಿಸಿ, ನಂತರ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ
ಎರಡು ಸರಿಪಡಿಸುವಿಕೆಗಳು ಸಮಾನವಲ್ಲ. ಮಾರ್ಗ ಸೇರಿಸುವುದು ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಹಾಗೆಯೇ ಉಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂಲಾಧಾರಿತ ನಿಯಮಗಳು, ಆಡಿಟ್ ಲಾಗ್‌ಗಳು ಮತ್ತು ಕರೆ ಮಾಡಿದವರನ್ನು ದಾಖಲಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತವೆ; ಬೆಲೆ ಎಂದರೆ ನಿರ್ಣಯ ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರತಿ ಹಾಪ್‌ಗೂ ಮಾರ್ಗ ಬೇಕು, ಅಂದರೆ ತಪ್ಪಾಗುವ ಹೆಚ್ಚು ಸ್ಥಳಗಳು. ದೂರದ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಮುಖವಾಡ ಹಿಂತಿರುಗು ಮಾರ್ಗವನ್ನು ಒಂದು ಹಾಪ್‌ಗೆ ಸಂಕೋಚಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಉತ್ತರ ಈಗ ಗೇಟ್‌ವೇಗೇ ವಿಳಾಸಗೊಂಡಿದೆ, ಮತ್ತು ಯಾವ ಕ್ಲೈಂಟ್ ಏನು ಮಾಡಿತು ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆಮಾಡಿ: ಕ್ಲೈಂಟ್‌ಗಳು ಗೇಟ್ವೇ ವಿಳಾಸವಾಗಿ ಕಾಣಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಮೂಲಾಧಾರಿತ ACL ಗಳು ಅವರನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ, ಮತ್ತು ಉತ್ತರವನ್ನು ಸುರಂಗಕ್ಕೆ ಮರಳಿ ಬರೆಯಲು conntrack ಮ್ಯಾಪಿಂಗ್ ಹಿಡಿದಿಡಬೇಕು. ಸೆಲೆಕ್ಟರ್‌ಗಳು ಇನ್ನೂ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಹೊರಗಿಟ್ಟರೆ, NAT ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿನಂತಿ ಎಂದೂ ಸುರಂಗ ಪ್ರವೇಶಿಸಿಲ್ಲ.
ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುವ ಮೊದಲು ನಾಲ್ಕನ್ನು ಕ್ರಮವಾಗಿ ಖಚಿತಪಡಿಸಿ: ಉತ್ತರ ಕಳುಹಿಸುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿನ ಮಾರ್ಗ, ಅದನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಪ್ರತಿ ಹಾಪ್‌ನಲ್ಲಿನ ಮಾರ್ಗ, ಎರಡೂ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಆವರಿಸುವ ಸೆಲೆಕ್ಟರ್‌ಗಳು, ಮತ್ತು ಉತ್ತರ ನೀವು ನಿರೀಕ್ಷಿಸುವ ಮೂಲದೊಂದಿಗೆ ಸುರಂಗ ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುವ ಸೆರೆಹಿಡಿಯುವಿಕೆ. ನಂತರ ಇನ್ನೊಂದು ಸೈಟ್‌ನಿಂದ ಪರೀಕ್ಷೆ ಪುನರಾವರ್ತಿಸಿ. ಒಂದು ದಿಕ್ಕು ಹಾದುಹೋಗುವುದು ಅರ್ಧ-ತೆರೆದ ವಿನ್ಯಾಸ, ಮತ್ತು ಎರಡನೇ ದಿಕ್ಕು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಈಗಷ್ಟೇ ಸರಿಪಡಿಸಿದ್ದಕ್ಕಿಂತ ಬೇರೆ ಕಾರಣದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ.