ಎರಡು DNS ಹೆಸರುಗಳು, ಒಂದು OpenVPN ಪೋರ್ಟ್: ನಿಜವಾಗಿ ಏನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ

ಎರಡು A ದಾಖಲೆಗಳು, ಒಂದು ವಿಳಾಸ, ಒಂದು ಡೀಮನ್: ಬಳಕೆದಾರ ಯಾವ ಹೆಸರನ್ನು ಟೈಪ್ ಮಾಡಿದರೂ ಬರುವ ಪ್ಯಾಕೆಟ್ ಒಂದೇ ರೀತಿಯದ್ದಾಗಿರುತ್ತದೆ, ಮತ್ತು 1194 ಪೋರ್ಟ್‌ಗೆ ಬದ್ಧವಾದ ಪ್ರಕ್ರಿಯೆಗೆ ಎರಡನ್ನೂ ಬೇರ್ಪಡಿಸಲು ಏನೂ ಇಲ್ಲ. ಇದು ಸರಿಪಡಿಸಲು ಕಾಯುತ್ತಿರುವ ತಪ್ಪು ಸಂರಚನೆ ಅಲ್ಲ; ಇದು ಹೆಸರಿನ ಹುಡುಕಾಟ ವ್ಯಕ್ತಪಡಿಸಬಹುದಾದ ಮಿತಿ. ಎರಡು OpenVPN ಪ್ರತಿಗಳ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವ ಯಾವುದೇ ವಿಷಯವು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕದಲ್ಲಿ ಇಡುವ ಮತ್ತು ಮುಂಭಾಗವು ಮತ್ತೆ ಓದಬಹುದಾದ ಮೌಲ್ಯವಾಗಿರಬೇಕು, ಮತ್ತು ಸಾಮಾನ್ಯ OpenVPN ಕ್ಲೈಂಟ್ ಅಂತಹ ಮೌಲ್ಯವನ್ನು ಬಹಿರಂಗವಾಗಿ ಇಡುವುದಿಲ್ಲ. ಮುಂದೆ ಬರುವುದು ಇದು ನಿಮ್ಮನ್ನು ಎಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಯಾವ ವ್ಯವಸ್ಥೆಗಳು ಸಂಚಾರವನ್ನು ನಿಜವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತವೆ ಎಂಬುದು.

ಪರಿಹಾರಕ ಹಿಂತಿರುಗಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

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

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

ಎಣಿಕೆಗೆ ಬರುವ ಏಕೈಕ ಆಯ್ಕೆದಾರ ಪ್ಯಾಕೆಟ್‌ನ ಒಳಗೆ ಸಾಗುತ್ತದೆ

HTTP ಇದನ್ನು Host ಹೆಡರ್‌ನಿಂದ ನಿಭಾಯಿಸುತ್ತದೆ, TLS ClientHello ನಲ್ಲಿ ಸರ್ವರ್ ಹೆಸರಿನ ವಿಸ್ತರಣೆಯಿಂದ, ಮತ್ತು ಹೀಗೆ ಒಂದು ವಿಳಾಸವು ಒಂದು ಶ್ರೋತೃವಿನ ಹಿಂದೆ ಅನೇಕ ಸೈಟ್‌ಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ. ಎರಡೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಏಕೆಂದರೆ ತಂತಿಯ ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ದಿಷ್ಟ ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಒಯ್ಯುತ್ತದೆ. OpenVPN ಬಗ್ಗೆ ಸಂಬಂಧಿತ ಸತ್ಯವೆಂದರೆ ಮಧ್ಯವರ್ತಿ ಪೆಟ್ಟಿಗೆ ಪರಿಶೀಲಿಸುವ ಪದರದಲ್ಲಿ ಈ ಎರಡೂ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಒಂದೂ ಇಲ್ಲ.

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

ಪ್ರೋಟೋಕಾಲ್ ವಿಭಾಜಕ ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ

sslh ಯೋಜನೆ ದಾಖಲಿಸುವ ಮಾದರಿಯ ಮಲ್ಟಿಪ್ಲೆಕ್ಸರ್ ಒಂದು ಪೋರ್ಟ್‌ನಲ್ಲಿ ಕೇಳುತ್ತದೆ, ಆರಂಭದ ಬೈಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಗುರುತಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡುವ ಯಾವುದೇ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ಒಪ್ಪಿಸುತ್ತದೆ. ಒಂದೇ ಪೋರ್ಟ್ SSH, HTTPS ಮತ್ತು OpenVPN ಗೆ ಒಟ್ಟಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಬೇಕಾದಾಗ ಇದು ನಿಜವಾದ ಮೌಲ್ಯ.

sslh ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಪರಿಶೋಧನೆ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದರ TLS ಪರಿಶೋಧನೆ ನಿಜವಾದ ClientHello ನಿಂದ ಸರ್ವರ್ ಹೆಸರು ಅಥವಾ ALPN ಮೌಲ್ಯವನ್ನು ಹೊರತೆಗೆಯಬಲ್ಲದು. ಸ್ಥಳೀಯ OpenVPN ಗುರುತಿಸುವುದು TLS ವಿಸ್ತರಣೆ ಓದುವುದಕ್ಕಿಂತ ಬೇರೆ ವರ್ಗೀಕರಣ, ಮತ್ತು ಎರಡೂ ಒಟ್ಟುಗೂಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕೇಳುವ ಸಾಕೆಟ್‌ಗೆ ಎಂದಿಗೂ ClientHello ಕಳುಹಿಸದ ಕ್ಲೈಂಟ್ ಪರಿಶೋಧನೆಯನ್ನು ಓದಲು ಏನೂ ಇಲ್ಲದೆ ಬಿಡುತ್ತದೆ. ಆದ್ದರಿಂದ OpenVPN ಗೆ ಹೊಂದುವ ನಿಯಮ “ಇದು OpenVPN ಕ್ಲೈಂಟ್” ಎಂದು ಉತ್ತರಿಸಿ ಮುಂದೆ ಹೋಗುವುದಿಲ್ಲ. ಆ ನಿಯಮದ ಹಿಂದೆ ಇರುವ ಎರಡು OpenVPN ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ಬೇರ್ಪಡಿಸಲಾಗದು, ಮುಂಭಾಗಕ್ಕೆ ಆಯ್ಕೆಗೆ ಯಾವುದೇ ಆಧಾರವಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಅಧಿವೇಶನವೂ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇಳಿಯುತ್ತದೆ. ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಒಂದು ಪೋರ್ಟ್ ಅನ್ನು ವಿವಿಧ ಸೇವೆಗಳ ನಡುವೆ ಹಂಚುತ್ತದೆ; ಅದು ಒಂದೇ ಸೇವೆಯ ಒಳಗೆ ವರ್ಚುವಲ್ ಹೋಸ್ಟಿಂಗ್ ಮಾಡುವುದಿಲ್ಲ.

ಎರಡು ಸರ್ವರ್‌ಗಳನ್ನು ನಿಜವಾಗಿ ಬೇರ್ಪಡಿಸುವ ವ್ಯವಸ್ಥೆಗಳು

