ਮਾਰਕ-ਅਧਾਰਿਤ VPN ਫਾਇਰਵਾਲ ਵੱਲੋਂ ਰੋਕਿਆ ਗਿਆ libvirt ਗੈਸਟ DNS ਠੀਕ ਕਰੋ

ਡਿਫਾਲਟ libvirt ਨੈੱਟਵਰਕ ਦੇ ਗੈਸਟ WireGuard ਇੰਟਰਫੇਸ ਆਉਣ ਤੱਕ ਨਾਂ ਬਿਲਕੁਲ ਠੀਕ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਹਰ ਲੁੱਕਅੱਪ ਉਸੇ ਥਾਂ 'ਤੇ ਅਟਕ ਜਾਂਦਾ ਹੈ। dnsmasq ਅਜੇ ਵੀ 192.168.122.1:53 'ਤੇ ਸੁਣ ਰਿਹਾ ਹੈ, ਗੈਸਟ ਕੋਲ ਅਜੇ ਵੀ ਉਹੀ ਪਤਾ ਰਿਜ਼ੌਲਵਰ ਵਜੋਂ ਹੈ, ਅਤੇ ਕਵੈਰੀ ਅਜੇ ਵੀ ਪਹੁੰਚਦੀ ਹੈ। ਬਦਲਿਆ ਇਹ ਹੈ ਕਿ ਹੋਸਟ ਦੀ ਆਪਣੀ ਅਪਸਟ੍ਰੀਮ ਕਵੈਰੀ, ਜਾਂ ਉਸ ਦਾ ਜਵਾਬ, ਹੁਣ ਅਜਿਹੇ ਨਿਯਮ ਵੱਲੋਂ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚੋਗੇ ਕਿ ਸੋਧਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਜਿਹੀ ਕਿਸੇ ਵੀ ਫਿਲਟਰ ਚੇਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ। ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਰਾਹ ਹੈ ਜਲਦੀ ਲਾਇਆ ਗਿਆ ਮਾਰਕ, ਅਜਿਹੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਜਿਸ ਨੂੰ ਜਵਾਬ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ।

ਟਨਲ ਉੱਠਦਿਆਂ ਹੀ ਗੈਸਟ ਦਾ DNS ਚਲਾ ਜਾਂਦਾ ਹੈ

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰੂਪ ਪੱਕਾ ਕਰੋ। ਟਨਲ ਹੇਠਾਂ ਕਰੋ, ਗੈਸਟ ਤੋਂ dig @192.168.122.1 example.com ਚਲਾਓ ਅਤੇ ਉਹ ਜਵਾਬ ਦਿੰਦਾ ਵੇਖੋ। ਟਨਲ ਉੱਪਰ ਕਰੋ, ਦੁਹਰਾਓ, ਅਤੇ ਉਹ ਟਾਈਮਆਊਟ ਹੁੰਦਾ ਵੇਖੋ। ਇਹ ਦੋ ਨਤੀਜੇ ਖਰਾਬ libvirt ਨੈੱਟਵਰਕ, ਗਲਤ ਰਿਜ਼ੌਲਵਰ ਪਤਾ ਅਤੇ ਮਰੇ dnsmasq ਨੂੰ ਇੱਕੋ ਕਦਮ ਵਿੱਚ ਰੱਦ ਕਰ ਦਿੰਦੇ ਹਨ।

ਫਿਰ ਹੋਸਟ ਵਾਲਾ ਪਾਸਾ ਵੇਖੋ। ਜੇ dnsmasq ਕਵੈਰੀ ਅਤੇ ਉਸ ਦਾ ਅਪਸਟ੍ਰੀਮ ਫਾਰਵਰਡ ਲੌਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੈਕਟ ਪਹੁੰਚ ਗਿਆ ਹੈ ਅਤੇ ਨਾਕਾਮੀ ਈਗ੍ਰੈੱਸ 'ਤੇ ਹੈ। ਜੇ dnsmasq ਕੁਝ ਵੀ ਲੌਗ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਗੈਸਟ ਕਵੈਰੀ ਇਨਗ੍ਰੈੱਸ 'ਤੇ ਹੀ ਸੁੱਟੀ ਜਾ ਰਹੀ ਹੈ ਅਤੇ ਅਪਵਾਦ ਉਸ ਹੁੱਕ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਲੇਖ ਮਾਰਕ ਕਰਦਾ ਹੈ, ਤੋਂ ਵੱਖਰੇ ਹੁੱਕ 'ਤੇ।

ਪਿਛਲੀ ਚੇਨ ਵਿੱਚਲਾ accept ਨਿਯਮ ਕਦੇ ਕਿਉਂ ਨਹੀਂ ਚੱਲਦਾ

ਮਾਰਕ-ਅਧਾਰਿਤ VPN ਫਾਇਰਵਾਲ ਤੁਹਾਡੇ ਸਰੋਤ ਪਤੇ ਵੱਲ ਨਹੀਂ, ਸਗੋਂ ਪੈਕਟ ਮਾਰਕ ਜਾਂ ਕਨੈਕਸ਼ਨ ਮਾਰਕ ਵੱਲ ਵੇਖ ਕੇ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ। ਭੌਤਿਕ ਇੰਟਰਫੇਸ 'ਤੇ ਬਿਨਾਂ ਉਮੀਦ ਕੀਤੇ ਮਾਰਕ ਦੇ ਆਉਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਰੱਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਰੱਦ ਕਰਨਾ ਉਸ ਨਿਯਮ ਸਮੂਹ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਜਿਸ ਕੋਲ ਮਾਰਕ ਟੈਸਟ ਹੈ। ip saddr 192.168.122.0/24 accept ਲਾਈਨ ਪਿਛਲੀ ਕਿਸੇ ਵੀ ਚੇਨ ਵਿੱਚ ਜੋੜਨ 'ਤੇ ਵੀ ਉਸ ਪੈਕਟ ਲਈ ਕਦੇ ਨਹੀਂ ਵੇਖੀ ਜਾਂਦੀ, ਇਸ ਲਈ ਸਪੱਸ਼ਟ ਦਿਸਣ ਵਾਲਾ ਨਿਯਮ ਸਹੀ ਲੱਗਦਾ ਹੈ ਪਰ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

ਜਦੋਂ ਤੱਕ ਕੁਝ ਕੰਮ ਨਾ ਕਰੇ, ਇਸ ਨੂੰ ਚੌੜਾ ਕਰਨਾ ਦੂਜਾ ਜਾਲ ਹੈ। ਹੋਸਟ ਦੇ input ਰਾਹ ਵਿੱਚ ਪੂਰਾ libvirt ਸਬਨੈੱਟ ਸਵੀਕਾਰ ਕਰਨ ਨਾਲ ਗੈਸਟਾਂ ਲਈ ਹੋਸਟ ਦੀ ਹਰ ਸੇਵਾ ਖੁੱਲ੍ਹ ਜਾਂਦੀ ਹੈ, ਜਦਕਿ ਅਸਲ ਲੋੜ ਇੱਕੋ ਪੋਰਟ ਦੀ ਹੈ।

ਸੰਕੀਰਣ ਅਪਵਾਦ ਸੰਭਵ ਕਰਨ ਵਾਲਾ ਤੰਤਰ ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਪੈਕਟ 'ਤੇ ct mark ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਮੁੱਲ ਸਿਰਫ਼ ਪੈਕਟ 'ਤੇ ਨਹੀਂ ਸਗੋਂ conntrack ਐਂਟਰੀ 'ਤੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਸ ਕਨੈਕਸ਼ਨ ਦਾ ਹਰ ਪੈਕਟ ਬਾਅਦ ਵਿੱਚ ਉਹ ਢੋਂਦਾ ਹੈ, ਹੋਸਟ ਤੋਂ ਗੈਸਟ ਵੱਲ ਮੁੜਨ ਵਾਲਾ ਜਵਾਬ ਵੀ। ਇਹੀ ਪੂਰੀ ਚਾਲ ਹੈ: ਬੇਨਤੀ ਇੱਕ ਵਾਰ ਮਾਰਕ ਕਰੋ, ਅਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ ਪਹਿਲਾਂ ਹੀ ਮਾਰਕ ਹੋ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ।

VPN ਟੇਬਲ ਦੇ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਵੈਰੀ ਮਾਰਕ ਕਰੋ

ਅਪਵਾਦ ਨੂੰ ਆਪਣੀ ਵੱਖਰੀ ਟੇਬਲ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਾਲਾ ਪਾਠਕ VPN ਨਿਯਮ ਪਾਰਸ ਕੀਤੇ ਬਿਨਾਂ ਉਹ ਲੱਭ ਸਕੇ:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle ਰਿਣਾਤਮਕ ਹੈ, ਜੋ ਇਸ ਚੇਨ ਨੂੰ VPN ਪੈਕੇਜ ਵੱਲੋਂ ਪ੍ਰਾਇਰਿਟੀ ਜ਼ੀਰੋ 'ਤੇ ਲਾਏ ਜਾਣ ਵਾਲੇ ਆਮ ਫਿਲਟਰ ਚੇਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖਦਾ ਹੈ। ਹੁੱਕ ਦਾ ਕ੍ਰਮ ਹੀ ਨਿਯਮ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਂਦਾ ਹੈ; VPN ਚੇਨ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੀ ਚੇਨ ਵਿੱਚ ਉਹੀ ਨਿਯਮ ਸਿਰਫ਼ ਸਜਾਵਟ ਹੈ।

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

ਮੋਰੀ ਨੂੰ ਪੋਰਟ 53 ਜਿੰਨੀ ਚੌੜੀ ਹੀ ਰੱਖੋ

ਜਿਵੇਂ ਲਿਖਿਆ ਹੈ, ਇਹ libvirt ਸਬਨੈੱਟ ਤੋਂ ਹੋਸਟ ਤੱਕ TCP ਜਾਂ UDP ਪੋਰਟ 53 'ਤੇ DNS ਦਿੰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਇਹ ਗੈਸਟਾਂ ਨੂੰ ਟਨਲ ਤੋਂ ਬਾਹਰ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਹੋਸਟ ਨੂੰ ਗੈਸਟਾਂ ਵੱਲ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਨਹੀਂ ਦਿੰਦਾ। ਜੇ ਕਿਸੇ ਗੈਸਟ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਹੋਸਟ ਸੇਵਾ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਸ ਨਿਯਮ ਨੂੰ ਢਿੱਲਾ ਕਰਨ ਦੀ ਥਾਂ ਉਸ ਮੰਜ਼ਿਲ ਪੋਰਟ ਦਾ ਨਾਂ ਲੈਣ ਵਾਲਾ ਵੱਖਰਾ ਨਿਯਮ ਜੋੜੋ।

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

ਇਸ ਨੂੰ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕਣ ਵਾਲਾ ਬਣਾਓ ਅਤੇ ਦੋਵੇਂ ਅੱਧ ਸਾਬਤ ਕਰੋ

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

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

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