Nebula static_host_map: ਉਹ ਪਤਾ ਜੋ ਲਾਈਟਹਾਊਸ ਨਹੀਂ ਦੇ ਸਕਦਾ

ਹਰ ਲਾਈਟਹਾਊਸ ਕਿਸੇ ਹੋਸਟ ਨੂੰ ਹਰ ਦੂਜੇ ਪੀਅਰ ਬਾਰੇ ਦੱਸ ਸਕਦਾ ਹੈ, ਸਿਵਾਏ ਇਸ ਤੋਂ ਕਿ ਲਾਈਟਹਾਊਸ ਖੁਦ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ। ਓਵਰਲੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਜਾਣਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ Nebula ਉਸ ਕੁਝ ਨੂੰ ਇੱਕ ਛੋਟੇ ਨਕਸ਼ੇ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਨਕਸ਼ਾ ਓਵਰਲੇ ਪਛਾਣ ਨੂੰ ਆਮ ਨੈੱਟਵਰਕ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪਤੇ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਸਿੱਖੀ ਹਰ ਚੀਜ਼ ਇਸ ਜੋੜੀ ਦੇ ਸਹੀ ਹੋਣ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਦੋ ਕੰਮਾਂ ਵਾਲੇ ਦੋ ਪਤੇ

ਹਰ Nebula ਹੋਸਟ ਕੋਲ ਓਵਰਲੇ ਪਤਾ ਹੁੰਦਾ ਹੈ ਜੋ ਡਿਵਾਈਸ ਦੇ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਘੁੰਮਣ ਵੇਲੇ ਵੀ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ। ਉਹ ਪਤਾ ਉਹੀ ਪਛਾਣ ਹੈ ਜੋ ਸਰਟੀਫਿਕੇਟ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ਪੀਅਰ ਸੰਬੰਧ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇਕੱਲਾ ਇਹ ਕਿਤੇ ਰੂਟ ਨਹੀਂ ਕਰਦਾ। ਪਹੁੰਚਣ ਯੋਗ ਐਂਡਪੌਇੰਟ ਕੁਝ ਹੋਰ ਹੈ: ਅਧੀਨ ਨੈੱਟਵਰਕ ਉੱਤੇ ਹੋਸਟਨਾਮ ਜਾਂ ਪਤਾ ਅਤੇ ਇੱਕ UDP ਪੋਰਟ, ਅਤੇ ਮਸ਼ੀਨ ਦਾ ਟਿਕਾਣਾ ਬਦਲਣ 'ਤੇ ਇਹ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਸਥਿਰ ਨਕਸ਼ਾ ਦੋਵਾਂ ਵਿਚਕਾਰਲਾ ਜੋੜ ਹੈ।

ਨਕਸ਼ੇ ਵਿੱਚ ਸਿਰਫ਼ ਉਹ ਹੋਸਟ ਆਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਠੰਡਾ ਡਾਇਲ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਲਾਈਟਹਾਊਸ ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਇੱਕ ਰਿਲੇ। ਉਹ ਸੂਚੀ ਛੋਟੀ ਰੱਖਣਾ ਡਿਜ਼ਾਈਨ ਦਾ ਟੀਚਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਹੱਥ ਨਾਲ ਲਿਖੀ ਐਂਟਰੀ ਉਹ ਤੱਥ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਸੰਭਾਲਣਾ ਹੁੰਦਾ ਹੈ। ਦੋਵੇਂ ਪਤਾ ਕਿਸਮਾਂ ਨੂੰ ਰਲਾਉਣਾ ਆਮ ਕਨਫਿਗਰੇਸ਼ਨ ਗਲਤੀ ਹੈ: ਲਾਈਟਹਾਊਸ ਸੂਚੀ ਵਿੱਚ ਰੱਖਿਆ ਜਨਤਕ ਪਤਾ ਖੋਜ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ।

ਪਛਾਣ ਉੱਥੇ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਪਛਾਣ ਦੀ ਉਮੀਦ ਹੁੰਦੀ ਹੈ। ਪਹੁੰਚਯੋਗਤਾ ਨਕਸ਼ੇ ਵਿੱਚ ਜਾਂਦੀ ਹੈ।

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

