VPN ਲੌਗਇਨ RADIUS ਅਤੇ ਤੁਹਾਡੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ
VPN ਸਾਈਨ-ਇਨ ਨੂੰ ਕਲਾਇੰਟ ਤੋਂ ਗੇਟਵੇ ਦੀ RADIUS ਬੇਨਤੀ, ਉਸ ਪਿੱਛੇ ਦੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਅਤੇ ਸਵੀਕ੍ਰਿਤੀ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਨੀਤੀ ਤੱਕ ਟ੍ਰੈਕ ਕਰੋ।
ਪਿਛਲੇ ਹਫ਼ਤੇ ਇੱਕ ਵਰਤੋਂਕਾਰ VPN ਵਿੱਚ ਸਾਈਨ ਇਨ ਕਰ ਸਕਿਆ ਅਤੇ ਫਿਰ ਵੀ ਉਸ ਨੈੱਟਵਰਕ ਉੱਤੇ ਪਹੁੰਚਿਆ ਜਿੱਥੇ ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਹੋ ਰਿਹਾ ਸੀ। ਕਲਾਇੰਟ ਨੇ ਕਿਹਾ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਗੇਟਵੇ ਲੌਗ ਨੇ Access-Accept ਕਿਹਾ, ਅਤੇ ਪਛਾਣ ਟੀਮ ਨੇ ਕਿਹਾ ਕਿ ਖਾਤਾ ਠੀਕ ਹੈ। ਲੌਗਇਨ ਕੰਮ ਕਰ ਚੁੱਕਾ ਸੀ; ਉਸ ਪਿੱਛੇ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ। ਜਦੋਂ VPN ਸਾਈਨ-ਇਨ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਮੈਂ ਉਹ ਰਾਹ ਚੱਲਦਾ ਹਾਂ ਜੋ ਬੇਨਤੀ ਅਸਲ ਵਿੱਚ ਲੈਂਦੀ ਹੈ — ਕਲਾਇੰਟ, ਗੇਟਵੇ, RADIUS ਸਰਵਰ, ਪਛਾਣ ਪ੍ਰਦਾਤਾ — ਅਤੇ ਪਹਿਲੇ ਉਸ ਕਦਮ ਉੱਤੇ ਰੁਕਦਾ ਹਾਂ ਜਿਸ ਦਾ ਜਵਾਬ ਅਗਲੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਕਲਾਇੰਟ ਕਦੇ ਵੀ RADIUS ਨਹੀਂ ਬੋਲਦਾ
ਲੈਪਟਾਪ ਦੀ ਐਪ ਜੋ ਵੀ ਦਿਖਾਵੇ, ਉਸ ਦਾ ਪਹਿਲਾ ਕਦਮ VPN ਪ੍ਰੋਟੋਕੋਲ ਹੈ: IKEv2, OpenVPN, WireGuard ਜਾਂ TLS-ਅਧਾਰਿਤ ਕਲਾਇੰਟ। RADIUS ਉਸ ਵਟਾਂਦਰੇ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ। ਕਲਾਇੰਟ ਗੇਟਵੇ ਉੱਤੇ ਸਰਟੀਫਿਕੇਟ, ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ, ਜਾਂ ਟਨਲ ਸੈਟਅਪ ਅੰਦਰ ਲਿਜਾਈ ਜਾਣ ਵਾਲੀ EAP ਵਿਧੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ।
ਲੌਗ ਪੜ੍ਹਦਿਆਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਵਰਤੋਂਕਾਰ ਜੋ ਆਮ ਪ੍ਰਮਾਣੀਕਰਨ ਗਲਤੀ ਦੇਖਦਾ ਹੈ, ਉਹ ਗੇਟਵੇ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨਾਲ ਗੱਲ ਕਰ ਚੁੱਕਣ ਤੋਂ ਬਾਅਦ ਬਣਾਉਂਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਕਦੇ ਵੀ ਗੇਟਵੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਤਾਂ ਡੀਬੱਗ ਕਰਨ ਲਈ ਕੋਈ RADIUS ਬੇਨਤੀ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ RADIUS ਸਰਵਰ ਉੱਤੇ ਬਿਤਾਇਆ ਇੱਕ ਘੰਟਾ ਵਿਅਰਥ ਜਾਂਦਾ ਹੈ। ਬੈਕਐਂਡ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟਨਲ ਬਣਿਆ ਵੀ ਸੀ।
ਗੇਟਵੇ ਹੀ RADIUS ਕਲਾਇੰਟ ਹੈ
ਜਿਵੇਂ ਹੀ ਟਨਲ ਸੈਟਅਪ ਉਸ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜਿੱਥੇ ਪਹਿਚਾਣ-ਪੱਤਰ ਜਾਂਚਣੇ ਹੁੰਦੇ ਹਨ, ਗੇਟਵੇ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਸਰਵਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ Access-Request ਬਣਾਉਂਦਾ ਹੈ: User-Name, ਪਾਸਵਰਡ ਜਾਂ EAP ਪੇਲੋਡ, NAS-IP-Address ਜਾਂ NAS-Identifier, ਅਤੇ ਵਿਧੀ ਮੰਗੇ ਤਾਂ Message-Authenticator। ਬੇਨਤੀ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ UDP 1812 ਉੱਤੇ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਿਸਾਬ 1813 ਉੱਤੇ। ਪੁਰਾਣੀਆਂ ਸਥਾਪਨਾਵਾਂ ਅਜੇ ਵੀ 1645 ਅਤੇ 1646 ਵਰਤਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਜੋੜੀ ਲਈ ਲਿਖਿਆ ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਹੁਤ ਸਾਰੀਆਂ ਚੁੱਪ ਫੇਲ੍ਹਤਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।
ਦੋਵੇਂ ਪਾਸੇ ਇੱਕ ਭੇਤ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਵਰਤੋਂਕਾਰ ਪਹਿਚਾਣ-ਪੱਤਰ ਨਹੀਂ ਹੈ। ਇਹ ਵਟਾਂਦਰੇ ਉੱਤੇ ਦਸਤਖ਼ਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਜਵਾਬ ਉਸ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ। ਦੋਵੇਂ ਪਾਸੇ ਭੇਤ ਵੱਖਰਾ ਰੱਖੋ ਅਤੇ ਸਰਵਰ ਮਾੜੇ ਭੇਤ ਵਾਲਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ — ਇਹ ਬੇਨਤੀ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜਾਂ ਜਵਾਬ ਜਾਂਚ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਗੇਟਵੇ ਸਮਾਂ-ਸਮਾਪਤੀ ਦੱਸਦਾ ਹੈ। ਗਲਤ ਭੇਤ ਅਤੇ ਮਰਿਆ ਸਰਵਰ ਗੇਟਵੇ ਤੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ, ਇਸ ਲਈ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਮੈਂ ਕਲਾਇੰਟ ਸਾਧਨ ਨਾਲ ਕਦਮ ਜਾਂਚਦਾ ਹਾਂ।
ਪ੍ਰੋਟੋਕੋਲ ਛੋਟਾ ਅਤੇ ਪੁਰਾਣਾ ਹੈ — RFC 2865 ਪ੍ਰਮਾਣੀਕਰਨ ਵਟਾਂਦਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ — ਪਰ ਇਹ ਜੋ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਜਾਂਦਾ ਹੈ, ਉਹੀ ਬਹੁਤੀ VPN ਨੀਤੀ ਦਾ ਆਧਾਰ ਹਨ।
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS ਸਰਵਰ ਸਿਰਫ਼ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਦਾ ਅਗਲਾ ਹਿੱਸਾ ਹੋ ਸਕਦਾ ਹੈ
ਲੋਕ RADIUS ਅਤੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਬਾਰੇ ਇੰਝ ਗੱਲ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਉਹ ਇੱਕੋ ਡੱਬਾ ਹੋਣ। ਅਕਸਰ ਨਹੀਂ ਹੁੰਦੇ। RADIUS ਸਰਵਰ Access-Request ਲੈਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਪੁੱਛਦਾ ਹੈ — LDAP ਜਾਂ Kerberos ਰਾਹੀਂ Active Directory, ਸਥਾਨਕ ਵਰਤੋਂਕਾਰ ਫ਼ਾਈਲ, ਜਾਂ ਬਾਹਰੀ ਸੇਵਾ। LDAP ਜਾਂ krb5 ਮੌਡਿਊਲ ਵਾਲਾ FreeRADIUS, Windows NPS ਅਤੇ Cisco ISE ਸਭ ਇਸੇ ਥਾਂ ਖੜ੍ਹੇ ਹਨ।
ਇਹ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਵੇਖੋ। ਰੱਦ ਕੀਤਾ ਪਾਸਵਰਡ RADIUS ਵੱਲੋਂ ਅੱਗੇ ਭੇਜਿਆ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਦਾ ਜਵਾਬ ਹੈ। ਸਮਾਂ-ਸਮਾਪਤੀ ਆਮ ਤੌਰ ਉੱਤੇ RADIUS ਤੋਂ ਡਾਇਰੈਕਟਰੀ ਤੱਕ ਦਾ ਹਿੱਸਾ ਹੈ: ਮਿਆਦ ਪੁੱਗਿਆ ਬਾਈਂਡ ਖਾਤਾ, ਨਾ ਪਹੁੰਚਣ ਯੋਗ ਡਾਇਰੈਕਟਰੀ, ਜਾਂ ਗਲਤ ਬੈਕਐਂਡ ਵੱਲ ਭੇਜੀ ਬੇਨਤੀ। ਜੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਵਿੱਚ ਡੋਮੇਨ ਪਿਛੇਤਰ ਹੈ, ਤਾਂ ਸਰਵਰ ਉਸ ਦੇ ਆਧਾਰ ਉੱਤੇ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ CORP\alice ਅਤੇ [email protected] ਵਜੋਂ ਭੇਜਿਆ ਉਹੀ ਖਾਤਾ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਉੱਤੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। Windows NPS ਵਿੱਚ, Security ਲੌਗ ਮਨਜ਼ੂਰੀ ਲਈ 6272 ਅਤੇ ਇਨਕਾਰ ਲਈ 6273 ਦਰਜ ਕਰਦਾ ਹੈ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਫ਼ੈਸਲਾ NPS ਤੋਂ ਹੀ ਆਇਆ ਸੀ ਜਾਂ ਨਹੀਂ।
ਫੇਲ੍ਹਤਾ ਉਸੇ ਕਦਮ ਉੱਤੇ ਪੜ੍ਹੋ ਜਿਸ ਨੇ ਇਹ ਪੈਦਾ ਕੀਤੀ
ਇੱਕ ਹੀ ਕਨੈਕਟ ਨਾ ਹੋ ਸਕਣ ਵਾਲਾ ਸੁਨੇਹਾ ਚਾਰ ਵੱਖਰੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ ਨੂੰ ਕੱਢਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲੱਛਣ ਨੂੰ ਉਸ ਕਦਮ ਨਾਲ ਮਿਲਾਓ ਜਿਸ ਨੇ ਇਹ ਪੈਦਾ ਕੀਤੀ।
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
ਆਖਰੀ ਕਤਾਰ ਹੀ ਉਹ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਗਲਤ ਟੀਮ ਕੋਲ ਭੇਜਦੀ ਹੈ। Access-Accept ਦਾ ਮਤਲਬ ਹੈ ਪਹਿਚਾਣ-ਪੱਤਰ ਸਵੀਕਾਰ ਹੋਏ; ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਗੇਟਵੇ ਨੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਸਹੀ ਪੂਲ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂ ਰੂਟ ਧੱਕੇ। ਗਰੁੱਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤਦ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ ਜਦੋਂ ਗੇਟਵੇ ਨੀਤੀ ਉਨ੍ਹਾਂ ਨੂੰ ਪੜ੍ਹਦੀ ਹੈ। ਮੈਂ ਸਹੀ ਲੌਗਇਨ ਨੂੰ ਮਹਿਮਾਨ ਪੂਲ ਵਿੱਚ ਡਿੱਗਦੇ ਦੇਖਿਆ ਹੈ, ਕਿਉਂਕਿ RADIUS ਪਾਸੇ ਗਰੁੱਪ ਮੈਪਿੰਗ ਗੇਟਵੇ ਵੱਲੋਂ ਜਾਂਚੀ ਜਾਣ ਵਾਲੀ ਵਿਸ਼ੇਸ਼ਤਾ ਤੋਂ ਵੱਖਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਸੈੱਟ ਸੀ।
ਇੱਕ ਲੌਗਇਨ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਟ੍ਰੈਕ ਕਰੋ
ਇੱਕ ਟੈਸਟ ਖਾਤਾ ਅਤੇ ਇੱਕ ਗੇਟਵੇ ਚੁਣੋ, ਫਿਰ ਉਹੀ ਕੋਸ਼ਿਸ਼ ਚਾਰੇ ਬਿੰਦੂਆਂ ਉੱਤੇ ਵੇਖੋ। RADIUS ਪਾਸੇ ਡੀਬੱਗ ਰਨ ਸ਼ੁਰੂ ਕਰੋ — freeradius -X ਬੇਨਤੀ ਅਤੇ ਇਸ ਵੱਲੋਂ ਛੂਹੇ ਹਰ ਮੌਡਿਊਲ ਨੂੰ ਛਾਪਦਾ ਹੈ — ਗੇਟਵੇ ਦਾ ਪ੍ਰਮਾਣੀਕਰਨ ਲੌਗ ਟ੍ਰੈਕ ਕਰੋ, ਅਤੇ UDP ਵਟਾਂਦਰੇ ਲਈ tcpdump ਚਲਾਓ। ਇੱਕ ਵਾਰ ਜੁੜੋ ਅਤੇ ਚਾਰੇ ਟ੍ਰੇਸ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ।
ਤੁਸੀਂ ਜੋ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਸਹਿਮਤੀ ਹੈ: ਗੇਟਵੇ ਨੇ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਵਰਤੋਂਕਾਰ ਬਾਰੇ ਪੁੱਛਿਆ, RADIUS ਸਰਵਰ ਨੇ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਬੈਕਐਂਡ ਦੀ ਚੋਣ ਕੀਤੀ, ਉਸ ਬੈਕਐਂਡ ਨੇ ਫ਼ੈਸਲਾ ਵਾਪਸ ਕੀਤਾ, ਅਤੇ ਜਵਾਬ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਗੇਟਵੇ ਵੱਲੋਂ ਲਾਗੂ ਨੀਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਟ੍ਰੇਸ ਪਹਿਲੀ ਵਾਰ ਜਿੱਥੇ ਨਾ ਮਿਲਣ ਉਹ ਤੁਹਾਡੀ ਖਰਾਬੀ-ਰੇਖਾ ਹੈ। ਜੇ ਜਵਾਬ ਵਿੱਚ ਕੋਈ ਗਰੁੱਪ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ, ਤਾਂ ਸਮੱਸਿਆ VPN ਪਰੋਫ਼ਾਈਲ ਵਿੱਚ ਨਹੀਂ, RADIUS ਪਾਸੇ ਹੈ; ਜੇ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਅਤੇ ਗੇਟਵੇ ਇਸ ਨੂੰ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਗੇਟਵੇ ਨੀਤੀ ਹੈ।
ਉੱਥੇ ਹੁੰਦਿਆਂ ਇੱਕ ਸੁਰੱਖਿਆ ਨੋਟ। ਸਾਂਝਾ ਭੇਤ ਵਟਾਂਦਰੇ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਗੇਟਵੇ ਅਤੇ RADIUS ਸਰਵਰ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਹਨ, ਤਾਂ ਉਹ ਕਦਮ TLS ਉੱਤੇ RADIUS ਜਾਂ ਨਿੱਜੀ ਰਾਹ ਉੱਤੇ ਰੱਖੋ। ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਵਰਤੋਂਕਾਰ ਟਨਲ ਬੈਕਐਂਡ ਲਿੰਕ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੱਲਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਗੇਟਵੇ RADIUS ਸਰਵਰ ਤੱਕ ਉਸ ਪੋਰਟ ਉੱਤੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਜਿਸ ਲਈ ਇਹ ਅਸਲ ਵਿੱਚ ਸੰਰਚਿਤ ਹੈ। ਸਾਂਝਾ ਭੇਤ ਦੋਵੇਂ ਪਾਸੇ ਮੇਲ ਖਾਂਦਾ ਹੈ। RADIUS ਸਰਵਰ ਗੇਟਵੇ ਵੱਲੋਂ ਭੇਜੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਦਾ ਸਹੀ ਰੂਪ ਹੱਲ ਕਰਦਾ ਹੈ। ਸਵੀਕ੍ਰਿਤੀ ਗੇਟਵੇ ਨੀਤੀ ਲਈ ਲੋੜੀਂਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਜਾਂਦੀ ਹੈ। ਜੇ ਚਾਰੇ ਸਹੀ ਹੋਣ, ਤਾਂ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਲੌਗਇਨ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਨਹੀਂ, ਗੇਟਵੇ ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਹੈ।