ਇੱਕ AWS Client VPN ਸੈਸ਼ਨ ਪਿੱਛੇ LAN: ਕੀ ਫਾਰਵਰਡ ਹੁੰਦਾ ਹੈ

ਲੈਪਟਾਪ AWS Client VPN ਐਂਡਪੌਇੰਟ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਨਿੱਜੀ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਸਭ ਕੁਝ ਸਿਹਤਮੰਦ ਦਿਸਦਾ ਹੈ। ਉਸੇ LAN ਦਾ ਡੈਸਕਟਾਪ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਹਾਲਾਂਕਿ Linux ਹੋਸਟ ਵਿੱਚ ਵੀ ਬ੍ਰਿਜ ਇੰਟਰਫੇਸ ਹੈ ਅਤੇ ਦੋਵੇਂ ਮਸ਼ੀਨਾਂ ਇੱਕੋ ਤਾਰ ’ਤੇ ਹਨ। ਟਨਲ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਕਨਫਿਗਰ ਨਹੀਂ ਹੈ; ਗੁੰਮ ਹਿੱਸਾ ਰਾਊਟਿੰਗ ਹੈ, ਅਤੇ ਬ੍ਰਿਜ ਇੱਕ ਭਰਮਾਉਣ ਵਾਲਾ ਸੁਰਾਗ ਹੈ।

Client VPN ਸੈਸ਼ਨ ਨੂੰ LAN ਤੱਕ ਵਧਾਉਣਾ ਗੇਟਵੇ ਦੀ ਭੂਮਿਕਾ ਹੈ। ਇਹ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਵਿੱਚ ਖਿੱਚਿਆ Ethernet ਖੰਡ ਨਹੀਂ ਹੈ।

ਹੋਸਟ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ LAN ਨਹੀਂ

Linux ਮਸ਼ੀਨ ’ਤੇ ਟਨਲ ਇੰਟਰਫੇਸ ਦਾ ਪਤਾ Client VPN ਕਲਾਇੰਟ CIDR ਦੇ ਅੰਦਰ ਹੈ, ਅਤੇ ਐਂਡਪੌਇੰਟ ਨੇ VPC ਰੇਂਜਾਂ ਲਈ ਰਾਊਟ ਭੇਜੇ ਹਨ। ਉਸ ਮਸ਼ੀਨ ’ਤੇ ਕੀਤੀ ਬੇਨਤੀ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਣਾਈ ਟ੍ਰੈਫਿਕ ਹੈ: ਇਹ ਰਾਊਟ ਚੁਣਦੀ ਹੈ, ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ। ਉਹ ਰਾਹ ਕਦੇ ਫਾਰਵਰਡਿੰਗ ਕੋਡ, LAN ਇੰਟਰਫੇਸ ਜਾਂ ਟ੍ਰਾਂਜ਼ਿਟ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ।

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

ਹਰ ਕਲਾਇੰਟ ਗੇਟਵੇ ਨਹੀਂ ਬਣ ਸਕਦਾ

AWS ਦੱਸਦਾ ਹੈ ਕਿ ਇਸ ਦੀ Client VPN ਡੈਸਕਟਾਪ ਐਪ IP ਫਾਰਵਰਡਿੰਗ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਹੋਰ ਕਲਾਇੰਟ ਕਰ ਸਕਦੇ ਹਨ। ਉਹ ਪਾਬੰਦੀ ਕੋਈ ਵੀ ਕਮਾਂਡ ਟਾਈਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਰਕੀਟੈਕਚਰ ਤੈਅ ਕਰਦੀ ਹੈ। ਜੇ ਉਪਲਬਧ ਇੱਕੋ ਕਲਾਇੰਟ ਅਧਿਕਾਰਤ ਡੈਸਕਟਾਪ ਐਪ ਹੈ, ਤਾਂ LAN ਲਈ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲਾ Linux ਗੇਟਵੇ ਉਹ ਸੰਰਚਨਾ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਪੂਰੀ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਕੋਈ ਵੀ ਮਾਤਰਾ masquerading ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲੇਗੀ।

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

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