ಅಗ್ಗದ ಪ್ರಾಮಾಣಿಕ ವಿಭಜನೆ ಎಂದರೆ ಎರಡನೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ, ಪ್ರತಿ ಪ್ರತಿಗೆ ಒಂದು, ಮತ್ತು ಇರುವ ಪ್ರೊಫೈಲ್‌ಗಳು ಬೇಕಾದದ್ದನ್ನು ಈಗಾಗಲೇ ಹೊತ್ತಿವೆ ಏಕೆಂದರೆ ಅವು ವಿವಿಧ ವಿಳಾಸಗಳಿಗೆ ತೋರಿಸುತ್ತವೆ. ಮುಂದಿನದು ಅದೇ ವಿಳಾಸದಲ್ಲಿ ಬೇರೆ ಪೋರ್ಟ್, ಅದು ಪ್ರತಿ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಒಂದು ಸಂಖ್ಯೆಗಿಂತ ಹೆಚ್ಚು ಏನನ್ನೂ ವೆಚ್ಚ ಮಾಡುವುದಿಲ್ಲ. TCP ಮತ್ತು UDP ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್ ಕೋಷ್ಟಕಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ 1194/tcp ಮತ್ತು 1194/udp ಸಂಬಂಧವಿಲ್ಲದ ಸಾಕೆಟ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದರಿಂದ ಒಂದು ಒಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಜೊತೆಯಾಗಿ ಇರಬಹುದು; ಇದು ಸಾಗಣೆ ವಿಭಜನೆ, ಹೆಸರು-ಮಾರ್ಗನಿರ್ದೇಶನ ಅಲ್ಲ, ಮತ್ತು ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಅದರೊಂದಿಗೆ ಗೊಂದಲಿಸಲಾಗುತ್ತದೆ. ಎರಡೂ ಆಯ್ಕೆಗಳು ಫೈರ್‌ವಾಲ್ ಪರಿಶೀಲನೆಯನ್ನು ದಾಟುತ್ತವೆ, ಏಕೆಂದರೆ ನಿಯಮವು ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ನಿಜವಾಗಿ ಇರುವುದಕ್ಕೆ ಹೊಂದುತ್ತದೆ.

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

OpenVPN ಮುಂದೆ ಇಡುವ TLS ಅಂತ್ಯಕಾರಿಯು ಸಮರ್ಥ ಮುಂಭಾಗಕ್ಕೆ ನಿಜವಾದ ಸರ್ವರ್ ಹೆಸರನ್ನು ಬಹಿರಂಗಪಡಿಸಬಲ್ಲದು, ಆದರೆ ಕ್ಲೈಂಟ್ ಕಡೆಯೂ ಆ ಹೆಚ್ಚುವರಿ ಪದರಕ್ಕೆ ಸಂರಚಿಸಲಾಗಿದ್ದರೆ ಮಾತ್ರ. ಇರುವ ಪ್ರೊಫೈಲ್‌ಗಳು ಅದೇ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವುದರಿಂದ ಆ ವರ್ತನೆಯನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.

ನಿರ್ಮಿಸುವ ಮೊದಲು ಆಯ್ಕೆದಾರವನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

openssl ಸಾಲು ಪ್ರಮಾಣಪತ್ರವನ್ನು ಆ ವಿಳಾಸದಲ್ಲಿ ಏನಾದರೂ TLS ಮುಗಿಸುವಲ್ಲಿ ಮಾತ್ರ ನೀಡುತ್ತದೆ; ಸ್ಥಳೀಯ OpenVPN ಶ್ರೋತೃವ ವಿರುದ್ಧ ಅದು ನಿಲ್ಲುತ್ತದೆ ಅಥವಾ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಹೊರ ಪದರ ಏನನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಉತ್ತರ. journal ಸಾಲು, ಪ್ರತಿ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಓದಿದಾಗ, ಯಾವ ಪ್ರತಿ ಅಧಿವೇಶನವನ್ನು ಸ್ವೀಕರಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ. ಮುಂಭಾಗದ ಲಾಗ್‌ಗಳು ವರ್ಗೀಕರಿಸಿದ್ದನ್ನು ಬರೆಯುತ್ತವೆ ಮತ್ತು ಉದ್ದೇಶಿಸಿದ್ದನ್ನು ಎಂದಿಗೂ ಬರೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಬಳಕೆದಾರ ಎಲ್ಲಿ ಇಳಿದನು ಎಂಬುದಕ್ಕೆ ಬ್ಯಾಕೆಂಡ್ ಒಂದೇ ಅಧಿಕಾರಿಯಾಗಿ ಉಳಿಯುತ್ತದೆ.

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