libvirt ಅತಿಥಿಯ DNS ಅನ್ನು ಮಾರ್ಕ್-ಆಧಾರಿತ VPN ಫೈರ್‌ವಾಲ್ ನಿರ್ಬಂಧಿಸಿದ್ದನ್ನು ಸರಿಪಡಿಸಿ

ಡೀಫಾಲ್ಟ್ 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 ಸಾಲು ಆ ಪ್ಯಾಕೆಟ್‌ಗೆ ಎಂದಿಗೂ ಪರಿಗಣಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸ್ಪಷ್ಟ ನಿಯಮ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.

ಏನಾದರೂ ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಅದನ್ನು ಅಗಲಿಸುವುದು ಎರಡನೇ ಬಲೆ. ಹೋಸ್ಟ್‌ನ ಇನ್‌ಪುಟ್ ಮಾರ್ಗದಲ್ಲಿ ಇಡೀ 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 ಗೆ ಅಥವಾ ಯಾರೋ ಟೈಪ್ ಮಾಡಿದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತದೆಯೇ, ಮತ್ತು ಕ್ವೆರಿ ಹೋಸ್ಟ್ ತಲುಪುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಗುರುತಿಸುವಿಕೆ ಪ್ಯಾಕೆಟ್‌ಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಟ್ಟ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಅಥವಾ ಮುರಿದ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಎಷ್ಟೇ ನಿಯಮ ಸೇರಿಸಿದರೂ ಮುರಿದೇ ಇರುತ್ತದೆ.