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

ਰੂਟ ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹਦਾ

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

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

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

ਜਦੋਂ ਮੰਜ਼ਿਲ ਸੱਚਮੁੱਚ ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਹੁੰਦੀ ਹੈ

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

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

ਜਦੋਂ ਕੰਮ ਦੀ ਇਕਾਈ ਹੋਸਟਨਾਮ ਹੁੰਦੀ ਹੈ

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

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

ਪ੍ਰੌਕਸੀ ਵਿਕਲਪ ਕੀ ਕਵਰ ਨਹੀਂ ਕਰਦਾ

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

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

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

ਦੋਵੇਂ ਰਾਹਾਂ ਦੀ ਜਾਂਚ, ਸਿਰਫ਼ ਖੁਸ਼ਹਾਲ ਵਾਲੇ ਦੀ ਨਹੀਂ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