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

ਦੋ ਨਾਂ, ਦੋ ਪਰਤਾਂ

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

LayerWhat carries the nameWho reads it
TLS handshakeServer name indicationThe TLS terminator in front of the service
HTTP requestAuthority or Host headerThe routing layer that picks a backend
Network pathDestination address and portRouters, and the VPN peer if one is in use

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

ਫਰੰਟਿੰਗ ਤਕਨੀਕ ਉੱਤੇ ਨਹੀਂ, ਪ੍ਰਦਾਤਾ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ

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

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

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

VPN ਅਸਲ ਵਿੱਚ ਕੀ ਚੁਣਦਾ ਹੈ

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

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

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

ਦਿੱਖ ਦੋ-ਮੁੱਲੀ ਨਹੀਂ ਹੈ

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

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

ਤਿੰਨ ਡੱਬੇ ਖਿੱਚੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