ਤੁਹਾਡੇ ਹੌਟਸਪੌਟ ਦਾ ਫਾਇਰਵਾਲ ਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ DHCP ਨੂੰ ਰੋਕਦਾ ਹੈ

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

ਕਲਾਇੰਟ ਦੇ ਜੁੜਨ ਨੂੰ ਵੇਖੋ

ਕਲਾਇੰਟ ਵੱਲੋਂ ਇੱਕ ਸੰਬੰਧ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਰੇਡੀਓ ਜੁੜਦਾ ਹੈ, ਕਲਾਇੰਟ DHCP ਖੋਜ ਭੇਜਦਾ ਹੈ, ਸਰਵਰ ਪੇਸ਼ਕਸ਼ ਦਿੰਦਾ ਹੈ, ਕਲਾਇੰਟ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਕਲਾਇੰਟ ਕੋਲ ਕਿਸੇ ਹੋਰ ਕੰਮ ਲਈ ਵਰਤੋਂਯੋਗ ਪਤਾ ਹੁੰਦਾ ਹੈ।

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

ਪਹਿਲੇ ਪੈਕਟ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ

RFC 2131 ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਪਤਾ ਮਿਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦੇ DHCP ਪ੍ਰਸਾਰਣ ਸਿਫ਼ਰ ਸਰੋਤ ਪਤਾ ਵਰਤਦੇ ਹਨ। ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਵੱਲ ਸੁਨੇਹੇ UDP ਪੋਰਟ 67 'ਤੇ, ਅਤੇ ਸਰਵਰ ਤੋਂ ਕਲਾਇੰਟ ਵੱਲ ਸੁਨੇਹੇ UDP ਪੋਰਟ 68 'ਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਲਈ ਖੋਜ 0.0.0.0 ਨੂੰ ਸਰੋਤ ਬਣਾ ਕੇ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰ ਸਰੋਤ ਮੰਗਣ ਵਾਲਾ ਨਿਯਮ ਉਸ ਨਾਲ ਸਿੱਧਾ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।

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

ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਾਹ ਇਸ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ

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

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

ਫੋਰਮ ਤੋਂ ਨਕਲ ਕੀਤੀ ਆਮ ਇਨਪੁਟ/ਆਉਟਪੁਟ ਵਿਧੀ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਤੁਹਾਡਾ ਅਮਲ ਉਹਨਾਂ ਚੇਨਾਂ ਵਿੱਚੋਂ ਉਸੇ ਤਰ੍ਹਾਂ ਲੰਘਦਾ ਹੈ।

ਜਵਾਬ ਹਮੇਸ਼ਾ ਪ੍ਰਸਾਰਣ ਨਹੀਂ ਹੁੰਦਾ

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

ਬਾਅਦ ਦੇ ਲੀਜ਼ ਨਵੀਨੀਕਰਨ ਵੱਖਰੀ ਸਥਿਤੀ ਵਿੱਚ ਉਹੀ ਅਦਲਾ-ਬਦਲੀ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਸਿਰਫ਼ ਪਹਿਲੇ ਜੁੜਨ ਲਈ ਨਹੀਂ, ਉਹਨਾਂ ਲਈ ਵੀ ਥਾਂ ਛੱਡੋ।

ਤੰਗ ਰੂਪ ਵਿੱਚ ਸੁਧਾਰੋ, ਫਿਰ ਬਾਕੀ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਟੇਬਲ ਫਲਸ਼ ਕਰਨਾ DHCP ਸੰਰਚਨਾ ਦਾ ਕਦਮ ਨਹੀਂ ਹੈ। iptables ਵਿੱਚ flush ਚੁਣੀ ਚੇਨ ਜਾਂ ਟੇਬਲ ਤੋਂ ਨਿਯਮ ਹਟਾਉਂਦਾ ਹੈ, ਅਤੇ NAT ਟੇਬਲ ਫਲਸ਼ ਕਰਨ ਨਾਲ ਅਨੁਵਾਦ ਨਿਯਮ ਨਹੀਂ ਬਣਦਾ। ਚੌੜੀਆਂ ACCEPT ਨੀਤੀਆਂ ਲਗਾਉਣ ਨਾਲ ਲੀਜ਼ ਨਾਲ ਸੰਬੰਧ ਰਹਿਤ ਸੁਰੱਖਿਆ ਹਟ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਹੌਟਸਪੌਟ ਸੁਧਾਰ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ।

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