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।
• ਮਾਰਗ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਮੰਜ਼ਿਲ ਦੇ ਇਨਬਾਊਂਡ ਨਿਯਮ ਅਸਲ ਸਰੋਤ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।