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

ಮೊದಲು ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ನಿಂದ ವೈಫಲ್ಯವನ್ನು ಓದಿ

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

ನಂತರ ಹೆಸರು ಪರಿಹಾರವನ್ನು ತಲುಪುವಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ, ಏಕೆಂದರೆ ಬ್ರೌಸರ್ ಎರಡನ್ನೂ ಒಂದೇ ಸಮಯ ಮುಗಿಯುವಿಕೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. NetBird ಕ್ಲೈಂಟ್ ಚಲಿಸುವ ಯಂತ್ರದಿಂದ, ನಂತರ ಚಲಿಸದ ಸಾಮಾನ್ಯ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ನಿಂದ ವಿಳಾಸದ ಮೂಲಕ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ನೋಂದಾಯಿತ ಯಂತ್ರ ಯಶಸ್ವಿಯಾಗಿ ಸಾಮಾನ್ಯ ಯಂತ್ರ ವಿಫಲವಾದರೆ ಅಂತರ ಸ್ಥಳೀಯ ರೂಟಿಂಗ್‌ನಲ್ಲಿದೆ; ಎರಡೂ ವಿಫಲವಾದರೆ ರೂಟ್ ಬದಲಿಸುವ ಮೊದಲು ಓದುವುದನ್ನು ಮುಂದುವರಿಸಿ.

ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಂದು ರೂಟಿಂಗ್ ಪೀರ್ ಆಯ್ಕೆಮಾಡಿ

ರೂಟಿಂಗ್ ಪೀರ್ ಎಂದರೆ ಓವರ್‌ಲೇನಲ್ಲಿ ತನ್ನ LAN ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಹೋಸ್ಟ್, ಆದ್ದರಿಂದ ಯಾರೋ ಒಬ್ಬರ ಡೆಸ್ಕ್ ವರ್ಕ್‌ಸ್ಟೇಷನ್ ಬದಲು ಸಬ್‌ನೆಟ್‌ಗೆ ಸ್ಥಿರ ತಲುಪುವಿಕೆ ಇರುವ Linux ಯಂತ್ರವನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಅದನ್ನು ಸಾಮಾನ್ಯ ಪ್ರಕ್ರಿಯೆಯಿಂದ ನೋಂದಾಯಿಸಿ ಪಾತ್ರದ ಹೆಸರಿನ ಗುಂಪಿನಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ನೆಟ್‌ವರ್ಕ್ ಸಂಪನ್ಮೂಲ ಮತ್ತು ನೀತಿ ಎರಡೂ ಆ ಗುಂಪನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ. ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಬ್ಬ ಪ್ರತಿನಿಧಿ ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ; ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸುವ ಸ್ವಯಂಸೇವಕರ ಗುಂಪು ಪ್ರತಿ ಮುಂದಿನ ಪ್ರಶ್ನೆಯನ್ನೂ ಡೀಬಗ್ ಅವಧಿಯಾಗಿ ಬದಲಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ವಿಭಾಗದಲ್ಲಿ ಪೀರ್‌ನ ವಿಳಾಸ ಅದರ ಓವರ್‌ಲೇ ಗುರುತಿನಷ್ಟೇ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಆ ವಿಳಾಸ ಪ್ರತಿ ಸಾಮಾನ್ಯ ಸಾಧನಕ್ಕೂ ಹೇಳುವ ಮುಂದಿನ ಹಾಪ್ ಆಗುತ್ತದೆ.

ಕನ್ಸೋಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಯೋಜನೆ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಹೆಸರುಗಳು ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್‌ಗಳೇ ಈ ವಿನ್ಯಾಸಗಳು ಜಾರುವ ಸ್ಥಳ: ಪ್ರಿಫಿಕ್ಸ್, ಗೇಟ್‌ವೇ, ಪೀರ್ ವಿಳಾಸ ಮತ್ತು ಗುಂಪು, ಪ್ರತಿ ಸೈಟ್‌ಗೆ. ಪಶ್ಚಿಮ 10.52.0.0/24, ಅದಕ್ಕೆ 10.52.0.5 ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ, ಪೂರ್ವ 10.63.0.0/24, ಅದಕ್ಕೆ 10.63.0.5 ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ; ಎರಡು ಗುಂಪುಗಳು west-routers ಮತ್ತು east-routers, ಮತ್ತು ಯಾವುದೇ ಪ್ರಿಫಿಕ್ಸ್ ಇನ್ನೊಂದರೊಂದಿಗೆ, ಓವರ್‌ಲೇ ಶ್ರೇಣಿಯೊಂದಿಗೆ ಅಥವಾ ಬೇರೆ ರೂಟ್ ಆದ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸಬಾರದು.

ಸಂಪನ್ಮೂಲ ರಚಿಸಿ, ಮಾಸ್ಕರೇಡಿಂಗ್ ಆನ್ ಇರಿಸಿ

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

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

ಪ್ರಾರಂಭಿಸುವವರಿಗೆ ಅಧಿಕಾರ ನೀಡಿ, ಪ್ರಿಫಿಕ್ಸ್‌ಗಳಿಗೆ ಅಲ್ಲ

ರೂಟ್ ವಿಳಾಸವನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುತ್ತದೆ, ನೀತಿ ಯಾರು ಅದನ್ನು ಬಳಸಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ಇವು ಪ್ರತ್ಯೇಕ ಮಾಲೀಕರ ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳು. ನೀತಿಯನ್ನು ಕೆಲಸದ ಹೊರೆಯಿಂದ ಹಿಂದಕ್ಕೆ ಬರೆಯಿರಿ: ಯಾವ ಗುಂಪು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಯಾವ ಸಂಪನ್ಮೂಲವನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ TCP ಸೇವೆ ಬೇಕು. ಪ್ರತಿ ನೋಂದಾಯಿತ ಪೀರ್‌ಗೂ ಎರಡೂ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಘೋಷಿಸುವ ನೆಟ್‌ವರ್ಕ್ ತಲುಪುವಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸಿ ಏನನ್ನೂ ನಿರ್ಣಯಿಸಿಲ್ಲ.

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

ಪ್ರತಿ ಗೇಟ್‌ವೇಗೆ ಮುಂದಿನ ಹಾಪ್ ಕಲಿಸಿ, ನಂತರ ನಿರಾಕರಣೆ ಪರೀಕ್ಷಿಸಿ

ಸಾಮಾನ್ಯ ಸಾಧನಗಳು ಓವರ್‌ಲೇವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವುಗಳ ಗೇಟ್‌ವೇಗೆ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ರೂಟಿಂಗ್ ಪೀರ್‌ನ LAN ವಿಳಾಸದತ್ತ ತೋರಿಸುವ ಸ್ಥಿರ ರೂಟ್ ಬೇಕು. ಇದೇ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಹಂತ, ಏಕೆಂದರೆ NetBird ಒಳಗೆ ಕಾಣುವ ಎಲ್ಲವೂ ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಸಾಮಾನ್ಯ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ಗಳು ಇನ್ನೂ ಸಮಯ ಮುಗಿಸುತ್ತಿರುವಾಗ. ಗೇಟ್‌ವೇ ತನ್ನ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಇದ್ದಂತೆ ಇರಿಸುತ್ತದೆ; ಈ ಪ್ರಿಫಿಕ್ಸ್ ಸೇರ್ಪಡೆ, ಬದಲಿ ಅಲ್ಲ.

ಎರಡು ರೂಟ್ ವಿವರಣೆಗಳು ಪ್ರತಿ ಸೈಟ್‌ನ ಸ್ವಂತ ಗೇಟ್‌ವೇ ಸಂರಚನೆಗೆ ಸೇರಿದವು, ಹೋಸ್ಟ್‌ನಲ್ಲಿನ ಮೇಲಿಬರಹಕ್ಕಲ್ಲ. ಎರಡೂ ಸಾಮಾನ್ಯ ಸ್ಥಿರ ರೂಟ್‌ಗಳು, ಮತ್ತು ಯಾವುದೂ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಮುಟ್ಟುವುದಿಲ್ಲ:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

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

TestA pass looks likeA failure points at
Ordinary workstation opens the east applicationNext hop on west is the routing peerMissing static route on the west gateway
A source outside policy is refusedNo session in the service logPolicy too broad, or a route bypasses it
East starts a connection, if requiredA fresh reverse session succeedsNo policy for the reverse direction

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

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