ਨਕਸ਼ਾ ਐਂਟਰੀ ਦੀ ਬਣਾਵਟ

ਕੁੰਜੀ ਹਵਾਲਾ ਚਿੰਨ੍ਹਾਂ ਵਿੱਚ ਲਿਖਿਆ ਓਵਰਲੇ ਪਤਾ ਹੈ, ਅਤੇ ਮੁੱਲ ਐਂਡਪੌਇੰਟਾਂ ਦੀ ਸੂਚੀ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਪਛਾਣ ਦੇ ਕਈ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਹੋ ਸਕਦੇ ਹਨ। ਹਰ ਐਂਡਪੌਇੰਟ ਵਿੱਚ ਇੱਕ ਹੋਸਟ ਅਤੇ ਇੱਕ ਪੋਰਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪੋਰਟ ਦੂਜੇ ਪਾਸੇ ਦੇ ਅਸਲ ਸੁਣਨ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। Nebula ਦਾ ਡਿਫਾਲਟ UDP 4242 ਹੈ, ਜੋ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ, ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਬਾਰੇ ਵਾਅਦਾ ਨਹੀਂ।

ਇੱਕ ਲਾਈਟਹਾਊਸ ਦੇ ਅੰਦਰ ਆਉਣ ਦੇ ਇੱਕ ਤੋਂ ਵੱਧ ਰਾਹ ਹੋਣ 'ਤੇ ਕਈ ਐਂਡਪੌਇੰਟ ਲਾਭਦਾਇਕ ਹਨ, ਜਿਵੇਂ ਜਨਤਕ ਪਤਾ ਅਤੇ ਉਸੇ ਸੈਗਮੈਂਟ ਦੇ ਹੋਸਟਾਂ ਲਈ ਨਿੱਜੀ ਪਤਾ। ਕਲਾਇੰਟ ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਪਹਿਲਾਂ ਰੱਖੋ। IPv6 ਲਈ ਪੋਰਟ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪਤੇ ਨੂੰ ਵਰਗ ਬਰੈਕਟਾਂ ਵਿੱਚ ਰੱਖੋ; ਗਲਤੀ ਕਰਨ 'ਤੇ ਪਾਰਸ ਗਲਤੀ ਆਉਂਦੀ ਹੈ ਜੋ ਗਲਤ ਲਾਈਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।

ਗਲਤ ਪੋਰਟ ਗਲਤੀ ਦੀ ਥਾਂ ਚੁੱਪੀ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ UDP ਕੋਲ ਇਨਕਾਰ ਕਰਨ ਲਈ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ। ਇਸ ਲਈ ਐਂਟਰੀ ਦਾ ਰੂਪ Nebula static_host_map ਹਵਾਲੇ ਨਾਲ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਯਾਦ ਨਾਲ ਨਹੀਂ। ਹਵਾਲਾ ਐਂਡਪੌਇੰਟ ਸੂਚੀਆਂ ਅਤੇ DNS ਰਿਫ੍ਰੈਸ਼ ਵਿਹਾਰ ਵੀ ਕਵਰ ਕਰਦਾ ਹੈ।

ਓਵਰਲੇ ਤੋਂ ਪਹਿਲਾਂ ਬੂਟਸਟ੍ਰੈਪ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਨਕਸ਼ੇ ਵਿੱਚਲਾ DNS ਨਾਮ ਕਿਸੇ ਵੀ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਹੋਸਟ ਕੋਲ ਮੌਜੂਦ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ ਆਮ ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ। ਇਹ ਉਸੇ ਮਸ਼ੀਨ ਤੋਂ, ਬੂਟ ਵੇਲੇ, ਓਵਰਲੇ ਬੰਦ ਰੱਖ ਕੇ ਜਾਂਚੋ। ਜੋ ਨਾਮ ਸਿਰਫ਼ ਓਵਰਲੇ ਦੇ ਆਪਣੇ DNS ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਉਹ ਓਵਰਲੇ ਨੂੰ ਬੂਟਸਟ੍ਰੈਪ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਹੀ ਪਰਖ ਰਸਤੇ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ: ਜੋ ਫਾਇਰਵਾਲ ਨਿਯਮ ਓਵਰਲੇ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਪਰ ਪਹਿਲੇ UDP ਵਟਾਂਦਰੇ ਦੀ ਨਹੀਂ, ਉਹ ਸ਼ੁਰੂਆਤੀ ਪੈਕਟ ਰੋਕਦਾ ਹੈ।

