Nebula static_host_map: ಲೈಟ್‌ಹೌಸ್ ನೀಡಲಾಗದ ವಿಳಾಸ

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

ಎರಡು ಕೆಲಸಗಳ ಎರಡು ವಿಳಾಸಗಳು

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

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

ಗುರುತು ಗುರುತು ನಿರೀಕ್ಷಿಸುವಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ. ತಲುಪುವಿಕೆ ನಕ್ಷೆಗೆ ಹೋಗುತ್ತದೆ.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

ನಕ್ಷೆ ನಮೂದಿನ ರಚನೆ

ಕೀಲಿಯು ಉಲ್ಲೇಖ ಚಿಹ್ನೆಗಳಲ್ಲಿ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಬರೆದ overlay ವಿಳಾಸ, ಮತ್ತು ಮೌಲ್ಯವು ಎಂಡ್ಪಾಯಿಂಟ್ಗಳ ಪಟ್ಟಿ, ಹಾಗಾಗಿ ಒಂದು ಗುರುತಿಗೆ ಹಲವು ಪ್ರವೇಶ ಬಿಂದುಗಳಿರಬಹುದು. ಪ್ರತಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಒಂದು ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ ಹೊಂದಿದೆ, ಮತ್ತು ಪೋರ್ಟ್ ಇನ್ನೊಂದು ಬದಿ ನಿಜವಾಗಿ ಕೇಳುವುದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. Nebula ನ ಡೀಫಾಲ್ಟ್ UDP 4242, ಇದು ಆರಂಭಿಕ ಬಿಂದು, ನಿಮ್ಮ ನಿಯೋಜನೆಯ ಬಗ್ಗೆ ಭರವಸೆ ಅಲ್ಲ.

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

ತಪ್ಪು ಪೋರ್ಟ್ ದೋಷದ ಬದಲು ಮೌನವನ್ನು ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ UDP ಗೆ ನಿರಾಕರಿಸುವ ಹ್ಯಾಂಡ್ಶೇಕ್ ಇಲ್ಲ. ಆದ್ದರಿಂದ ನಮೂದಿನ ಸ್ವರೂಪವನ್ನು Nebula static_host_map ಉಲ್ಲೇಖ ಜೊತೆ ಪರಿಶೀಲಿಸುವುದು ಒಳ್ಳೆಯದು, ನೆನಪಿನೊಂದಿಗೆ ಅಲ್ಲ. ಉಲ್ಲೇಖವು ಎಂಡ್ಪಾಯಿಂಟ್ ಪಟ್ಟಿಗಳು ಮತ್ತು DNS ರಿಫ್ರೆಶ್ ನಡವಳಿಕೆಯನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ.

overlay ಮೊದಲು ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಕೆಲಸ ಮಾಡಬೇಕು

ನಕ್ಷೆಯಲ್ಲಿನ DNS ಹೆಸರು ಯಾವುದೇ ಟನೆಲ್ ಇರುವ ಮೊದಲು ಹೋಸ್ಟ್ಗೆ ಇರುವ ರೆಸಾಲ್ವರ್ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡಬೇಕು, ಅಂದರೆ ಸಾಮಾನ್ಯ ಸಿಸ್ಟಂ ರೆಸಾಲ್ವರ್. ಅದೇ ಯಂತ್ರದಿಂದ, ಬೂಟ್ ಸಮಯದಲ್ಲಿ, overlay ನಿಲ್ಲಿಸಿ ಪರೀಕ್ಷಿಸಿ. overlay ನ ಸ್ವಂತ DNS ಮೂಲಕ ಮಾತ್ರ ಪರಿಹರಿಸುವ ಹೆಸರು overlay ಅನ್ನು ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಮಾಡಲಾರದು. ಅದೇ ಪರೀಕ್ಷೆ ಮಾರ್ಗಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ: overlay ಗೆ ಅನುಮತಿ ನೀಡಿ ಮೊದಲ UDP ವಿನಿಮಯಕ್ಕೆ ನೀಡದ ಫೈರ್ವಾಲ್ ನಿಯಮವು ಆರಂಭಿಕ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ.

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

ಸ್ಥಿರ ನಮೂದುಗಳು ನೇರವಾಗಿ ಡಯಲ್ ಆಗುತ್ತವೆ ಮತ್ತು ಎಂದೂ ಲೈಟ್ಹೌಸ್ ಅನ್ನು ಕೇಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಇಲ್ಲಿ ವೈಫಲ್ಯವು ಯಾವುದೇ ಪೀರ್ ಇಲ್ಲದ ಸಾಮಾನ್ಯ ಟೈಮೌಟ್ನಂತೆ ಕಾಣುತ್ತದೆ.

ಮೊದಲ ಹ್ಯಾಂಡ್ಶೇಕ್ ನಂತರ ಏನಾಗುತ್ತದೆ

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

ಹೋಸ್ಟ್ಗಳು ತಮ್ಮ ಹೆಚ್ಚುವರಿ ತಲುಪಬಹುದಾದ ವಿಳಾಸಗಳನ್ನೂ ಘೋಷಿಸಬಹುದು, ಮತ್ತು ಹಾಗೆ ತಿಳಿದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಹಿಂದಿನ ಪೀರ್ ಇತರರಿಗೆ ಅದನ್ನು ಹುಡುಕಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆ ಘೋಷಣೆಗಳು ಕಲಿಯಲ್ಪಡುತ್ತವೆ, ಸ್ಥಿರ ನಕ್ಷೆಯಲ್ಲಿ ಬರೆಯಲ್ಪಡುವುದಿಲ್ಲ.

DNS ಹೆಸರುಗಳಾಗಿ ಬರೆದ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳಿಗೆ ರಿಫ್ರೆಶ್ ನಡವಳಿಕೆ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಪ್ರಕ್ರಿಯೆ ಮುಂದುವರಿಯುತ್ತಿರುವಾಗ ಪರಿಹರಿಸಿದ ವಿಳಾಸ ಬದಲಾಗಬಹುದು. Nebula ನ ಸೆಟ್ಟಿಂಗ್ಗಳು ಆ ಹುಡುಕಾಟಗಳು ಹೇಗೆ ನಡೆಯುತ್ತವೆ, ಯಾವ ರೆಸಾಲ್ವರ್ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನೂ ನಿಯಂತ್ರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಿಸ್ಟಂ ಡೀಫಾಲ್ಟ್ ಎಂದು ಊಹಿಸುವ ಬದಲು ಅವುಗಳನ್ನು ಓದಿ. ಟನೆಲ್ ಮೇಲೆ ಬಂದಾಗ ರೆಸಾಲ್ವರ್ ಬದಲಾಗುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, ತಪ್ಪು ಸೆಟ್ಟಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಅನ್ನು ಅಧಿವೇಶನದ ಮಧ್ಯದಲ್ಲಿ ಪರಿಹರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಹೆಸರಾಗಿ ಬದಲಿಸಬಹುದು. ಹುಡುಕಾಟವನ್ನು ಸ್ಥಿರ ರೆಸಾಲ್ವರ್ಗೆ ಪಿನ್ ಮಾಡುವುದು ಹಲವುವೇಳೆ ವಿಶ್ವಾಸಾರ್ಹ overlay ಮತ್ತು ಮಧ್ಯೆ ಮಧ್ಯೆ ನಿಲ್ಲುವ overlay ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

ಅನ್ವೇಷಣೆ ಕೆಲಸ ಮಾಡಿ ಒಂದು ಪೀರ್ ಮಾಡದಿದ್ದಾಗ

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

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

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