ਡੋਮੇਨ-ਅਧਾਰਿਤ VPN ਰੂਟਿੰਗ ਬਨਾਮ IP ਰੂਟ: ਕਿਹੜਾ ਢੁਕਵਾਂ ਹੈ?
ਸਪਲਿਟ-ਟਨਲ ਬਾਕਸ ਵਿੱਚ ਹੋਸਟਨਾਮ ਰੂਟ ਨਹੀਂ ਹੁੰਦਾ। ਰਿਫ੍ਰੈਸ਼, ਸਬਡੋਮੇਨ ਦਾਇਰਾ ਅਤੇ DNS ਬਦਲਣ ਵੇਲੇ ਕੀ ਹੁੰਦਾ ਹੈ ਦੇ ਆਧਾਰ 'ਤੇ ਡੋਮੇਨ ਨਿਯਮਾਂ ਅਤੇ ਸਪਸ਼ਟ ਪ੍ਰੀਫਿਕਸ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਇੱਕ IP ਰੂਟ ਐਡਰੈਸ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਕਰਨਲ ਹੋਰ ਸਵਾਲ ਪੁੱਛੇ ਬਿਨਾਂ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਡੋਮੇਨ-ਅਧਾਰਿਤ VPN ਨਿਯਮ ਇੱਕ ਨਾਮ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਟੈਕ ਵਿੱਚ ਕੁਝ ਚੀਜ਼ ਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਹ ਨਾਮ ਹੁਣ ਕਿਹੜੇ ਐਡਰੈਸ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਉਹ ਫੈਸਲਾ ਅਦਿਅਤ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਇਹ ਵੱਖਰੇ ਫੇਲ ਹੋਣ ਦੇ ਢੰਗਾਂ ਵਾਲੇ ਵੱਖਰੇ ਮਕੈਨਿਜ਼ਮ ਹਨ, ਅਤੇ ਵਿਕਰੇਤਾ ਦੋਵਾਂ ਲਈ ਇੱਕੋ ਸ਼ਬਦ ਵਰਤਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ-ਸੂਚੀਆਂ ਵਿੱਚ ਤੁਲਨਾ ਕਰਨਾ ਮੁੱਖ ਗੱਲ ਖੁੰਝਾ ਦਿੰਦਾ ਹੈ; ਉਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਇਸ ਗੱਲ 'ਤੇ ਕਰੋ ਕਿ ਜਵਾਬ ਬਦਲਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਲਾਭਦਾਇਕ ਵੰਡ ਉਸ ਨਿਯਮ ਵਿਚਕਾਰ ਹੈ ਜੋ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਨਿਯਮ ਵਿਚਕਾਰ ਜੋ ਨਹੀਂ ਕਰਦਾ।
ਹਰ ਨਿਯਮ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨਾਲ ਮਿਲਦਾ ਹੈ
ਪ੍ਰੀਫਿਕਸ ਨਿਯਮ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਮੰਜ਼ਿਲ ਐਡਰੈਸ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਕੁਝ ਵੀ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਹਰ ਪੈਕੇਟ ਲਈ ਮੇਲ ਸਹੀ ਹੁੰਦਾ ਹੈ। ਡੋਮੇਨ ਨਿਯਮ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਨਾਮ ਲਈ ਬੇਨਤੀ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਜਿਸਨੂੰ RFC 1034 ਐਡਰੈਸ ਦੀ ਬਜਾਏ ਲੇਬਲ ਦਾ ਦਰਖਤ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਕੁਝ ਉਤਪਾਦ ਨਾਮ ਨੂੰ ਇੱਕ ਵਾਰ ਹੱਲ ਕਰਕੇ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੇ ਐਡਰੈਸ ਨੂੰ ਰੂਟ ਵਜੋਂ ਸਥਾਪਿਤ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਨਿਯਮ ਰਿਫ੍ਰੈਸ਼ ਟਾਈਮਰ ਜੁੜਿਆ IP ਨਿਯਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇਨ੍ਹਾਂ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਹਾਲਤ ਵਿੱਚ ਫੇਲ ਹੋਣਾ ਬਿਲਕੁਲ ਵੱਖਰਾ ਦਿਸਦਾ ਹੈ।
ਸਟੈਕ ਵਿੱਚ ਡੋਮੇਨ ਨਿਯਮ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ
ਜੇ ਉਤਪਾਦ ਡੋਮੇਨ ਨਿਯਮ ਸਥਾਨਕ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਪ੍ਰੌਕਸੀ ਤੱਕ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਿਯਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਇਹ ਨਾਮ ਹੱਲ ਕਰਕੇ ਰੂਟ ਜੋੜ ਕੇ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਐਡਰੈਸ ਆਖਰੀ ਰਿਫ੍ਰੈਸ਼ ਜਿੰਨੇ ਹੀ ਤਾਜ਼ਾ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਹ ਰਿਜ਼ੋਲਵਰ ਨਾਲ ਹੁੱਕ ਕਰਦਾ ਹੈ, ਤਾਂ DNS ਵਿਵਹਾਰ ਰੂਟਿੰਗ ਨੀਤੀ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਾਲਬੈਕ ਰਿਜ਼ੋਲਵਰ ਇਸਨੂੰ ਚੁੱਪਚਾਪ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ।
ਸੈਟਿੰਗ ਦਾ ਲੇਬਲ ਨਹੀਂ, ਵਿਕਰੇਤਾ ਦਾ ਮਾਡਲ ਪੜ੍ਹੋ। Split Tunnel ਨਾਮ ਵਾਲਾ ਬਾਕਸ ਰੱਖਣ ਵਾਲੇ ਦੋ ਕਲਾਇੰਟ ਤਿੰਨ ਵੱਖਰੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਸਕਦੇ ਹਨ।
ਕੀ ਟੁੱਟਦਾ ਹੈ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਤਿੰਨ ਚੀਜ਼ਾਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਟੁੱਟਦੀਆਂ ਹਨ। ਐਡਰੈਸ ਬਦਲਣਾ: CDN ਹੋਸਟਨਾਮ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਵੱਖਰੇ ਐਡਰੈਸ ਸਮੂਹ ਵਿੱਚ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਨਕਲ ਕੀਤੀ ਸੂਚੀ ਛੇਤੀ ਪੁਰਾਣੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਬਡੋਮੇਨ ਦਾਇਰਾ: example.com ਲਈ ਨਿਯਮ api.example.com ਨੂੰ ਕਵਰ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਹੜਾ। ਹੱਲ ਵਿੱਚ ਫੇਲ: ਜਦੋਂ ਰਿਜ਼ੋਲਵਰ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹੱਲ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਟਨਲ ਕਰਨ ਜਾਂ ਸਿੱਧਾ ਭੇਜਣ ਵੱਲ ਮੁੜ ਸਕਦਾ ਹੈ।
ਸਿਰਫ ਦੂਜਾ ਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਸਵਾਲ ਹੈ। ਬਾਕੀ ਦੋ ਡਿਜ਼ਾਈਨ ਦੇ ਸਵਾਲ ਹਨ ਕਿ ਉਤਪਾਦ ਕਿੰਨਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਨੂੰ ਤਿਆਰ ਹੈ।
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
ਪ੍ਰੀਫਿਕਸ ਕਦੋਂ ਬਿਹਤਰ ਜਵਾਬ ਹੈ
ਸਥਿਰ ਨਿੱਜੀ ਸਬਨੈੱਟ ਲਈ ਸਪਸ਼ਟ ਪ੍ਰੀਫਿਕਸ ਵਧੇਰੇ ਸਪਸ਼ਟ, ਤੇਜ਼ ਅਤੇ ਆਡਿਟ ਕਰਨ ਵਿੱਚ ਸੌਖਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਰਿਜ਼ੋਲਵਰ ਰੁਕਾਵਟ ਨੂੰ ਵੀ ਝੱਲ ਲੈਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ। ਡੋਮੇਨ ਨਿਯਮ ਤਦ ਵਰਤੋ ਜਦੋਂ ਸੇਵਾ ਹੋਸਟ ਕੀਤੀ ਹੋਈ ਹੋਵੇ, ਜਦੋਂ ਐਡਰੈਸ ਘੁੰਮਦੇ ਹੋਣ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਮੰਜ਼ਿਲ ਸਮੂਹ ਦੀ ਗਿਣਤੀ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਸਿਰਫ ਇਸ ਲਈ ਨਾ ਵਰਤੋ ਕਿ ਹੋਸਟਨਾਮ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸੰਜੋਗ ਨਾਲ ਪਤਾ ਹੈ।
ਅੰਦਾਜ਼ੇ ਵਾਲੀ ਸਥਿਰ ਸੂਚੀ ਦੋਵਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਮਾੜੀ ਹੈ: ਇਹ ਸੰਭਾਲੀ ਹੋਈ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਜਿਸ ਦਿਨ ਪ੍ਰਦਾਤਾ ਹੋਸਟ ਜੋੜਦਾ ਹੈ ਉਸ ਦਿਨ ਚੁੱਪਚਾਪ ਟ੍ਰੈਫਿਕ ਖੁੰਝਾ ਦਿੰਦੀ ਹੈ।
ਨਵੀਂ ਬੇਨਤੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ
ਆਮ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਠੰਡੀ ਬੇਨਤੀ ਨਾਲ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀਤਾ ਪੰਨਾ ਸ਼ਾਇਦ ਕਦੇ ਨਿਯਮ ਨੂੰ ਛੂਹੇ ਹੀ ਨਾ। ਨਾਮ ਹੱਲ ਕਰੋ, ਫਿਰ ਜਾਂਚੋ ਕਿ ਕਨੈਕਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਗਿਆ। dig +short app.example.com ਮੌਜੂਦਾ ਐਡਰੈਸ ਸਮੂਹ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਕਨੈਕਸ਼ਨ ਸੂਚੀ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਨੇ ਪ੍ਰਵਾਹ ਢੋਇਆ।
ਉਤਪਾਦ ਜੋ ਰਿਫ੍ਰੈਸ਼ ਅੰਤਰਾਲ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਉਸ ਤੋਂ ਬਾਅਦ ਦੁਹਰਾਓ। ਜੇ ਐਡਰੈਸ ਸਮੂਹ ਖਿਸਕ ਜਾਵੇ ਅਤੇ ਨਿਯਮ ਉਸਦਾ ਪਿੱਛਾ ਨਾ ਕਰੇ, ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਵਿਵਹਾਰ ਲੱਭ ਲਿਆ ਹੈ।
ਰਿਜ਼ੋਲਵਰ ਨੀਤੀ ਵੀ ਵੱਖਰੀ ਰੱਖੋ। ਡੋਮੇਨ ਨਿਯਮ ਨੂੰ ਸਹੀ ਨਾਮ-ਡੇਟਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇਹ ਆਪਣੇ ਆਪ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।