Nebula ರಿಲೇ ಕಾನ್ಫಿಗರ್ ಆಗಿದೆ ಆದರೆ ಬಳಕೆಯಾಗುತ್ತಿಲ್ಲ: ಪರಿಶೀಲಿಸಬೇಕಾದ ಮೂರು ಸೆಟ್ಟಿಂಗ್‌ಗಳು

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

ಕಾನ್ಫಿಗ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮೂರು ಪಾತ್ರಗಳ ನಕ್ಷೆ ಮಾಡಿ

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

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

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

ಮಿಶ್ರ ಫ್ಲೀಟ್‌ನಲ್ಲಿ ಆವೃತ್ತಿ ಸಾಲು ಮುಖ್ಯ. ರಿಲೇ ನಿರ್ವಹಣೆ, ಪಂಚಿಂಗ್ ವರ್ತನೆ ಮತ್ತು ಸ್ವೀಕೃತ ಕಾನ್ಫಿಗ್ ಕೀಗಳು ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಒಂದೇ ರೀತಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಹಳೆಯ ಬಿಲ್ಡ್ ತನಗೆ ಬರೆಯದ ವಿಭಾಗವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ. ಹೋಸ್ಟ್‌ಗಳನ್ನು ಒಂದೇ ಮೈನರ್ ಸರಣಿಗೆ ತನ್ನಿ, ನಂತರ ಪ್ರತಿ ಹೋಸ್ಟ್‌ನಲ್ಲಿ nebula -test -config /etc/nebula/config.yml ಚಲಾಯಿಸಿ ಮತ್ತು ಕೋಡ್ ಜಾರಿಗೊಳಿಸದ ಸಾರಿಗೆಯನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಔಟ್‌ಪುಟ್ ಹೋಲಿಸಿ.

ರಿಲೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಪಾತ್ರ ಸಕ್ರಿಯಗೊಳಿಸಿ

ರಿಲೇ ಪಾತ್ರ ಫಾರ್ವರ್ಡಿಂಗ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಒಂದು ಫ್ಲ್ಯಾಗ್, ಮತ್ತು ಅದು ಲೈಟ್‌ಹೌಸ್ ಆಗಿರುವುದಕ್ಕಿಂತ ಪ್ರತ್ಯೇಕ. ಅನ್ವೇಷಣೆ ಸಕ್ರಿಯವಾಗಿದ್ದು ರಿಲೇ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವ ಹೋಸ್ಟ್ ಇನ್ನೂ ಕೇವಲ ಅನ್ವೇಷಣಾ ಸೇವೆ. ರಿಲೇಯಲ್ಲಿ:

relay:
  am_relay: true

ಈ ಫ್ಲ್ಯಾಗ್ ಉದ್ದೇಶವನ್ನು ಘೋಷಿಸುತ್ತದೆ; ಅದು ತಲುಪುವಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ರಿಲೇ ಎರಡೂ ಪೀರ್‌ಗಳಿಂದ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು, ಇದರ ಅರ್ಥ ವಾಸ್ತವವಾಗಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ, ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಮತ್ತು ಯಾವುದೇ ಕ್ಲೌಡ್ ಭದ್ರತಾ ಗುಂಪಿನಲ್ಲಿ Nebula ಪೋರ್ಟ್‌ನಲ್ಲಿ ತೆರೆದ ಒಳಬರುವ UDP, ಮತ್ತು ಅದರ ಮುಂದೆ ದ್ವಿಗುಣ NAT ಇಲ್ಲದಿರುವುದು. ಕೇಳುವ ಸಾಕೆಟ್ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಪೀರ್‌ನ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬರುವುದನ್ನು ಗಮನಿಸಿ:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

ರಿಲೇಯನ್ನು ಕ್ಲೈಂಟ್‌ನಿಂದ ಅಲ್ಲ, ಗಮ್ಯಸ್ಥಾನದಿಂದ ಪ್ರಕಟಿಸಿ

ಇದೇ ಹೆಚ್ಚು ಗಂಟೆಗಳನ್ನು ತಿನ್ನುವ ವ್ಯತ್ಯಯ. ರಿಲೇ ಪಟ್ಟಿ ನೀವು ತಲುಪಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿರಬೇಕು, ಏಕೆಂದರೆ ಅದು ಆ ಹೋಸ್ಟ್‌ಗೆ ತಲುಪಲು ಯಾವ ರಿಲೇಗಳನ್ನು ಬಳಸಬಹುದೆಂದು ಇತರ ಪೀರ್‌ಗಳಿಗೆ ಹೇಳುತ್ತದೆ. ಸಂಪರ್ಕ ಪ್ರಾರಂಭಿಸುವ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಅದನ್ನು ಇಡುವುದು ಕ್ಲೈಂಟ್‌ಗೆ ಬೇಕಾದ ದಿಕ್ಕಿಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

