webpack ਡੈਵ ਸਰਵਰ ਨੂੰ VPN ਪਤੇ 'ਤੇ ਕਿਵੇਂ ਸੇਵਾ ਕਰਨੀ ਹੈ

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

ਤਿੰਨ ਸਵਾਲ ਜਵਾਬ ਤੈਅ ਕਰਦੇ ਹਨ: ਕੌਣ ਜੁੜਦਾ ਹੈ, ਉਹ ਕਿਹੜੇ ਪਤੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੀ ਉਨ੍ਹਾਂ ਲਈ ਲਾਈਵ ਰੀਲੋਡ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਸੰਰਚਨਾ ਫਾਈਲ ਨਾਲ ਨਹੀਂ, ਸਾਕਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

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

ਰੂਟ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਨਿਰੀਖਣ ਨਾਲ ਮੇਲ ਖਾਓ। ਜੇ ਪ੍ਰਕਿਰਿਆ ਗਲਤ ਪਤੇ 'ਤੇ ਸੁਣ ਰਹੀ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਨੀਤੀ ਰਾਊਟਿੰਗ ਕਲਾਇੰਟ ਨੂੰ ਉੱਥੇ ਨਹੀਂ ਪਹੁੰਚਾ ਸਕੇਗੀ।

ਬਾਈਂਡ ਪਤਾ ਇਸ ਆਧਾਰ 'ਤੇ ਚੁਣੋ ਕਿ ਉਸ ਤੱਕ ਕਿਸ ਨੂੰ ਪਹੁੰਚਣਾ ਹੈ

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

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

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

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

ਉਸ ਟੁਕੜੇ ਵਿੱਚ ਪਤਾ ਉਦਾਹਰਨ ਹੈ ਅਤੇ ਹੋਸਟ ਕੋਲ਼ ਮੌਜੂਦ VPN ਪਤੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਜੇ ਪ੍ਰੋਜੈਕਟ ਸਰਵਰ ਨੂੰ new WebpackDevServer(options, compiler) ਨਾਲ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੀ ਬਜਾਏ ਵਿਕਲਪ ਕੰਸਟ੍ਰਕਟਰ ਆਰਗਿਊਮੈਂਟ ਰਾਹੀਂ ਭੇਜੋ, ਕਿਉਂਕਿ webpack ਸੰਰਚਨਾ ਦੀ ਵੱਖਰੀ devServer ਵਿਸ਼ੇਸ਼ਤਾ ਉਸ ਰਾਹ 'ਤੇ ਨਹੀਂ ਵੇਖੀ ਜਾਂਦੀ। ਸੰਰਚਨਾ ਫਾਈਲ ਅਤੇ Node API ਵਿਚਕਾਰ ਇਹ ਫ਼ਰਕ ਉਨ੍ਹਾਂ ਨੂੰ ਫੜਦਾ ਹੈ ਜੋ ਟੁਕੜਾ ਅਜਿਹੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕਾਪੀ ਕਰਦੇ ਹਨ ਜੋ ਇਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹਦਾ। dev-server ਦਸਤਾਵੇਜ਼ ਦੋ ਲਾਂਚ ਸ਼ੈਲੀਆਂ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ ਅਤੇ ਵਰਤੀ ਜਾ ਰਹੀ ਸੰਸਕਰਣ ਨਾਲ ਜਾਂਚਣ ਲਈ ਹਵਾਲਾ ਹਨ।

ਹੋਸਟਨਾਮ ਜਾਂਚ ਨੂੰ ਉਨ੍ਹਾਂ ਨਾਵਾਂ ਨਾਲ ਮਿਲਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹੋ

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

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

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

ਪੰਨਾ ਅਤੇ ਲਾਈਵ-ਰੀਲੋਡ ਸਾਕਟ ਇਕੱਠੇ ਜਾਂਚੋ

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

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

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

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