SSH ਅਤੇ VPN ਇਨਗ੍ਰੇਸ ਨਿਯਮ: ਅਨੁਮਤੀ-ਸੂਚੀ ਅਸਲ ਵਿੱਚ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ

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

ਇੱਕ SSH ਕੋਸ਼ਿਸ਼ ਦਾ ਇਨਪੁਟ ਹੁੱਕ ਤੱਕ ਪਿੱਛਾ ਕਰੋ

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

ਫਿਰ ਸਰੋਤੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਨਾ-ਮੌਜੂਦ ਸੇਵਾ ਨੂੰ ਕੋਈ ਨਿਯਮ ਨਹੀਂ ਬਚਾ ਸਕਦਾ। ss -ltnp ਚਲਾਓ ਅਤੇ ਜਾਂਚੋ ਕਿ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਪੋਰਟ ਅਤੇ ਪਤਾ-ਪਰਿਵਾਰ ਨਾਲ ਕੁਝ ਬੱਝਿਆ ਹੈ, ਫਿਰ ਕਲਾਇੰਟ ਉੱਤੇ ssh -v ਪੜ੍ਹੋ ਤਾਂ ਜੋ ਪਤਾ ਲੱਗੇ ਕਿ ਇਹ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ।

ਫ਼ਾਰਵਰਡਿੰਗ ਇੱਕ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਹੈ

VPN ਸਰਵਰ ਉੱਤੇ ਵਧੇਰੇ ਦਿਲਚਸਪ ਹੁੱਕ forward ਹੈ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਟ੍ਰੈਫ਼ਿਕ ਮਸ਼ੀਨ ਨੂੰ ਸੌਂਪਣ ਦੀ ਬਜਾਏ ਉਸ ਵਿੱਚੋਂ ਰੂਟ ਹੁੰਦਾ ਹੈ। ਜਿਹੜਾ ਹੋਸਟ ਸਿਰਫ਼ ਆਪਣਾ VPN ਕਲਾਇੰਟ ਚਲਾਉਂਦਾ ਹੈ ਉਸਨੂੰ ਦੂਜਿਆਂ ਦੇ ਪੈਕਟ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਹੋਸਟ ਨਾਲੋਂ ਬਹੁਤ ਛੋਟਾ ਨਿਯਮ-ਸਮੂਹ ਚਾਹੀਦਾ ਹੈ। ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਇੱਕ ਮਸ਼ੀਨ ਉੱਤੇ ਮਿਲਾਉਣ ਨਾਲ ਅਜਿਹੇ ਨਿਯਮ ਬਣਦੇ ਹਨ ਜੋ ਸਹੀ ਦਿਸਦੇ ਹਨ ਅਤੇ ਕੁਝ ਵੀ ਲੰਘਣ ਨਹੀਂ ਦਿੰਦੇ।

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

ਡ੍ਰੌਪ ਅਤੇ ਰਿਜੈਕਟ ਕਿਰਿਆਵਾਂ ਹਨ, ਨੀਤੀਆਂ ਨਹੀਂ

ਬੇਸ ਚੇਨ ਦੀ ਨੀਤੀ ਸਵੀਕਾਰ ਜਾਂ ਡ੍ਰੌਪ ਕਰਦੀ ਹੈ, ਅਤੇ ਚੋਣਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਇਹੀ ਹੈ, ਜਿਵੇਂ nftables ਸੰਦਰਭ ਕਹਿੰਦਾ ਹੈ। ਰਿਜੈਕਟ ਇੱਕ ਚੁਣੇ ਜਵਾਬ ਵਾਲੀ ਨਿਯਮ-ਕਿਰਿਆ ਵਜੋਂ ਮੌਜੂਦ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਨੀਤੀ ਵਜੋਂ ਲਿਖਣਾ nftables ਅਤੇ iptables ਦੋਵਾਂ ਉੱਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਵਿਵਹਾਰ ਵਿੱਚ drop ਕਲਾਇੰਟ ਨੂੰ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੰਦਾ, ਜਦਕਿ reject ਉਸਨੂੰ ਅਜਿਹੀ ਗਲਤੀ ਦਿੰਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਉਹ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

ਸੱਚਮੁੱਚ ਲੋੜੀਂਦਾ ਨਿਯੰਤਰਣ ਟ੍ਰੈਫ਼ਿਕ ਰੱਖੋ

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

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

ਪੁਰਾਣੇ ਮਾਰਗ ਨੂੰ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਬਹਾਲੀ ਸਿੱਧ ਕਰੋ

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

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