ਪੋਰਟ ਨੂੰ ਖੁੱਲ੍ਹਾ ਮੰਨਣ ਦੀ ਥਾਂ UDP ਸੰਦ ਨਾਲ ਜਾਂਚੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਸਤੇ 'ਤੇ ਕੋਈ ਵੀ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਸਹੀ ਅੰਦਰੂਨੀ ਹੋਸਟ ਵੱਲ ਹੈ ਅਤੇ ਵਾਪਸੀ ਰਸਤਾ ਮੌਜੂਦ ਹੈ। ਜੇ ਹੋਸਟਨਾਮ ਕਈ ਪਤਿਆਂ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹਰ ਇੱਕ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਅਜਿਹਾ ਪਤਾ ਚੁਣ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਜਾਂਚਿਆ।

ਸਥਿਰ ਐਂਟਰੀਆਂ ਸਿੱਧੀਆਂ ਡਾਇਲ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਕਦੇ ਲਾਈਟਹਾਊਸ ਨਹੀਂ ਪੁੱਛਦੀਆਂ। ਇਸ ਲਈ ਇੱਥੇ ਅਸਫਲਤਾ ਕਿਸੇ ਪੀਅਰ ਤੋਂ ਬਿਨਾਂ ਆਮ ਟਾਈਮਆਊਟ ਵਰਗੀ ਲੱਗਦੀ ਹੈ।

ਪਹਿਲੇ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ

ਹੋਸਟ ਦੇ ਲਾਈਟਹਾਊਸ ਤੱਕ ਪਹੁੰਚਦਿਆਂ ਹੀ ਉਹ ਹੋਰ ਹੱਥ ਨਾਲ ਲਿਖੀਆਂ ਐਂਟਰੀਆਂ ਤੋਂ ਬਿਨਾਂ ਪੀਅਰਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਪਹੁੰਚਣ ਯੋਗ ਪਤਿਆਂ ਬਾਰੇ ਜਾਣਦਾ ਹੈ। ਪਿਛਲੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਸਰਕੇ ਹੋਸਟ ਉਸ ਚੈਨਲ ਰਾਹੀਂ ਖੋਜਣ ਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ। ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਨਕਸ਼ਾ ਛੋਟਾ ਰੱਖਣ ਦਾ ਇਹੀ ਇਨਾਮ ਹੈ।

ਹੋਸਟ ਆਪਣੇ ਵਾਧੂ ਪਹੁੰਚਣ ਯੋਗ ਪਤੇ ਵੀ ਘੋਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਜਾਣੇ-ਪਛਾਣੇ ਜਨਤਕ ਪਤੇ ਪਿੱਛੇ ਦਾ ਪੀਅਰ ਦੂਜਿਆਂ ਨੂੰ ਇਸਨੂੰ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਉਹ ਘੋਸ਼ਣਾਵਾਂ ਸਿੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਸਥਿਰ ਨਕਸ਼ੇ ਵਿੱਚ ਲਿਖੀਆਂ ਨਹੀਂ ਜਾਂਦੀਆਂ।

DNS ਨਾਮਾਂ ਵਜੋਂ ਲਿਖੇ ਐਂਡਪੌਇੰਟਾਂ ਲਈ ਰਿਫ੍ਰੈਸ਼ ਵਿਹਾਰ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ ਚੱਲਦੇ ਰਹਿਣ ਵੇਲੇ ਹੱਲ ਹੋਇਆ ਪਤਾ ਬਦਲ ਸਕਦਾ ਹੈ। Nebula ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਲੁੱਕਅਪ ਕਿਵੇਂ ਹੁੰਦੇ ਹਨ, ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਸਮੇਤ, ਇਸ ਲਈ ਸਿਸਟਮ ਡਿਫਾਲਟ ਮੰਨਣ ਦੀ ਥਾਂ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹੋ। ਜਿਸ ਹੋਸਟ ਦਾ ਰਿਜ਼ੋਲਵਰ ਟਨਲ ਚੜ੍ਹਨ 'ਤੇ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਉੱਥੇ ਗਲਤ ਸੈਟਿੰਗ ਚੱਲ ਰਹੇ ਬੂਟਸਟ੍ਰੈਪ ਨੂੰ ਸੈਸ਼ਨ ਵਿਚਕਾਰ ਹੱਲ ਹੋਣਾ ਬੰਦ ਕਰਨ ਵਾਲੇ ਨਾਮ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। ਲੁੱਕਅਪ ਨੂੰ ਸਥਿਰ ਰਿਜ਼ੋਲਵਰ ਨਾਲ ਬੰਨ੍ਹਣਾ ਅਕਸਰ ਭਰੋਸੇਯੋਗ ਓਵਰਲੇ ਅਤੇ ਵਿਚਕਾਰ-ਵਿਚਕਾਰ ਰੁਕਣ ਵਾਲੇ ਓਵਰਲੇ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੁੰਦਾ ਹੈ।

ਜਦੋਂ ਖੋਜ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਇੱਕ ਪੀਅਰ ਨਹੀਂ

ਜੇ ਲਾਈਟਹਾਊਸ ਪਹੁੰਚਣ ਯੋਗ ਹਨ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪੀਅਰ ਜੁੜਦੇ ਹਨ, ਤਾਂ ਬੂਟਸਟ੍ਰੈਪ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਬਚੀ ਜੋੜੀ ਜਾਂ ਤਾਂ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਵਰਤੋਂਯੋਗ ਰਾਹ ਨਹੀਂ ਲੱਭਦੀ ਜਾਂ ਪਹੁੰਚਯੋਗਤਾ ਤੋਂ ਉੱਪਰ ਅਸਫਲ ਹੁੰਦੀ ਹੈ। ਲਾਈਟਹਾਊਸ ਪਤੇ ਦੀ ਇੱਕ ਹੋਰ ਸਪੈਲਿੰਗ ਜੋੜਨ ਨਾਲ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਹਾਲਤ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ।

ਜਿਸ ਨਕਸ਼ੇ 'ਤੇ ਬਾਕੀ ਸਭ ਪਹਿਲਾਂ ਹੀ ਟਿਕਿਆ ਹੈ, ਉਸਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜੀ ਜਾਂਚੋ। ਨਕਸ਼ਾ ਬਦਲਣਾ ਹਰ ਹੋਸਟ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਸਭ ਤੋਂ ਆਖਰੀ ਛੂਹਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ, ਪਹਿਲੀ ਨਹੀਂ।

ਇੱਕੋ ਅਥਾਰਟੀ ਦੇ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਰੱਦ ਕੀਤਾ ਹੈਂਡਸ਼ੇਕ ਦੂਰੋਂ ਪਹੁੰਚ ਨਾ ਹੋਣ ਵਾਲੇ ਪੀਅਰ ਵਰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਫਿਰ ਜਾਂਚੋ ਕਿ ਜੋੜੀ ਸਿੱਧਾ ਰਾਹ ਬਣਾ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਸਿੱਧੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲੇ ਨੈੱਟਵਰਕਾਂ ਲਈ ਰਿਲੇ ਕਨਫਿਗਰ ਹੈ ਜਾਂ ਨਹੀਂ। ਰਿਲੇ ਇੱਕ ਹੌਪ ਅਤੇ ਇੱਕ ਨਿਰਭਰਤਾ ਜੋੜਦਾ ਹੈ, ਪਰ ਇਹ ਸਮਰਥਿਤ ਜਵਾਬ ਹੈ, ਅਤੇ ਪੀਅਰ ਦਾ ਰਾਹ ਸੁਧਾਰਨਾ ਖੋਜ ਸੁਧਾਰਨ ਨਾਲੋਂ ਵੱਖਰਾ ਕੰਮ ਹੈ।