ਤੁਹਾਡਾ iptables ਨਿਯਮ ਬ੍ਰਿਜ ਕੀਤੇ VPN ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਦੇ ਕਿਉਂ ਨਹੀਂ ਦੇਖਦਾ
ਬ੍ਰਿਜ ਕੀਤੇ ਫਰੇਮ ਉਸ IP ਚੇਨ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੇ ਹਨ ਜਿਸ ਦੀ ਤੁਸੀਂ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ ਹੋ। ਹੋਰ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਮੂਲ bridge ਪਰਿਵਾਰ ਦੀ ਤੁਲਨਾ ਪੁਰਾਣੇ br_netfilter ਨਾਲ ਕਰੋ।
ਇੱਕੋ ਹੋਸਟ 'ਤੇ ਦੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬ੍ਰਿਜ ਰਾਹੀਂ LAN ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ, ਅਤੇ ip forward ਚੇਨ ਵਿੱਚ ਰੱਖਿਆ ਨਿਯਮ ਉਹ ਕਾਊਂਟਰ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਹਿੱਲਦਾ। ਫਰੇਮ ਅਸਲੀ ਹਨ, ਟ੍ਰੈਫਿਕ ਲੰਘ ਰਿਹਾ ਹੈ, ਅਤੇ ਨਿਯਮ ਬੱਸ ਉਸ ਦੇ ਰਾਹ 'ਤੇ ਨਹੀਂ ਹੈ। Linux ਬ੍ਰਿਜ ਟ੍ਰੈਫਿਕ ਦਿਖਾਉਣ ਦੇ ਦੋ ਤਰੀਕਿਆਂ ਦੀ ਤੁਲਨਾ ਇਸ ਚੁੱਪ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਕ ਪੁਰਾਣਾ ਮੌਡਿਊਲ ਲੋਡ ਕਰਨਾ ਦਿਖਣ ਨਾਲੋਂ ਕਿਉਂ ਮਾੜਾ ਜਵਾਬ ਹੈ।
ਇੱਕ ਹੋਸਟ ਰਾਹੀਂ ਦੋ ਰਾਹ
ਪੈਕੇਟ ਇਸ ਹੋਸਟ ਨੂੰ ਦੋ ਬਹੁਤ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਛੱਡ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਹੁੱਕ ਇਸਨੂੰ ਦੇਖਣਗੇ। ਜੇ ਮੰਜ਼ਿਲ ਕਿਸੇ ਭੌਤਿਕ ਪੋਰਟ ਤੋਂ ਪਾਰ ਹੈ ਅਤੇ ਫਰੇਮ ਬ੍ਰਿਜ ਦੇ ਦੋ ਪੋਰਟਾਂ ਵਿਚਕਾਰ ਸਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹੋਸਟ ਇੱਕ Ethernet ਫਰੇਮ ਅੱਗੇ ਭੇਜਦਾ ਹੈ; ਰੂਟਿੰਗ ਕੋਡ ਨਹੀਂ ਪੁੱਛਿਆ ਜਾਂਦਾ, ਅਤੇ ਕੋਈ ਰੂਟਡ ਹੌਪ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਮੰਜ਼ਿਲ ਹੋਸਟ ਆਪਣਾ ਹੈ, ਜਾਂ ਟਨਲ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਹੈ, ਤਾਂ ਪੈਕੇਟ ਰੂਟ ਹੁੰਦਾ ਹੈ ਅਤੇ IP ਪਰਤ ਦੇ ਹੁੱਕ ਸੱਚਮੁੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਇਹ ਫੁੱਟ ਯਾਦ ਰੱਖੋ, ਕਿਉਂਕਿ ਚੇਨਾਂ ਅਤੇ ਪਰਿਵਾਰਾਂ ਬਾਰੇ ਹਰ ਅਗਲਾ ਸਵਾਲ ਇਸੇ ਗੱਲ ਤੋਂ ਆਉਂਦਾ ਹੈ ਕਿ ਫਰੇਮ ਦੋ ਰਾਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਲੈਂਦਾ ਹੈ।
ਇਹ ਫ਼ਰਕ ਉਸ ਨਿਯਮ ਪਿੱਛੇ ਦੀ ਪੂਰੀ ਕਹਾਣੀ ਹੈ ਜੋ ਕੁਝ ਵੀ ਨਹੀਂ ਗਿਣਦਾ। veth9a1 ਤੋਂ enp3s0 ਤੱਕ ਬ੍ਰਿਜ ਕੀਤਾ ਫਰੇਮ IP ਸਟੈਕ ਨਹੀਂ, ਬ੍ਰਿਜ ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ip forward ਚੇਨ ਨੂੰ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਨਹੀਂ ਦਿਸਦਾ। ਪੁਰਾਣੇ ਉਦਾਹਰਨ ਵਿੱਚ ਇੰਟਰਫੇਸ ਨਾਮ ਤੈਅ ਨਹੀਂ ਕਰਦੇ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਰਾਹ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਪਹਿਲਾ ਕਦਮ ਨਿਯਮ-ਸਮੂਹ ਵੱਲ ਨਹੀਂ, ਟੋਪੋਲੋਜੀ ਵੱਲ ਦੇਖਣਾ ਹੈ।
ਟਨਲ ਇੱਕ ਤੀਜਾ ਕੇਸ ਜੋੜਦੀ ਹੈ ਜੋ ਨਾਮ ਦੇਣ ਯੋਗ ਹੈ। TUN ਡਿਵਾਈਸ ਹੋਸਟ ਨੂੰ IP ਪੈਕੇਟ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਉਹ ਰੂਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸੱਚਮੁੱਚ IP ਚੇਨਾਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਬ੍ਰਿਜ ਨਾਲ ਜੁੜੀ TAP ਡਿਵਾਈਸ ਫਰੇਮ ਦਿੰਦੀ ਹੈ ਅਤੇ ਬ੍ਰਿਜ ਵਾਲੇ ਕੇਸ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਡਿਵਾਈਸ ਦੀ ਕਿਸਮ ਤੈਅ ਕਰਦੀ ਹੈ, ਉਤਪਾਦ ਦਾ ਨਾਮ ਨਹੀਂ।
ਬ੍ਰਿਜ ਕੀਤਾ ਫਰੇਮ ਦੇਖ ਸਕਣ ਵਾਲੇ ਦੋ ਪਰਿਵਾਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
Linux nftables ਦੇ bridge ਪਰਿਵਾਰ ਰਾਹੀਂ ਮੂਲ ਬ੍ਰਿਜ ਫਿਲਟਰਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਉੱਡਦੇ ਫਰੇਮਾਂ ਦੀ ਜਾਂਚ ਕਰਕੇ ਸੁੱਟਣ ਲਈ ਇਸਨੂੰ ਕਿਸੇ ਪੁਰਾਣੇ ਮੌਡਿਊਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਕਰਨਲ ਦਾ ਆਪਣਾ ਬ੍ਰਿਜ ਦਸਤਾਵੇਜ਼ ਸਿੱਧੀ ਇਹ ਸਿਫ਼ਾਰਸ਼ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿਸੇ ਖੋਜ ਨਤੀਜੇ ਦੇ ਤੁਹਾਨੂੰ ਮੌਡਿਊਲ ਲੋਡ ਕਰਨ ਲਈ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣਨਾ ਲਾਹੇਵੰਦ ਹੈ।
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
iptables ਦੀ ਥਾਂ nft ਕਮਾਂਡ ਵਰਤਣਾ ਆਪਣੇ ਆਪ ਨਿਯਮ ਨੂੰ ਸਹੀ ਪਰਿਵਾਰ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ। bridge ਪਰਿਵਾਰ ਵਿੱਚ ਐਲਾਨੀ ਚੇਨ ਫਰੇਮ ਦੇਖਦੀ ਹੈ; ip, ip6 ਜਾਂ inet ਵਿੱਚ ਐਲਾਨੀ ਚੇਨ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖਦੀ, ਭਾਵੇਂ ਇਸਨੂੰ ਕੋਈ ਵੀ ਬਾਈਨਰੀ ਬਣਾਈ ਹੋਵੇ। ਪਰਿਵਾਰ ਚੇਨ ਦਾ ਗੁਣ ਹੈ, ਟਾਈਪ ਕਰਨ ਵਾਲੇ ਸਾਧਨ ਦਾ ਨਹੀਂ।
ਪੁਰਾਣਾ ਰਾਹ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਆਦਤ ਨਾਲ ਧਿਰ ਚੁਣਨ ਦੀ ਥਾਂ ਤੁਲਨਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। br_netfilter ਲੋਡ ਕਰਨ ਅਤੇ bridge-nf-call ਸੈਟਿੰਗਾਂ ਸਮਰਥਿਤ ਕਰਨ ਨਾਲ ਬ੍ਰਿਜ ਕੀਤਾ IPv4 ਅਤੇ IPv6 ਟ੍ਰੈਫਿਕ ਦੁਬਾਰਾ IP ਪਰਤ ਦੇ ਹੁੱਕਾਂ ਰਾਹੀਂ ਬਾਹਰ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਆਮ iptables ਨਿਯਮ ਆਖ਼ਰ ਇਸ ਨਾਲ ਮੇਲ ਖਾ ਸਕੇ। ਫਰੇਮ ਨਹੀਂ ਬਦਲਦੇ; ਜਿਨ੍ਹਾਂ ਹੁੱਕਾਂ ਵਿੱਚੋਂ ਉਹ ਲੰਘਦੇ ਹਨ ਉਹ ਸਮੂਹ ਬਦਲਦਾ ਹੈ, ਜਿਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਮੌਜੂਦਾ ਹੋਸਟ ਨਿਯਮ ਕੋਲ ਹੁਣ ਨਵਾਂ ਦਰਸ਼ਕ ਵਰਗ ਹੈ।
ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਰਾਹ ਪੜ੍ਹੋ
ਤਿੰਨ ਕਮਾਂਡਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਹੋ: ਬ੍ਰਿਜ ਕਿਸ ਨਾਲ ਜੁੜੀ ਹੈ, ਪੁਰਾਣਾ ਮੌਡਿਊਲ ਸਕਿਰਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ bridge ਪਰਿਵਾਰ ਵਿੱਚ ਕਿਹੜੀਆਂ ਚੇਨਾਂ ਪਹਿਲਾਂ ਹੀ ਹਨ। ਕੁਝ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਚਲਾਓ, ਕਿਉਂਕਿ ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਦੋ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਵਧਾ ਰਹੇ ਹੋ। ਇਹ ਕਦਮ ਛੱਡਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਸਹੀ ਨਿਯਮ ਅਜਿਹੀ ਚੇਨ ਵਿੱਚ ਪੈ ਜਾਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਲੰਘਦਾ।
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"ਆਊਟਪੁੱਟ ਕੇਸਾਂ ਨੂੰ ਸਾਫ਼ ਵੱਖਰਾ ਕਰਦਾ ਹੈ। ਬ੍ਰਿਜ ਹੇਠ ਸੂਚੀਬੱਧ ਪੋਰਟ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਸਵਿੱਚ ਹੋ ਰਹੇ ਹਨ; ਖਾਲੀ lsmod ਨਤੀਜੇ ਦਾ ਮਤਲਬ ਹੈ ਬ੍ਰਿਜ ਕੀਤੇ ਫਰੇਮਾਂ ਦੀ IP ਪਰਤ 'ਤੇ ਕੋਈ ਦਿੱਖ ਨਹੀਂ; ਮੌਜੂਦਾ bridge ਪਰਿਵਾਰ ਦੀ forward ਚੇਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨੀਤੀ ਦਾ ਮਾਲਕ ਪਹਿਲਾਂ ਹੀ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਨਿਯਮ ਆਪਣੀ ਨਵੀਂ ਚੇਨ ਵਿੱਚ ਨਹੀਂ, ਉੱਥੇ ਹੀ ਜਾਂਦਾ ਹੈ।
ਫਿਰ ਮੁੜ ਪੜ੍ਹਨ ਵਿੱਚ ਸੌਖਾ ਇੱਕ ਨਿਯਮ ਜੋੜੋ, ਕਾਊਂਟਰ ਨਾਲ ਅਤੇ ਫ਼ੈਸਲਾ ਬਦਲੇ ਬਿਨਾਂ, ਅਤੇ ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਪ੍ਰਵਾਹ ਬ੍ਰਿਜ ਵਿੱਚੋਂ ਲੰਘਾਓ। ਹਿੱਲਦਾ ਕਾਊਂਟਰ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਫਰੇਮ ਨਿਯਮ ਤੱਕ ਪਹੁੰਚਿਆ। ਏਨਾ ਹੀ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਰੱਦ ਕੀਤੇ ਰਾਹ ਨਾਲ ਵੀ ਅੱਗੇ ਵਧੋ, ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਵੀ ਹਿੱਲਦਾ ਕਾਊਂਟਰ ਪੈਦਾ ਕਰਦੀ ਹੈ।
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptਪੁਰਾਣਾ ਮੌਡਿਊਲ ਵਿਵਹਾਰ ਕਿੱਥੇ ਬਦਲਦਾ ਹੈ
ਚੱਲ ਰਹੀ ਬ੍ਰਿਜ 'ਤੇ ਪੁਰਾਣਾ ਰਾਹ ਸਮਰਥਿਤ ਕਰਨਾ ਦਿੱਖ ਜੋੜਨ ਦੀ ਅਣਪੱਖੀ ਕਿਰਿਆ ਨਹੀਂ ਹੈ। ਜੋ ਨਿਯਮ ਪਹਿਲਾਂ ਬ੍ਰਿਜ ਟ੍ਰੈਫਿਕ ਲਈ ਅਪਹੁੰਚ ਸਨ ਉਹ ਪਹੁੰਚਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਦੂਜੇ ਇੰਟਰਫੇਸ ਲਈ ਲਿਖੇ ਹੋਸਟ ਨਿਯਮ ਵੀ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ip forward ਚੇਨ ਦੀ ਡਿਫ਼ਾਲਟ drop ਨੀਤੀ ਅਚਾਨਕ ਉਹਨਾਂ ਫਰੇਮਾਂ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਛੋਹੇ ਬਿਨਾਂ ਲੰਘਦੇ ਸਨ। ਜਿਸ ਹੋਸਟ ਦਾ ਪ੍ਰਬੰਧਨ ਉਸੇ ਬ੍ਰਿਜ ਰਾਹੀਂ ਹੁੰਦਾ ਹੈ, ਉੱਥੇ ਨਤੀਜਾ ਕੰਸੋਲ ਤੋਂ ਬਿਨਾਂ ਲਾਕਆਊਟ ਹੈ। ਇਹ ਕਾਲਪਨਿਕ ਫੇਲ੍ਹ ਮੋਡ ਨਹੀਂ ਹੈ; ਇਹ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਚੌੜਾ ਕੀਤੇ ਰਾਹ ਰਾਹੀਂ ਪਹੁੰਚਦੀ ਮਸ਼ੀਨ 'ਤੇ ਹੁੱਕਾਂ ਦਾ ਸਮੂਹ ਚੌੜਾ ਕਰਨ ਦਾ ਆਮ ਨਤੀਜਾ ਹੈ।
ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਕ੍ਰਮ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਪਰਿਵਾਰ ਨੀਤੀ ਦਾ ਮਾਲਕ ਹੈ ਤੈਅ ਕਰੋ, ਨਿਯਮ ਉੱਥੇ ਲਿਖੋ, ਅਤੇ ਕੋਈ ਵੀ sysctl ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਤੰਤਰ ਬਹਾਲੀ ਰਾਹ ਰੱਖੋ। ਜੇ ਦੋਵੇਂ ਪਰਿਵਾਰ ਨਿਯਮ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਕਿਹੜਾ ਅਧਿਕਾਰਤ ਹੈ; ਦੋ ਓਵਰਲੈਪ ਹੁੰਦੀਆਂ ਨੀਤੀਆਂ ਹੀ ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ ਪੈਕੇਟ ਇੱਕ ਥਾਂ ਸਵੀਕਾਰ ਅਤੇ ਦੂਜੀ ਥਾਂ ਰੱਦ ਹੁੰਦਾ ਹੈ, ਪੜ੍ਹਨ ਲਈ ਇੱਕ ਵੀ ਫਾਈਲ ਤੋਂ ਬਿਨਾਂ।
ਅਲੱਗਾਉਣ ਨੂੰ ਆਪਣੇ ਆਪ ਹੀ ਅਜੇ ਪੂਰੀ ਡਿਜ਼ਾਈਨ ਲੋੜੀਂਦੀ ਹੈ। ਇੱਕ ਸਰੋਤ ਨੂੰ ਇੱਕ ਮੰਜ਼ਿਲ ਤੱਕ ਆਗਿਆ ਦੇਣਾ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰਵਾਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਲੋੜ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ VM ਆਪਣੇ ਗੁਆਂਢੀਆਂ ਜਾਂ ਹੋਸਟ ਤੱਕ ਨਾ ਪਹੁੰਚ ਸਕੇ। ਰੱਦ ਨਿਯਮਾਂ ਦੇ ਕਾਊਂਟਰ ਸਵੀਕਾਰ ਨਿਯਮ ਦੇ ਕਾਊਂਟਰ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਕਿਉਂਕਿ ਸਵੀਕਾਰ ਕਾਊਂਟਰ ਉਹੀ ਹੈ ਜਿਸ ਦੇ ਹਿੱਲਣ ਦੀ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਆਸ ਰੱਖੀ ਸੀ।
ਅੰਤ ਵਿੱਚ, ਹੋਸਟ-ਇਨਪੁੱਟ ਕੇਸ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ। ਬ੍ਰਿਜ ਦੇ ਆਪਣੇ IP 'ਤੇ ਭੇਜਿਆ ਟ੍ਰੈਫਿਕ input 'ਤੇ ਆਉਂਦਾ ਹੈ, forward 'ਤੇ ਨਹੀਂ, ਅਤੇ forward ਦਾ ਨਿਯਮ ਤੁਸੀਂ ਕੋਈ ਵੀ ਪਰਿਵਾਰ ਚੁਣੋ, ਇਸਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖੇਗਾ। ਤਿੰਨ ਕੇਸ, ਦੋ ਪਰਿਵਾਰ, ਇੱਕ ਪਾਠ: ਰਾਹ ਹੁੱਕ ਤੈਅ ਕਰਦਾ ਹੈ, ਅਤੇ ਹੁੱਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਨਿਯਮ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ।