Apple VPN On Demand ਦੇ ਡੋਮੇਨ ਨਿਯਮ ਟਨਲ ਕਿਵੇਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ
ਡੋਮੇਨ ਨਿਯਮ ਸਿਰਫ਼ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਟਨਲ ਕਦੋਂ ਖੁੱਲ੍ਹਦਾ ਹੈ। connect-if-needed DNS ਪ੍ਰੋਬ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਰੂਟ ਅਜੇ ਵੀ ਟ੍ਰੈਫਿਕ ਕਿਉਂ ਚੁਣਦੇ ਹਨ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਕਿਵੇਂ ਪਰਖਣੀ ਹੈ।
ਤੁਸੀਂ ਇੱਕ ਅੰਦਰੂਨੀ ਨਾਮ ਦੀ ਮੰਗ ਕਰਦੇ ਹੋ ਤਾਂ ਟਨਲ ਖੁੱਲ੍ਹਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਐਪ ਨੂੰ ਉੱਨੀ ਹੀ ਲੋੜ ਹੋਣ 'ਤੇ ਬੰਦ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਐਪ ਵਿੱਚ ਬੱਗ ਨਹੀਂ ਹੈ; ਇਹ ਡੋਮੇਨ ਨਿਯਮ ਦਾ ਆਕਾਰ ਹੈ। Apple ਦੀ on-demand ਸੰਰਚਨਾ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦੱਸਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਸ਼ਰਤਾਂ ਦਾ ਡੋਮੇਨ ਰੂਪ ਇੱਕ ਵੀ ਪੈਕਟ ਹਿਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ। ਦੋ ਸਵਾਲ ਲਗਾਤਾਰ ਮਿਲ ਜਾਂਦੇ ਹਨ: ਟਨਲ ਕਦੋਂ ਉੱਪਰ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਹੋਣ ਮਗਰੋਂ ਕੀ ਢੋਂਦਾ ਹੈ। ਪਹਿਲਾ ਟ੍ਰਿਗਰ ਹੈ, ਦੂਜਾ ਰੂਟ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਨੀਤੀ ਹੈ, ਅਤੇ ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਦੋਵੇਂ ਇੱਕੋ payload ਵਿੱਚ ਸੈੱਟ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਸਹੀ ਡੋਮੇਨ ਨਿਯਮ ਵੀ ਤੁਹਾਨੂੰ ਗਲਤ ਨੈੱਟਵਰਕ 'ਤੇ ਛੱਡ ਸਕਦਾ ਹੈ।
ਟ੍ਰਿਗਰ ਅਤੇ ਟ੍ਰੈਫਿਕ ਚੋਣ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵਿੱਚ ਹਨ
on-demand ਨਿਯਮ VPN payload ਦੇ on-demand ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ: ਕ੍ਰਮਬੱਧ ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ, ਹਰ ਇੱਕ ਵਿੱਚ ਇੱਕ ਕਾਰਵਾਈ ਅਤੇ ਮੇਲ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦਾ ਸਮੂਹ। ਕਨੈਕਟੀਵਿਟੀ ਬਦਲਣ ਜਾਂ ਕੁਝ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ 'ਤੇ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਾਰਵਾਈ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਟਨਲ ਉੱਪਰ ਚੁੱਕਿਆ ਜਾਵੇ, ਮੁਲਾਂਕਣ ਹੋਵੇ, ਡਿਸਕਨੈਕਟ ਹੋਵੇ ਜਾਂ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾਵੇ। ਇਹ ਸਭ ਐਪ ਨੂੰ ਸਾਕਟ ਮਿਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਲੇਟਫਾਰਮ ਦੀ ਨੈੱਟਵਰਕਿੰਗ ਪਰਤ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
ਇਸ ਮਗਰੋਂ ਆਉਣ ਵਾਲਾ ਹਿੱਸਾ ਵੱਖਰਾ ਕੁੰਜੀ ਸਮੂਹ ਹੈ: ਟਨਲ ਦੀਆਂ IPv4 ਅਤੇ IPv6 ਸੈਟਿੰਗਾਂ, ਉਸ ਦੇ ਸ਼ਾਮਲ ਅਤੇ ਬਾਹਰ ਰੱਖੇ ਰੂਟ, DNS ਸਰਵਰ ਪਤੇ, ਅਤੇ iOS ਤੇ iPadOS ਵਿੱਚ ਕਿਹੜੀਆਂ ਐਪਾਂ ਟਨਲ ਵਰਤ ਸਕਦੀਆਂ ਹਨ ਇਹ ਤੈਅ ਕਰਨ ਵਾਲੀ ਪ੍ਰਤੀ-ਐਪ ਮੈਪਿੰਗ। ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਚੌੜੇ ਟ੍ਰਿਗਰ ਨੂੰ ਤੰਗ ਰੂਟ ਨਾਲ ਜੋੜ ਸਕਦੀ ਹੈ, ਜਾਂ ਤੰਗ ਟ੍ਰਿਗਰ ਨੂੰ ਡਿਫਾਲਟ ਰੂਟ ਨਾਲ। ਸਿਰਫ਼ ਅੱਧਾ ਪੜ੍ਹੋ, ਦੂਜਾ ਅੱਧਾ ਖਰਾਬੀ ਵਾਂਗ ਦਿਸੇਗਾ।
ਮੇਰੇ ਕੋਲ ਇੱਕ ਲੈਬ ਪ੍ਰੋਫਾਈਲ ਹੈ ਜੋ ਅੰਦਰੂਨੀ ਡੋਮੇਨ ਹੇਠਾਂ ਕੁਝ ਵੀ ਮੰਗੇ ਜਾਣ 'ਤੇ ਕਨੈਕਟ ਹੁੰਦੀ ਹੈ ਪਰ ਟਨਲ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ /16 ਰੂਟ ਕਰਦੀ ਹੈ। ਇਹ ਆਪਣੇ payload ਵਿੱਚ ਲਿਖਿਆ ਬਿਲਕੁਲ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਕਿਸਮ ਦੀ ਪ੍ਰੋਫਾਈਲ ਵੀ ਹੈ ਜੋ ਟਿਕਟ ਪੈਦਾ ਕਰਦੀ ਹੈ: ਲੋਕ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਜੁੜਿਆ ਟਨਲ ਮਤਲਬ ਉਨ੍ਹਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਇਸ ਦੇ ਅੰਦਰ ਹੈ।
ਡੋਮੇਨ ਨਿਯਮ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਪੁੱਛਦਾ ਹੈ
ਆਮ ਤੌਰ 'ਤੇ connect-if-needed ਕਹਾਉਣ ਵਾਲੇ ਨਿਯਮ ਦਾ ਡੋਮੇਨ ਰੂਪ ਪੈਕਟ payload ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ ਅਤੇ URL ਨਹੀਂ ਵੇਖਦਾ। ਨਾਮ ਰਿਜ਼ੋਲਵ ਹੋਣ 'ਤੇ ਸਿਸਟਮ ਇਸ ਨੂੰ ਨਿਯਮ ਦੇ ਡੋਮੇਨਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਮੇਲ ਖਾਣ 'ਤੇ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਨਾਮ ਟਨਲ ਵੱਲੋਂ ਦਿੱਤੇ DNS ਸਰਵਰਾਂ ਰਾਹੀਂ ਰਿਜ਼ੋਲਵ ਹੋ ਸਕਦਾ ਹੈ। ਟਨਲ ਦਾ ਰਿਜ਼ੋਲਵਰ ਜਵਾਬ ਦੇਵੇ ਤਾਂ ਨਾਮ ਅੰਦਰੂਨੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਸ ਦੀ ਥਾਂ ਸਥਾਨਕ ਰਿਜ਼ੋਲਵਰ ਜਵਾਬ ਦੇਵੇ ਤਾਂ ਨਾਮ ਬਾਹਰੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੋਈ ਟਨਲ ਨਹੀਂ ਦਿਸਦਾ। Apple ਦਾ ਤੈਨਾਤੀ ਸੰਖੇਪ ਇਸ ਨੂੰ ਨੈੱਟਵਰਕ ਖੋਜ ਅਤੇ ਫਿਰ ਕਨੈਕਸ਼ਨ ਮੁਲਾਂਕਣ ਦੱਸਦਾ ਹੈ।
ਦੋ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ। ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਟਨਲ ਦੇ ਅੰਦਰ DNS ਸਰਵਰ ਦੱਸਣੇ ਚਾਹੀਦੇ ਹਨ; ਟਨਲ ਰਿਜ਼ੋਲਵਰ ਤੋਂ ਬਿਨਾਂ ਡੋਮੇਨ ਨਿਯਮ ਕੋਲ ਤੁਲਨਾ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਮੁਲਾਂਕਣ ਤੁਹਾਡੀ ਉਮੀਦ ਵਾਲਾ ਮੇਲ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਅਤੇ ਖੋਜ ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਤੱਕ ਪਹੁੰਚਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੋ ਐਪ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਆਪਣਾ ਐਨਕ੍ਰਿਪਟਿਡ DNS ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਐਕਸਟੈਂਸ਼ਨ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਸ਼ਬਦੀ ਪਤੇ ਨਾਲ ਕਨੈਕਸ਼ਨ — ਇਹ ਕਦੇ ਉਹ ਨਾਮ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਨਹੀਂ ਬਣਾਉਂਦੇ ਜਿਸ ਦੀ ਨਿਯਮ ਉਡੀਕ ਕਰ ਰਿਹਾ ਸੀ। ਮੇਰੀਆਂ ਸਭ ਤੋਂ ਲੰਬੀਆਂ ਦੁਪਹਿਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉਦੋਂ ਖ਼ਤਮ ਹੋਈ ਜਦੋਂ ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਟਨਲ ਅੱਗੇ ਵਾਲਾ ਕਲਾਇੰਟ DNS over HTTPS ਵਰਤ ਰਿਹਾ ਸੀ।
ਕੈਸ਼ਿੰਗ ਵੀ ਟ੍ਰਿਗਰ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਕੈਸ਼ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਨਾਮ ਦਾ ਜਵਾਬ ਉਸ ਪ੍ਰੋਬ ਤੋਂ ਬਿਨਾਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਟਨਲ ਸ਼ੁਰੂ ਕਰਦਾ, ਇਸ ਲਈ ਕੱਲ੍ਹ ਕੰਮ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਰੀਬੂਟ ਮਗਰੋਂ ਜਾਂ ਟਨਲ ਕੁਝ ਸਮਾਂ ਉੱਪਰ ਰਹਿਣ ਮਗਰੋਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। macOS 'ਤੇ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ਹਾਲਤ ਰੀਸੈਟ ਕਰਦਾ ਹੈ; iOS 'ਤੇ ਏਅਰਪਲੇਨ ਮੋਡ ਚਾਲੂ-ਬੰਦ ਕਰਨਾ ਜਾਂ ਡਿਵਾਈਸ ਰੀਸਟਾਰਟ ਕਰਨਾ ਤੁਲਨਾਯੋਗ ਸਾਫ਼ ਸ਼ੁਰੂਆਤ ਦਿੰਦਾ ਹੈ।
ਮੇਲ ਦਾ ਦਾਇਰਾ: ਨਾਮ, ਐਪਾਂ ਅਤੇ ਨੈੱਟਵਰਕ
ਡੋਮੇਨ ਮਿਲਾਨ ਕਈ ਕਿਸਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਨਿਯਮ ਇੰਟਰਫੇਸ ਕਿਸਮ (Wi-Fi, ਸੈਲੂਲਰ, Ethernet) ਅਤੇ ਖਾਸ SSID ਨਾਲ ਵੀ ਮਿਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ-ਐਪ ਜਾਂ Safari-ਡੋਮੇਨ ਐਂਟਰੀਆਂ ਟਨਲ ਨੂੰ ਇੱਕ ਕੰਮ-ਪ੍ਰਵਾਹ ਨਾਲ ਬੰਨ੍ਹਦੀਆਂ ਹਨ। ਇਹੀ ਬੰਧਨ ਉਹ ਅਜੀਬ ਤਜਰਬਾ ਸਮਝਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਸਿਰਫ਼ ਇੱਕ ਐਪ ਬਾਕੀ ਸਭ ਤੋਂ ਵੱਖਰੀ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ: ਬਾਕੀ ਐਪਾਂ ਟਨਲ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ, ਇਸ ਲਈ ਟਨਲ ਆਈਕਨ ਜੁੜਿਆ ਹੋਣ ਦਾ ਕਹਿਣ 'ਤੇ ਵੀ ਉਹ ਸਥਾਨਕ ਮਾਰਗ ਵਰਤਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
ਕ੍ਰਮ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਨਿਯਮ ਕ੍ਰਮ ਵਿੱਚ ਮੁਲਾਂਕਿਤ ਹੁੰਦੇ ਹਨ ਅਤੇ ਪਹਿਲਾ ਮਿਲਣ ਵਾਲਾ ਕਾਰਵਾਈ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਤੰਗ ਡੋਮੇਨ ਨਿਯਮ ਉੱਤੇ ਰੱਖਿਆ ਚੌੜਾ ਕਿਸੇ-ਵੀ-Wi-Fi-ਤੇ-ਜੁੜੋ ਨਿਯਮ ਚੁੱਪਚਾਪ ਜਿੱਤ ਜਾਵੇਗਾ ਅਤੇ ਡੋਮੇਨ ਨਿਯਮ ਨੂੰ ਪਰਖਣਯੋਗ ਨਹੀਂ ਛੱਡੇਗਾ। ਡੋਮੇਨ ਸੂਚੀ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪਿਛਲਾ ਕੋਈ ਨਿਯਮ ਪਹਿਲਾਂ ਹੀ ਨਹੀਂ ਮਿਲਿਆ।
ਇਸੇ ਲਈ always-on ਸਿਰਫ਼ ਸਖ਼ਤ on-demand ਨਿਯਮ ਨਹੀਂ ਹੈ। always-on ਦਾ ਲਾਗੂ ਕਰਨਾ ਵੱਖਰਾ ਤੈਨਾਤੀ ਮੋਡ ਹੈ ਜਿਸ ਦੀਆਂ ਆਪਣੀਆਂ ਨਿਗਰਾਨੀ ਅਤੇ ਪ੍ਰਬੰਧਨ ਲੋੜਾਂ ਹਨ; ਇਹ ਨਾਮ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣ ਦੀ ਥਾਂ ਟਨਲ ਖੁੱਲ੍ਹਾ ਰੱਖਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਕਦੇ ਨਾ ਡਿੱਗਣ ਵਾਲਾ ਟਨਲ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਡੋਮੇਨ ਨਿਯਮ ਗਲਤ ਸਾਧਨ ਹੈ।
ਟੁੱਟੇ ਨਿਯਮ ਵਰਗੀਆਂ ਅਸਫਲਤਾਵਾਂ
ਡੋਮੇਨ ਨਿਯਮ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਪੰਜ ਥਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਪਹੁੰਚਦੀਆਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਆਖ਼ਰੀ ਨਿਯਮ ਦਾ ਪਾਠ ਹੈ।
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
ਕੈਪਟਿਵ ਪੋਰਟਲ ਆਪਣੀ ਵੱਖਰੀ ਲਾਈਨ ਦੇ ਹੱਕਦਾਰ ਹਨ, ਕਿਉਂਕਿ ਹੋਟਲ ਅਤੇ ਹਵਾਈ ਅੱਡੇ ਦਾ Wi-Fi ਉਸੇ ਖੋਜ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿਸ 'ਤੇ ਨਿਯਮ ਨਿਰਭਰ ਹੈ। ਜਦੋਂ ਤੱਕ ਪੋਰਟਲ ਡਿਵਾਈਸ ਨੂੰ ਅੰਦਰ ਨਹੀਂ ਆਉਣ ਦਿੰਦਾ, ਟਨਲ ਦਾ DNS ਸਰਵਰ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ, ਪ੍ਰੋਬ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ ਗਲਤ ਸਪੈਲਿੰਗ ਵਾਲੇ ਡੋਮੇਨ ਵਾਂਗ ਦਿਸਦੀ ਹੈ। ਪ੍ਰਮਾਣਿਕਤਾ ਦੂਜਾ ਚੁੱਪ ਕੇਸ ਹੈ: ਨਿਯਮ ਚੱਲ ਸਕਦਾ ਹੈ, ਟਨਲ ਜੁੜਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਮਿਆਦ ਪੁੱਗੇ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਦੂਜੀ ਡਿਸਪਲੇ 'ਤੇ ਆਉਣ ਵਾਲੇ ਪ੍ਰੋਂਪਟ 'ਤੇ ਮਰ ਜਾਂਦਾ ਹੈ।
IPv6 ਇੱਕ ਅਜਿਹਾ ਰੂਪ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ ਦਾ ਗਲਤ ਨਿਦਾਨ ਕਰਨਾ ਸੌਖਾ ਹੈ। ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰਾਂ ਵਾਲੇ ਨਾਮ ਦਾ ਜਵਾਬ ਪਹਿਲਾਂ AAAA ਰਿਕਾਰਡ ਤੋਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਟਨਲ ਦੀ ਰੂਟ ਸੂਚੀ ਵਿੱਚ ਸਿਰਫ਼ IPv4 ਹੈ। ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਦੂਜਾ ਫੇਲ੍ਹ, ਅਤੇ ਡੋਮੇਨ ਸੂਚੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਰਦੋਸ਼ ਹੈ।
ਅਸਲੀ ਬੇਨਤੀ ਨਾਲ, ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਪਰਖੋ
ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀ ਪੜ੍ਹੋ। macOS 'ਤੇ sudo profiles show -type configuration VPN payload ਸਮੇਤ ਸਥਾਪਿਤ ਪ੍ਰੋਫਾਈਲ ਛਾਪਦਾ ਹੈ, scutil --nc list ਸੇਵਾ ਦੀ ਹਾਲਤ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ scutil --nc show <service> ਸਿਸਟਮ ਵੱਲੋਂ ਵਰਤਿਆ ਜਾਂਦਾ on-demand ਸ਼ਬਦਕੋਸ਼ ਛਾਪਦਾ ਹੈ। ਪ੍ਰਬੰਧਿਤ iPhone ਜਾਂ iPad 'ਤੇ ਉਹੀ payload ਪ੍ਰਬੰਧਨ ਕੰਸੋਲ ਜਾਂ MDM ਰਿਪੋਰਟ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਨੈੱਟਵਰਕਿੰਗ ਲੌਗ macOS 'ਤੇ log stream --predicate 'subsystem == "com.apple.networkextension"' ਨਾਲ, ਅਤੇ ਫ਼ੋਨ ਜੁੜਿਆ ਹੋਣ 'ਤੇ ਡਿਵਾਈਸ ਕੰਸੋਲ ਰਾਹੀਂ ਉਪਲਬਧ ਹਨ।
ਫਿਰ ਇਸ ਸੈਸ਼ਨ ਵਿੱਚ ਪਹਿਲਾਂ ਨਾ ਪੁੱਛੇ ਗਏ ਹੋਸਟਨਾਮ ਨਾਲ ਪਰਖੋ। ਟਨਲ ਦੇ DNS ਜ਼ੋਨ ਵਿੱਚ ਉਹ ਨਾਮ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਰਿਜ਼ੋਲਵ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਵਾਰ ਮੰਗੋ, ਅਤੇ ਦੇਖੋ ਟਨਲ ਦਿਸਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਉਹੀ ਖੋਜ ਦੋ ਵਾਰ ਚਲਾਓ: ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਕੈਸ਼ ਮਾਰਗ ਵਰਤਦੀ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਦਾ ਫ਼ਰਕ ਦੱਸਦਾ ਹੈ ਕਿ ਟ੍ਰਿਗਰ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਹੈ ਜਾਂ ਰਾਊਟਿੰਗ।
ਟਨਲ ਉੱਪਰ ਆਉਣ ਮਗਰੋਂ ਦੋਵੇਂ ਪਰਤਾਂ ਵੱਖਰੀਆਂ ਜਾਂਚੋ। netstat -rn -f inet ਅਤੇ netstat -rn -f inet6 ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਹਰ ਪ੍ਰੀਫਿਕਸ ਕਿੱਧਰ ਸੰਕੇਤ ਕਰਦਾ ਹੈ, scutil --dns ਰਿਜ਼ੋਲਵਰਾਂ ਦਾ ਕ੍ਰਮ ਅਤੇ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਕਿਸ ਰਿਜ਼ੋਲਵਰ ਦਾ ਮਾਲਕ ਹੈ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ nettop -m route ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਨੇ ਬਾਈਟ ਢੋਏ। ਜੇ ਟਨਲ ਉੱਪਰ ਹੈ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਸਹੀ ਹੈ ਪਰ ਸਰੋਤ ਫੇਲ੍ਹ ਹੋ ਰਿਹਾ ਹੈ ਤਾਂ ਨਿਯਮ ਸੋਧਣਾ ਬੰਦ ਕਰੋ; ਸਰਵਰ-ਸਾਈਡ ਅਧਿਕਾਰ ਅਤੇ ਵਾਪਸੀ ਰੂਟ ਜਾਂਚੋ।
ਜਦੋਂ ਨਿਯਮ ਕਿਸੇ ਹੋਰ ਦਾ ਹੋਵੇ
ਜੇ ਕਨੈਕਸ਼ਨ ਕੱਟਣ ਮਗਰੋਂ ਟਨਲ ਦੁਬਾਰਾ ਦਿਸੇ ਤਾਂ ਨਿਯਮ ਆਮ ਤੌਰ 'ਤੇ ਐਪ ਦਾ ਨਹੀਂ, ਪ੍ਰੋਫਾਈਲ ਦਾ ਹੁੰਦਾ ਹੈ: MDM ਰਾਹੀਂ ਭੇਜੀ ਸੰਰਚਨਾ, ਬਚਿਆ ਹੋਇਆ ਨਿੱਜੀ ਪ੍ਰੋਫਾਈਲ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਵੱਲੋਂ ਸਥਾਪਿਤ ਪ੍ਰੋਫਾਈਲ। sudo profiles show -type configuration ਅਤੇ on-demand ਕੁੰਜੀਆਂ ਦੀ ਖੋਜ ਇਸ ਨੂੰ ਤੰਗ ਕਰੇਗੀ, ਅਤੇ ਹਟਾਉਣ ਦਾ ਰਾਹ ਪ੍ਰੋਫਾਈਲ ਹੈ, ਮੀਨੂ ਬਾਰ ਦਾ ਟੌਗਲ ਨਹੀਂ। ਸੇਵਾ ਐਂਟਰੀ ਜਾਂ ਐਪ ਮਿਟਾਉਣ ਨਾਲ ਨਿਯਮ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਸਥਾਪਨਾ ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ।
ਇੱਕ ਪਰਖ ਮਾਲਕੀ ਤੈਅ ਕਰਦੀ ਹੈ: ਡਿਸਕਨੈਕਟ ਕਰੋ, ਉਡੀਕ ਕਰੋ, ਅੰਦਰੂਨੀ ਨਾਮ ਦੁਬਾਰਾ ਮੰਗੋ। ਜੇ ਟਨਲ ਵਾਪਸ ਆਵੇ ਤਾਂ ਟ੍ਰਿਗਰ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਖੁੱਲ੍ਹਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਸ ਨੂੰ ਕੌਣ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਕੀ ਉਹ ਦਾਇਰਾ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਨੂੰ ਬੱਗ ਵਜੋਂ ਦਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹੀ ਪੰਜ ਜਾਂਚਾਂ ਕਰੋ: payload ਵਿੱਚ ਟਨਲ ਰਿਜ਼ੋਲਵਰ ਪਤੇ ਮੌਜੂਦ ਹਨ, ਨਾਮ ਕੈਸ਼ ਨਹੀਂ ਹੋਇਆ ਸੀ, ਪਿਛਲਾ ਕੋਈ ਨਿਯਮ ਪਹਿਲਾਂ ਹੀ ਨਹੀਂ ਮਿਲਿਆ, ਰੂਟ ਸੂਚੀ AAAA ਮਾਰਗ ਢਕਦੀ ਹੈ, ਅਤੇ ਐਪ ਟਨਲ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਹੈ। ਪੰਜੇ ਸਹੀ ਹੋਣ ਤਾਂ ਨਿਯਮ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਖਰਾਬੀ ਮਾਰਗ ਵਿੱਚ ਹੋਰ ਅੱਗੇ ਹੈ।