OpenVPN ನ UDP ಪ್ರತ್ಯುತ್ತರ ತಪ್ಪು ವಿಳಾಸದಿಂದ ಏಕೆ ಹೊರಡುತ್ತದೆ

OpenVPN ಕ್ಲೈಂಟ್ ಒಂದು ವಿಳಾಸಕ್ಕೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ, ಸರ್ವರ್ ಬೇರೊಂದು ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಎಂದಿಗೂ ಏಳುವುದಿಲ್ಲ. ಸರ್ವರ್ ಲಾಗ್ ಪ್ಯಾಕೆಟ್ ಬರುತ್ತಿರುವುದನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಯಾಪ್ಚರ್ ಉತ್ತರ ಹೊರಡುತ್ತಿರುವುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ದೋಷವನ್ನು ಕ್ಲೈಂಟ್ ಮೇಲೆ ಹೊರಿಸಲಾಗುತ್ತದೆ. ಹಲವು ಇಂಟರ್ಫೇಸ್ಗಳಿರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, ಅಥವಾ ಒಂದೇ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಹಲವು ವಿಳಾಸಗಳಿದ್ದಾಗ, ಯಾವ ವಿಳಾಸ ಬಳಕೆಯಲ್ಲಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಎರಡೂ ಕಡೆಗಳು ಸರಳವಾಗಿ ಒಪ್ಪುವುದಿಲ್ಲ. ಉತ್ತರವು IP ಪದರದಲ್ಲಿ ಮಾನ್ಯವಾಗಿದೆ, ಆದರೂ ಅನೇಕ ಕ್ಲೈಂಟ್ಗಳು ತಾವು ಸಂಪರ್ಕಿಸಿದ ವಿಳಾಸವಲ್ಲದ ಮೂಲವನ್ನು ಹೊಂದಿರುವ ಡೇಟಾಗ್ರಾಮ್ ಅನ್ನು ತಳ್ಳಿಹಾಕುತ್ತವೆ.

ಮೂಲ ಬದಲಾದಾಗ ಕ್ಲೈಂಟ್ ಏನು ನೋಡುತ್ತದೆ

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

ಉತ್ತರಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ಕ್ಲೈಂಟ್ಗಳು, ಮತ್ತು ನಿಖರವಾದ ನಾಲ್ಕು ಮತ್ತು ಮೂಲವನ್ನು ನಿರೀಕ್ಷಿಸುವ ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್, ಉಪಯುಕ್ತ ಸಂದೇಶವಿಲ್ಲದೆ ಉತ್ತರವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ. ನಂತರ ಸುರಂಗವು ಏನೂ ಬಾರದಂತೆ ಸಮಯ ಮೀರಿ ಮುಗಿಯುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಇದನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯ ಫೈರ್ವಾಲ್ ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸಲಾಗುತ್ತದೆ. ಸರ್ವರ್ನಲ್ಲಿ ಮಾತ್ರ ತೆಗೆದ ಕ್ಯಾಪ್ಚರ್ ದೋಷವನ್ನು ವಿವರಿಸುವ ಬದಲು ಅದನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಉತ್ತರ ನಿಜವಾಗಿಯೂ ಹೊರಡುತ್ತದೆ. ಬೇರೆ ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಉತ್ತರದ ಮೂಲವನ್ನು ಕ್ಲೈಂಟ್ ಡಯಲ್ ಮಾಡಿದ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ.

multihome ಆಯ್ಕೆ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

ಈ ಸೂಚನೆಯನ್ನು ಸಂರಚನಾ ಫೈಲ್ನಲ್ಲಿ multihome ಆಗಿ ಮತ್ತು ಆದೇಶ ಸಾಲಿನಲ್ಲಿ --multihome ಆಗಿ ಬರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು ಇದು UDP ಸರ್ವರ್ ಅನ್ನು ಕ್ಲೈಂಟ್ನ ಪ್ಯಾಕೆಟ್ ತಲುಪಿದ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಕರ್ನಲ್ ಸ್ವೀಕರಿಸುವಾಗ ಮೂಲ ಗಮ್ಯ ವಿಳಾಸವನ್ನು ಪೂರಕ ಡೇಟಾ ಆಗಿ ನೀಡುತ್ತದೆ, ಮತ್ತು OpenVPN ಆ ಮೌಲ್ಯವನ್ನು ಉತ್ತರದ ಮೂಲವಾಗಿ ಬಳಸುತ್ತದೆ. ಹೀಗೆ ವೈಲ್ಡ್ಕಾರ್ಡ್ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತಿರುವ ಸರ್ವರ್, IPv4 ಗೆ local 0.0.0.0 ಅಥವಾ ಅದರ IPv6 ಸಮಾನ, ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಪ್ರತ್ಯೇಕ ಶ್ರೋತೆಯನ್ನು ತಲುಪಿದಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಮೂಲಕ ಬಂದ ಕ್ಲೈಂಟ್ಗಳು ಸಾರ್ವಜನಿಕ ವಿಳಾಸದಿಂದ ಉತ್ತರ ಪಡೆಯುತ್ತವೆ, ಮತ್ತು ಆಂತರಿಕ ವಿಳಾಸದಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ಗಳು ಅದೇ ವಿಳಾಸದಿಂದ ಪಡೆಯುತ್ತವೆ. ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗದಲ್ಲಿ ಬೇರೆ ಯಾವುದೂ ಚಲಿಸುವುದಿಲ್ಲ: ಮಾರ್ಗ, ಫಿಲ್ಟರ್ ನಿಯಮಗಳು ಮತ್ತು ಸುರಂಗ ಸಂರಚನೆ ಇದ್ದಂತೆಯೇ ಉಳಿಯುತ್ತವೆ.

ಈ ಕೊನೆಯ ಗುಣವೇ ಆಯ್ಕೆಯನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಸರ್ವರ್ಗೆ ಸೇರಿಸಲು ಸುರಕ್ಷಿತವಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಫಿಲ್ಟರ್ ಅನ್ನು ಅದು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣವೂ ಅದೇ. ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ ಅದು ಹೋಗುವ ಮಾರ್ಗದಲ್ಲಿ ಸ್ವೀಕರಿಸಲ್ಪಡಬೇಕು, ಆದ್ದರಿಂದ ಮೂಲ ಸುಧಾರಣೆ ಉತ್ತರದ ಹುಟ್ಟನ್ನು ಬದಲಿಸುತ್ತದೆ, ಅಷ್ಟೇ. ಇದು UDP ಗೆ ಮಾತ್ರ: TCP ಶ್ರೋತೆಗೆ ಇದೇ ರೂಪದಲ್ಲಿ ಈ ಸಮಸ್ಯೆ ಇಲ್ಲ, ಏಕೆಂದರೆ ಸಂಪರ್ಕವನ್ನು ಉತ್ತರದ ಮೂಲ ವಿಳಾಸದಿಂದಲ್ಲ, ನಾಲ್ಕರಿಂದ ಗುರುತಿಸಲಾಗುತ್ತದೆ.

ಸ್ಥಿರ ಸ್ಥಳೀಯ ವಿಳಾಸ ಯಾವಾಗ ತಪ್ಪು ಡೀಫಾಲ್ಟ್

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

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

ಉತ್ತರದ ಮೂಲವನ್ನು ಹೊರಗಿನಿಂದ ಸಾಬೀತುಪಡಿಸಿ

ಸರ್ವರ್ನ ಹೊರಗಿನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಏನನ್ನೂ ಸೆರೆಹಿಡಿಯುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಬಳಸಿದ ನಿಖರ ವಿಳಾಸ ಮತ್ತು ಸಾಗಣೆಯನ್ನು ದಾಖಲಿಸಿ. ಕೆಳಗಿನ ಮೂರು ಪರಿಶೀಲನೆಗಳು ಮೂರು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಕ್ರಮ ಮುಖ್ಯ.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

ಮಾರ್ಗನಿರ್ದೇಶನ, ಶೋಧನೆ ಮತ್ತು ಫಿಲ್ಟರಿಂಗ್ ಪ್ರತ್ಯೇಕವಾಗಿ ಉಳಿಯುತ್ತವೆ

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

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