ಸಂಪರ್ಕಿಸುವ ಪೀರ್ ರಿಲೇ ಬಳಸಲು ಅನುಮತಿಸಿ

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

relay:
  use_relays: true

ಈ ಬದಿಯ ಅನುಮತಿ ಏಕೈಕ ದ್ವಾರವಲ್ಲ. ಗಮ್ಯಸ್ಥಾನದ ಒಳಬರುವ ನಿಯಮಗಳು ರಿಲೇ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್‌ಗೆ ಇನ್ನೂ ಅನ್ವಯವಾಗುತ್ತವೆ, ಮತ್ತು ಅವು ಹೊಂದಿಸುವ ಮೂಲವು ಸುರಂಗದ ಒಳಗಿನ ಗುರುತು, ರಿಲೇಯ ಸ್ವಂತ ವಿಳಾಸವಲ್ಲ. ರಿಲೇ ಮಾಡಿದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಂಡರೂ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾದರೆ, ನಿಯಮವನ್ನು ಮರುಬರೆಯುವ ಮೊದಲು ಗಮ್ಯಸ್ಥಾನದ ಲಾಗ್‌ನಲ್ಲಿ ದಾಖಲಾದ ಮೂಲವನ್ನು ಓದಿ.

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

ವಿಫಲವಾದ ಜೋಡಿಯೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮರುಲೋಡ್ ಮಾಡಿ

ವಾಸ್ತವವಾಗಿ ವಿಫಲವಾದ ಎರಡು ಹೋಸ್ಟ್‌ಗಳನ್ನು ಅವುಗಳಿಗೆ ಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ನಿಮ್ಮ ವರ್ಕ್‌ಸ್ಟೇಶನ್‌ನಿಂದ ರಿಲೇಯ ಸ್ವಂತ ಸೇವೆಗೆ ಯಶಸ್ವಿ ping ಇತರ ಎರಡು ಪೀರ್‌ಗಳ ನಡುವಿನ ಫಾರ್ವರ್ಡಿಂಗ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಇದು ಈ ಇಡೀ ಕಾರ್ಯವಿಧಾನದಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು ಧನಾತ್ಮಕ.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

ಮರುಪ್ರಾರಂಭಿಸುವ ಬದಲು ಮರುಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆ ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್ ತೆಗೆದುಕೊಂಡಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಮರುಪ್ರಾರಂಭ ಪ್ರತಿ ಸುರಂಗವನ್ನೂ ಒಡೆಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪರೀಕ್ಷೆಯನ್ನು ಓದಲು ಕಷ್ಟವಾಗಿಸುತ್ತದೆ, ಆದರೆ SIGHUP ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉಳಿಸಿ ಕಾನ್ಫಿಗ್ ಮತ್ತೆ ಓದುವಂತೆ ಮಾಡುತ್ತದೆ:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload ಸ್ಥಳೀಯ ಯೂನಿಟ್ ExecReload ವ್ಯಾಖ್ಯಾನಿಸಿದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಯೋಜನೆಯೊಂದಿಗೆ ಬರುವ ಯೂನಿಟ್ ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸ್ಟಾಕ್ ಸ್ಥಾಪನೆಯಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುವ ಹಂತ systemctl kill -s HUP. ಮರುಲೋಡ್ ನಂತರ ಪ್ರಕ್ರಿಯೆ ತೆರೆದ ಕಾನ್ಫಿಗ್ ಮಾರ್ಗಕ್ಕಾಗಿ ಜರ್ನಲ್ ಓದಿ, ಹೊಸ ಫೈಲ್ ಓದಲಾಗಿದೆ ಎಂದು ತಿಳಿಯಲು, ನೀವು ಊಹಿಸಿದ ಫೈಲ್ ಅಲ್ಲ.

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

ನಂತರ ಪ್ರತಿ ಹೇಳಿಕೆ ತನ್ನದೇ ಫೈಲ್‌ನಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ:

• ಫಾರ್ವರ್ಡಿಂಗ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ am_relay: true, ಮತ್ತು ಆ ಹೋಸ್ಟ್ ಎರಡೂ ಬದಿಗಳಿಂದ UDP ನಲ್ಲಿ ತಲುಪಬಲ್ಲದು.
• ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಆ ಹೋಸ್ಟ್‌ನ Nebula ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವ relays:.
• ಸಂಪರ್ಕ ಪ್ರಾರಂಭಿಸುವ ಪೀರ್‌ನಲ್ಲಿ use_relays: true.
• ಮಾರ್ಗ ಬದಲಾದ ನಂತರವೂ ಗಮ್ಯಸ್ಥಾನದ ಒಳಬರುವ ನಿಯಮಗಳು ನಿಜವಾದ ಮೂಲಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತವೆ.