ಹಲವು ಮಾರ್ಗಗಳಲ್ಲಿ VPN: ವಾಹಕವು ಒದಗಿಸಬೇಕಾದ ನಾಲ್ಕು ಖಾತರಿಗಳು

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

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

ಲಕ್ಷಣ: ಲಿಂಕ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿವೆ, ಸೆಷನ್ ಇನ್ನೂ ಮುರಿಯುತ್ತದೆ

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

ವರ್ಗಾವಣೆ ನಿಂತಾಗ, ವಾಹಕವು ಉಳಿದ ಮಾರ್ಗದಲ್ಲಿ ವಿತರಣೆಯನ್ನು ಮುಂದುವರಿಸಿತೇ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ. ಎರಡನೇ ಲಿಂಕ್ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ ಸೆಷನ್ ಸತ್ತರೆ, ವಾಹಕವು ಅದನ್ನು ಎಂದೂ ಬಳಸಿಲ್ಲ. ಸೆಷನ್ ಉಳಿದರೂ ಡೇಟಾ ಕ್ರಮವಿಲ್ಲದೆ ಅಥವಾ ದ್ವಿಗುಣವಾಗಿ ಬಂದರೆ, ವಾಹಕವು ಸಂಪರ್ಕ ಮಟ್ಟದ ಒಪ್ಪಂದವಿಲ್ಲದೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸರಿಸುತ್ತಿದೆ. ಎರಡೂ ಕಡೆಯ ಸಮಯ ಮುದ್ರೆಗಳು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಪಷ್ಟಪಡಿಸುತ್ತವೆ.

ಈ ವ್ಯತ್ಯಾಸವೇ ಪರಿಹಾರವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ರೂಟಿಂಗ್ ಅಥವಾ ನೀತಿ ಸಮಸ್ಯೆಗೆ ಮಾರ್ಗ ಆಯ್ಕೆ ಬದಲಾವಣೆ ಬೇಕು; ಕಾಣೆಯಾದ ಕ್ರಮ ಮತ್ತು ಮರುಪ್ರಾಪ್ತಿ ಪದರಕ್ಕೆ ಬೇರೆ ಸಾಗಣೆ ಬೇಕು, ದೊಡ್ಡ ಬಫರ್ ಅಲ್ಲ.

ಮೊದಲ ಖಾತರಿ: ಸಂಪರ್ಕ ಮಟ್ಟದಲ್ಲಿ ಬೈಟ್ ಸ್ಟ್ರೀಮ್

VPN ಗೆ ನಂಬಲರ್ಹ ಕ್ರಮಬದ್ಧ ಸ್ಟ್ರೀಮ್ ಬೇಕಾದರೆ, ವಾಹಕವು ಪ್ರತ್ಯೇಕ ಮಾರ್ಗದ ಮೇಲೆ ಬೈಟ್ ಶ್ರೇಣಿಗಳನ್ನು ಗುರುತಿಸಬೇಕು. ಪ್ರತಿ ಮೂಲ TCP ಸಂಪರ್ಕವು ತನ್ನದೇ ವಿಭಾಗಗಳನ್ನು ಮಾತ್ರ ಸಂಖ್ಯೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ವೀಕರಿಸುವವನು ಆ ಸಂಖ್ಯೆಗಳಿಂದ ಮಾತ್ರ ಮಾರ್ಗಗಳ ನಡುವೆ ಮರುಕ್ರಮ ಮಾಡಲಾರನು.

Multipath TCP ಪ್ರಮಾಣಿತ ಉದಾಹರಣೆ. ಒಂದು ನಂಬಲರ್ಹ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಒದಗಿಸುತ್ತಾ ಹಲವು TCP ಉಪಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸುತ್ತದೆ, ಡೇಟಾ ಮಟ್ಟದ ಕ್ರಮ ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ದೃಢೀಕರಣದೊಂದಿಗೆ. ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟ್ರೀಮ್ ಓದುತ್ತದೆ, ತುಣುಕನ್ನು ಮೊದಲು ಒದಗಿಸಿದ ಉಪಸ್ಟ್ರೀಮ್ ಅಲ್ಲ.

Linux ನಲ್ಲಿ MPTCP ಪ್ರತಿ ಸಾಕೆಟ್‌ಗೆ IPPROTO_MPTCP ಮೂಲಕ opt-in. ಸಮಾಲೋಚನೆ ಬಹುಮಾರ್ಗ ವರ್ತನೆಯನ್ನು ಬಳಸಲಾಗದಿದ್ದಾಗ, ದಾಖಲಿತ ಪರ್ಯಾಯ ಸಾಮಾನ್ಯ TCP, ಅಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಎರಡನೇ ಮಾರ್ಗವನ್ನು ಎಂದೂ ಬಳಸದೆ ಒಂದು ಮಾರ್ಗದಲ್ಲಿ ಮುಂದುವರಿಯಬಹುದು. ಕರ್ನಲ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ವಯವಾಯಿತು ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿಯೋಜಿತ ಸಾಕೆಟ್ ವಾಸ್ತವವಾಗಿ ಯಾವ ವರ್ತನೆಗೆ ಒಪ್ಪಿಗೆ ನೀಡಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಎರಡನೇ ಖಾತರಿ: ಕ್ರಮ, ನಕಲು ಮತ್ತು ಮರುಪ್ರಾಪ್ತಿ

ವಿಭಿನ್ನ ವಿಳಂಬ ಮತ್ತು ನಷ್ಟ ದರಗಳ ಮಾರ್ಗಗಳು ವಾಹಕವನ್ನು ಬಫರಿಂಗ್, ಮರುಕ್ರಮ ಮತ್ತು ಮರುಪ್ರಸಾರಕ್ಕೆ ಒತ್ತಾಯಿಸುತ್ತವೆ. ಎಷ್ಟು ಬಫರಿಂಗ್ ಅನುಮತಿಸಲಾಗಿದೆ, ಅಪ್ಲಿಕೇಶನ್ ಯಾವ ಪ್ರತಿರೋಧವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಯಾವ ಮಾರ್ಗ ಮರುಪ್ರಸಾರವನ್ನು ಹೊರುತ್ತದೆ ಎಂದು ಒಪ್ಪಂದ ತಿಳಿಸಬೇಕು.

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

ನಕಲಿಗೆ ತನ್ನದೇ ನಿಯಮ ಬೇಕು. ಒಂದೇ ಪೇಲೋಡ್ ಅನ್ನು ಎರಡೂ ಮಾರ್ಗಗಳಲ್ಲಿ ಕಳುಹಿಸುವುದು ವಿಳಂಬವನ್ನು ಸುಧಾರಿಸಬಹುದು, ಆದರೆ ಸ್ವೀಕರಿಸುವವನು ಪ್ರತಿಯನ್ನು VPN ತಲುಪುವ ಮೊದಲು ಅಡಗಿಸಬೇಕು. IPsec anti-replay ಪ್ರತಿ ಭದ್ರತಾ ಸಂಬಂಧಕ್ಕೂ ಐಚ್ಛಿಕ ಮತ್ತು ಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ; ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮರುಕ್ರಮಗೊಳಿಸುವ ಅಥವಾ ಮರುಪ್ಲೇ ಮಾಡುವ ನಕಲು ಪದರವು ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು ಅಥವಾ ಸುರಂಗ ಬೀಳುವವರೆಗೆ ಸಮಸ್ಯೆಯನ್ನು ಮರೆಮಾಡಬಹುದು.

ಮೂರನೇ ಖಾತರಿ: ಎಂಡ್‌ಪಾಯಿಂಟ್ ಗುರುತು ಮತ್ತು ಮಾರ್ಗ ಸೇರ್ಪಡೆ

ಹೊಸ ಮಾರ್ಗ ಕಾಣಿಸಿಕೊಂಡಾಗ ಸೆಷನ್ ಅನ್ನು ಗುರುತಿಸಲು ಸಹಚರನಿಗೆ ಸ್ಥಿರ ಮಾರ್ಗ ಬೇಕು. ಪ್ರತಿ ಮಾರ್ಗವೂ ಪ್ರತ್ಯೇಕ ಸುರಂಗವಾಗಿ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟರೆ, VPN ಒಂದರ ಬದಲು ಎರಡು ಸೆಷನ್‌ಗಳನ್ನು ನೋಡಬಹುದು. ವಾಹಕವು ಮಾರ್ಗಗಳನ್ನು ಒಂದು ಸೆಷನ್ ಅಡಿಯಲ್ಲಿ ಸೇರಿಸಿದರೆ, ಹೊಸ ಮಾರ್ಗ ಹೇಗೆ ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಹಳೆಯದಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು.

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

ನೀತಿಯೂ ಇಲ್ಲಿಯೇ ವಾಸಿಸುತ್ತದೆ. ಅನಿರೀಕ್ಷಿತ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಸೇರುವ ಮಾರ್ಗ ತಾಂತ್ರಿಕವಾಗಿ ಮಾನ್ಯವಾಗಿದ್ದು ಸಹ ಉದ್ದೇಶಿತ ವಿಶ್ವಾಸ ಮಾದರಿಯನ್ನು ಉಲ್ಲಂಘಿಸಬಹುದು. ಹೊಸ ಮಾರ್ಗಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತವೆಯೇ, ದೃಢೀಕರಣ ಬೇಕೇ ಅಥವಾ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ.

ನಾಲ್ಕನೇ ಖಾತರಿ: ವೈಫಲ್ಯದ ಅಡಿಯಲ್ಲಿ ಸೀಮಿತ ವರ್ತನೆ

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

ಬಫರಿಂಗ್, ಮರುಪ್ರಸಾರ ಮತ್ತು ಮಾರ್ಗಗಳ ಸಂಖ್ಯೆಗೆ ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ, ನಂತರ ಅವನ್ನು ನಷ್ಟ, ಮರುಕ್ರಮ, ನಕಲು ಮತ್ತು ವಿಳಂಬ ಅಸಮತೋಲನದ ಅಡಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಿ. ಒಟ್ಟು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಇಲ್ಲಿ ಅತ್ಯಂತ ಕಡಿಮೆ ಆಸಕ್ತಿದಾಯಕ ಸಂಖ್ಯೆ; ವಿತರಣೆಯ ನಿರಂತರತೆ ಮತ್ತು ಮೆಮೊರಿ ಮಿತಿಗಳೇ ಒಪ್ಪಂದ.

ವಾಹಕದ ಮರುಪ್ರಾಪ್ತಿ ಸ್ಥಿತಿಯನ್ನು VPN ನ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸ್ಥಿತಿಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಸ್ಥಾಪಿತ ದೃಢೀಕರಣ ಅಥವಾ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಅನ್ನು ಬದಲಿಸುವ ಸ್ವಂತ ವಿಶ್ವಾಸಾರ್ಹತೆ ಪದರವು ಶಾರ್ಟ್‌ಕಟ್ ಅಲ್ಲ, ಮತ್ತು ಪದರಗಳ ನಡುವೆ ಕ್ರಮ ಸಂಖ್ಯೆಗಳ ಮರುಬಳಕೆ replay ರಕ್ಷಣೆ ಮತ್ತು ರೋಗನಿರ್ಣಯವನ್ನು ನಂಬಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ.

ವಾಹಕವನ್ನು ಪರೀಕ್ಷಾ ಯೋಜನೆಯೊಂದಿಗೆ ಸ್ವೀಕರಿಸಿ

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

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

ಅನುಮೋದಿತ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ನಿಯೋಜನೆಯೊಂದಿಗೆ ಇರಿಸಿ. ಇದು ಮುಂದಿನ ಎಂಜಿನಿಯರ್‌ಗೆ ಯಾವ ವರ್ತನೆ ಭರವಸೆ ನೀಡಲಾಗಿತ್ತು, ಯಾವ ಮಾರ್ಗ ಸಂಯೋಜನೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವ ವೈಫಲ್ಯ ವಿಧಾನವು ಇನ್ನೂ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ ಎಂದು ಲಿಂಕ್ ಸ್ಥಿತಿ ದೀಪಗಳಿಂದ ಹೊಸ ಊಹೆ ಇಲ್ಲದೆ ತಿಳಿಸುತ್ತದೆ.