LAN ਨੂੰ ਟਨਲ ਵੱਲ ਭੇਜੋ ਅਤੇ ਇਸ ਦਾ ਅਨੁਵਾਦ ਕਰੋ

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

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

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

ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ LAN ਰਾਊਟ ਆਪਣੇ ਆਪ ਆਉਣ ਦਿਓ: DHCP ਵਿਕਲਪ, ਰਾਊਟਰ ਘੋਸ਼ਣਾ, ਜਾਂ LAN ਦਾ ਪ੍ਰਬੰਧ ਕਰਨ ਵਾਲੇ ਵੱਲੋਂ ਭੇਜਿਆ ਸਥਿਰ ਰਾਊਟ। ਸਿਰਫ਼ ਇੱਕ ਟੈਸਟ ਮਸ਼ੀਨ ’ਤੇ ਮੌਜੂਦ ਰਾਊਟ ਡਿਜ਼ਾਈਨ ਨੂੰ ਉਸ ਪਲ ਟੁੱਟਿਆ ਦਿਖਾਏਗਾ ਜਦੋਂ ਕੋਈ ਹੋਰ ਇਸ ਨੂੰ ਅਜ਼ਮਾਏਗਾ।

ਜਵਾਬ ਨੂੰ ਵੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ

ਬੇਨਤੀ VPC ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ, ਜਵਾਬ ਨੂੰ ਉਹਨਾਂ ਹੀ ਅਨੁਵਾਦ ਅਵਸਥਾਵਾਂ ਰਾਹੀਂ ਵਾਪਸ ਆ ਕੇ ਗੇਟਵੇ ’ਤੇ LAN ਰਾਊਟ ਲੱਭਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਹਿੱਸਾ ਆਮ ਤੌਰ ’ਤੇ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ masquerade ਨਿਯਮ ਮੌਜੂਦ ਹੋਵੇ, ਕਿਉਂਕਿ ਮੈਪਿੰਗ ਉਸ ਹੋਸਟ ’ਤੇ ਰਹਿੰਦੀ ਹੈ ਜਿਸ ਨੇ ਇਹ ਕੀਤਾ। ਇਹ ਤਦ ਟੁੱਟਦਾ ਹੈ ਜਦੋਂ VPC ਪਾਸੇ ਅਜਿਹਾ ਰਾਊਟ ਹੋਵੇ ਜੋ ਜਵਾਬ ਕਿਤੇ ਹੋਰ ਭੇਜੇ, ਅਤੇ ਇਸੇ ਲਈ ਕਲਾਇੰਟ CIDR ਰਾਊਟ ਅਤੇ ਐਂਡਪੌਇੰਟ ’ਤੇ ਸਬਨੈੱਟ ਜੁੜਾਅ ਦੋਵੇਂ ਮਹੱਤਵਪੂਰਨ ਹਨ।

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

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

ਸਾਂਝੀ ਪਛਾਣ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸ ਦਾ ਜਵਾਬ ਨੀਤੀ ਨੇ ਦੇਣਾ ਹੈ

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

ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹੀ ਡਿਜ਼ਾਈਨ ਦੇ ਰੱਦ ਹੋਣ ਦਾ ਕਾਰਨ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ VPC ਸਰੋਤ ਕੌਣ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ ਬਾਰੇ ਕੀ ਮੰਨਦੇ ਹਨ। ਮਨਜ਼ੂਰੀ ਮਾਡਲ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਵਾਲੀ ਸਾਂਝੀ ਪਛਾਣ ਠੀਕ ਹੈ; ਜੋ ਚੁੱਪਚਾਪ ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਸੈਸ਼ਨ ਨੂੰ ਪੂਰੇ LAN ਦੀ ਪਹੁੰਚ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਉਹ ਲਿਖੇ ਜਾਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਖੋਜ ਹੈ।

ਜੇ ਲੋੜ ਸੱਚਮੁੱਚ ਪੂਰੀ ਸਾਈਟ ਨੂੰ VPC ਨਾਲ ਜੋੜਨ ਦੀ ਹੈ, ਤਾਂ ਰਿਮੋਟ-ਪਹੁੰਚ ਕਲਾਇੰਟ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਮਰਥਿਤ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਡਿਜ਼ਾਈਨ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਅਰਥ ਵੱਖਰਾ ਹੈ, ਅਤੇ ਜਦੋਂ VPC ਨੂੰ LAN ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨੇ ਹੋਣ ਤਾਂ NAT ਕੀਤਾ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਸਾਈਟ ਲਿੰਕ ਲਈ ਮਾੜਾ ਬਦਲ ਹੈ।

ਕਲਾਇੰਟ, ਰਾਊਟ, ਅਨੁਵਾਦ ਅਤੇ ਪਛਾਣ ਦੀ ਕਹਾਣੀ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਤੈਅ ਕਰੋ। ਹਰ ਇੱਕ ਅਗਲੇ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕ੍ਰਮ ਦੱਸਦਾ ਹੈ ਕਿ ਹੋਸਟ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ LAN ਨਹੀਂ।