Pi-hole VPN ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ಜಾಹೀರಾತುಗಳನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಿಲ್ಲ: ಐದು ಪರಿಶೀಲನೆಗಳು

ಒಂದು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಜಾಹೀರಾತುಗಳು ಇನ್ನೂ ಕಾಣುತ್ತಿವೆ, Pi-hole ತಾನು ಆರೋಗ್ಯವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ಆ ಕ್ಲೈಂಟ್ನ ಸಂಚಾರವನ್ನು Pi ಮೂಲಕ ಕಳುಹಿಸುವುದು ಸಹಜ ಪ್ರವೃತ್ತಿ. ಅದು ತಪ್ಪು ತಿರುವು. ಫಿಲ್ಟರಿಂಗ್ಗೆ ಪ್ಯಾಕೆಟ್ಗಳಲ್ಲ, ಪ್ರಶ್ನೆಗಳು ಬೇಕು, ಮತ್ತು ಪ್ರಶ್ನೆಗಳು ISP ನ ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗುವ ಕ್ಲೈಂಟ್ ತನ್ನ ಸಂಚಾರ ಎಲ್ಲಿಗೆ ಹರಿದರೂ ಫಿಲ್ಟರ್ ಆಗದೆ ಉಳಿಯುತ್ತದೆ. ಈ ಪಟ್ಟಿಯನ್ನು ಕ್ರಮವಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಮೊದಲ ಹಂತದಲ್ಲೇ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ಹಂತ ಕೆಟ್ಟಿರುವಾಗ ಮುಂದಿನ ಹಂತ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳಲಾರದು.

1. ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಬಳಸುತ್ತಿರುವ ರಿಸಾಲ್ವರ್ ಓದಿ

ರೌಟರ್ ಅಲ್ಲ, ಕ್ಲೈಂಟ್ಗೆ ಕೇಳಿ. Linux ನಲ್ಲಿ resolvectl status ಪ್ರತಿ ಲಿಂಕ್ನ DNS ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತು ಯಾವ ಲಿಂಕ್ ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ಮುದ್ರಿಸುತ್ತದೆ; /etc/resolv.conf ಒಂದೇ ಸಾಮಾನ್ಯವಾಗಿ 127.0.0.53 ಗೆ ತೋರಿಸುವ ಸ್ಟಬ್ ಆಗಿರುತ್ತದೆ. Windows ನಲ್ಲಿ ipconfig /all ಪ್ರತಿ ಅಡಾಪ್ಟರ್ಗೆ DHCP ನೀಡಿದ ಸರ್ವರ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು macOS ನಲ್ಲಿ scutil --dns ಅದೇ ವಿಷಯವನ್ನು ವ್ಯಾಪ್ತಿಯ ಪ್ರಕಾರ ತೋರಿಸುತ್ತದೆ. ಉತ್ತರ Pi-hole ನ ವಿಳಾಸವಲ್ಲದಿದ್ದರೆ, ನಿಮಗೆ ನಿಯೋಜನೆ ಸಮಸ್ಯೆ ಇದೆ ಮತ್ತು ಹಂತ 2 ಅದು ಇರುವ ಜಾಗ.

ಸಿಸ್ಟಮ್ ರಿಸಾಲ್ವರ್ ಸರಿಯಾಗಿ ಸೆಟ್ ಆಗಿದ್ದರೂ ಎರಡು ವಿಷಯಗಳು ಅದನ್ನು ಸೋಲಿಸುತ್ತವೆ. ಸ್ವಂತ ಸುರಕ್ಷಿತ DNS ಇರುವ ಬ್ರೌಸರ್ಗಳು (Chrome ನ “Use secure DNS”, Firefox ನ network.trr.mode) ಪ್ರಶ್ನೆಗಳನ್ನು HTTPS ಮೂಲಕ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ಗೆ ಕಳುಹಿಸುತ್ತವೆ ಮತ್ತು ಪೋರ್ಟ್ 53 ಅನ್ನು ಎಂದಿಗೂ ತೆರೆಯುವುದಿಲ್ಲ. ಮತ್ತು ಕ್ಲೈಂಟ್ನಲ್ಲೇ ಇರುವ VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ~. ಮಾರ್ಗನಿರ್ದೇಶನ ಡೊಮೇನ್ನೊಂದಿಗೆ DNS ಸರ್ವರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು, ಇದು ಆ ಲಿಂಕ್ ಅನ್ನು ಪ್ರತಿ ಹೆಸರಿಗೂ ಅಧಿಕೃತಗೊಳಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ಗಳು ಹೋಗುವ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಡೀಬಗ್ ಉಪಕರಣ ಹೋಗುವ ಮಾರ್ಗವನ್ನಲ್ಲ. resolvectl query example.com ಯಾವ ಲಿಂಕ್ ಉತ್ತರಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು getent hosts example.com ಅಪ್ಲಿಕೇಶನ್ ಹೋಗುವ ಅದೇ NSS ಮಾರ್ಗದ ಮೂಲಕ ಹೋಗುತ್ತದೆ; macOS ನಲ್ಲಿ dscacheutil -q host -a name example.com, scutil --dns ಪಟ್ಟಿ ಮಾಡುವ ವ್ಯಾಪ್ತಿಯ ರಿಸಾಲ್ವರ್ಗಳನ್ನು ಓದುತ್ತದೆ. ಬರೀ dig ಇದನ್ನು ಮಾಡುವುದಿಲ್ಲ: ಅದು /etc/resolv.conf ಓದಿ ಲಿಂಕ್ ಪ್ರಕಾರದ ಆಯ್ಕೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ತಳ್ಳಿದ ರಿಸಾಲ್ವರ್ ಬಳಸುತ್ತಿರುವಾಗಲೂ ಅದು Pi-hole ನಿಂದ ಉತ್ತರಿಸಬಹುದು, ಮತ್ತು ಇದು ನಿಖರವಾಗಿ ಈ ಪಟ್ಟಿ ಹಿಡಿಯಲು ಇರುವ ವೈಫಲ್ಯ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ ಪರೀಕ್ಷಿಸಲು dig @192.168.1.53 ಇಟ್ಟುಕೊಳ್ಳಿ.

2. ಉತ್ತರವನ್ನು ಯಾರು ಹಂಚುತ್ತಾರೆ ಎಂದು ದೃಢೀಕರಿಸಿ

ನಿಯೋಜನೆ DHCP ಗೆ ಉತ್ತರಿಸುವ ಯಾವುದೇ ವಸ್ತುವಿನಿಂದ ಬರುತ್ತದೆ. dnsmasq ನಲ್ಲಿ ಅದು ಒಂದು ಸಾಲು, dhcp-option=6,192.168.1.53; ರೌಟರ್ನ ವೆಬ್ UI ನಲ್ಲಿ ಅದು LAN DHCP ವಿಭಾಗದ DNS ಕ್ಷೇತ್ರ. ಕ್ಲೈಂಟ್ಗಳು ಅದನ್ನು ನೋಡುವ ಮೊದಲು ನವೀಕರಿಸಬೇಕು. ದಿನಗಳಿಂದ ಆನ್ ಆಗಿರುವ ಸಾಧನ ಇನ್ನೂ ಹಳೆಯ ಬಾಡಿಗೆ ಹಿಡಿದಿದೆ, ಮತ್ತು ಕೈಯಿಂದ ಟೈಪ್ ಮಾಡಿದ ರಿಸಾಲ್ವರ್ ಇರುವ ಸಾಧನ ಅದನ್ನು ಶಾಶ್ವತವಾಗಿ ಹಿಡಿದಿರುತ್ತದೆ. ಹರಡುವಿಕೆಯನ್ನು ಊಹಿಸುವ ಬದಲು ಪರೀಕ್ಷಾ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ನವೀಕರಿಸಿ.

IPv6 ಎಂಬುದು ಕಣ್ಣು ತಪ್ಪಿಸುವ ಅರ್ಧ. ರೌಟರ್ ಜಾಹೀರಾತುಗಳು ತಮ್ಮದೇ DNS ಸರ್ವರ್ ಅನ್ನು ಹೊತ್ತುಕೊಳ್ಳಬಹುದು (RDNSS), ಮತ್ತು OpenWrt ನಲ್ಲಿ ಅದು odhcpd ನ ra_dns ಆಯ್ಕೆ; IPv6 ಬಯಸುವ ಕ್ಲೈಂಟ್ ಆ ಸರ್ವರ್ ಬಳಸುತ್ತದೆ, ಆದರೆ ನೀವು ಈಗ ಸೆಟ್ ಮಾಡಿದ DHCPv4 ಆಯ್ಕೆ ಬಳಕೆಯಾಗದೆ ಉಳಿಯುತ್ತದೆ. IPv6 DNS ನೀಡಲು ಸಿದ್ಧವಿಲ್ಲದಿದ್ದರೆ, DNS ಜಾಹೀರಾತನ್ನು ಮಾತ್ರ ತೆರವುಗೊಳಿಸಿ: odhcpd ನಲ್ಲಿ ra_dns, ಅಥವಾ ರೌಟರ್ ಜಾಹೀರಾತುಗಳಿಗೆ ಉತ್ತರಿಸುವ ಯಾವುದೇ ವಸ್ತುವಿನಲ್ಲಿ RDNSS ಆಯ್ಕೆ. ಇಡೀ ಜಾಹೀರಾತನ್ನು ಆಫ್ ಮಾಡುವುದು LAN ನಿಂದ IPv6 ವಿಳಾಸೀಕರಣವನ್ನೂ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಅದು ನೀವು ಉದ್ದೇಶಿಸಿದ್ದಕ್ಕಿಂತ ಬಹಳ ದೊಡ್ಡ ಬದಲಾವಣೆ, ಆದರೆ DNS ಆಯ್ಕೆಯನ್ನು ಮಾತ್ರ ತೆರವುಗೊಳಿಸುವುದು ವಿಳಾಸೀಕರಣವನ್ನು ಅಕ್ಷತವಾಗಿ ಉಳಿಸಿ ಕಾಣೆಯಾದ RDNSS ಅನ್ನು ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆಯಲ್ಲಿ ಗೋಚರವಾಗಿಸುತ್ತದೆ.

3. ಪ್ರಶ್ನೆ Pi-hole ತಲುಪುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

Pi ಯಿಂದ ಮಾಡಿದ ಪ್ರಶ್ನೆ ಜಾಲ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅದನ್ನು ಕ್ಲೈಂಟ್ನಿಂದ ಚಲಾಯಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ ಓದಿ:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

ಸಮಯ ಮೀರುವಿಕೆ ಫಿಲ್ಟರಿಂಗ್ ಅಥವಾ ಮಾರ್ಗಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ; REFUSED ಪ್ರವೇಶ ನಿಯಮಕ್ಕೆ; SERVFAIL Pi-hole ಹಿಂದಿನ ಮೇಲ್ಮುಖ ರಿಸಾಲ್ವರ್ಗೆ; ಪ್ರಶ್ನೆ ಲಾಗ್ನಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣದ ಸರಿಯಾದ ಉತ್ತರ ಕ್ಲೈಂಟ್ ಬೇರೆ ಏನೋ ಕೇಳಿದೆ ಎಂದರ್ಥ. UDP ಮತ್ತು TCP 53 ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ದೊಡ್ಡ ಉತ್ತರಗಳು ಮತ್ತು ಕೆಲವು ರಿಸಾಲ್ವರ್ಗಳು TCP ಗೆ ಮರಳುತ್ತವೆ, ಮತ್ತು Pi-hole ಕಂಟೇನರ್ನಲ್ಲಿ ಚಲಿಸುವಾಗ ಎರಡನ್ನೂ ಪ್ರಕಟಿಸಿ. UDP ಮಾತ್ರ ಆವರಿಸುವ ಮ್ಯಾಪಿಂಗ್ ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಂತೆ ಕಾಣುವ ಮಧ್ಯಂತರ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ನಂತರ Pi-hole ನ ಆಲಿಸುವ ಮೋಡ್ ಅದು ಒಟ್ಟಿನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಮಾತ್ರ ಮೋಡ್ನಲ್ಲಿ dnsmasq ನೇರವಾಗಿ ಸಂಪರ್ಕಿತ ಸಬ್ನೆಟ್ನಲ್ಲಿಲ್ಲದ ಮೂಲಗಳ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದು ರೌಟರ್ ಹಿಂದೆ ಇರುವ ಅಥವಾ ಸುರಂಗದ ಮೂಲಕ ಬರುವ ಕ್ಲೈಂಟ್ ನಿಖರವಾಗಿ ಹಾಗೆ ಕಾಣುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಸಮಯ ಮೀರಿ ಪ್ರಶ್ನೆ ಎಂದಿಗೂ ಲಾಗ್ ತಲುಪುವುದಿಲ್ಲ. ಹಾಗಿದ್ದರೂ REFUSED ಆಗಿ ಕಾಣುವ ಪ್ರಶ್ನೆಯನ್ನು ಪ್ರವೇಶ ಪಟ್ಟಿ ಅಥವಾ ಫೈರ್ವಾಲ್ ನಿಯಮ ತಿರಸ್ಕರಿಸಿದೆ. ಎಲ್ಲಾ ಮೂಲಗಳಿಗೆ ಅನುಮತಿ ನೀಡುವುದು ಸಾಮಾನ್ಯ ಪರಿಹಾರ, ಜೊತೆಗೆ ಪೋರ್ಟ್ 53 ಅನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಸಬ್ನೆಟ್ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮ.

4. ಸುರಂಗ ಉತ್ತರವನ್ನು ಬದಲಾಯಿಸಿದೆಯೇ ಅಥವಾ ನುಂಗಿತೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಇದು ಎರಡೂ ಲಕ್ಷಣಗಳು ಅಡಗಿರುವ ಸಂದರ್ಭ. ರೌಟರ್ ಸ್ವತಃ VPN ಕ್ಲೈಂಟ್ ಆಗಿರುವಾಗ, ತಳ್ಳಿದ DNS ಆಯ್ಕೆ ಸುರಂಗ ಏರುವ ಕ್ಷಣದಲ್ಲೇ LAN ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮೀರಿಸಬಹುದು: OpenVPN ಸರ್ವರ್ಗಳು dhcp-option DNS ತಳ್ಳುತ್ತವೆ, ಮತ್ತು WireGuard ಪ್ರೊಫೈಲ್ಗಳು ತಮ್ಮದೇ DNS ನಮೂದನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತವೆ. ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ರೌಟರ್ನ ಪರಿಣಾಮಕಾರಿ ರಿಸಾಲ್ವರ್ ಓದಿ, ಅದಕ್ಕೂ ಮೊದಲಲ್ಲ, ಮತ್ತು LAN ಪುಟ ಹೇಳುವುದನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ.

ಇನ್ನೊಂದು ದೋಷ ಬದಲಾಯಿಸುವಿಕೆಯಲ್ಲ, ತಲುಪುವಿಕೆ. ಸುರಂಗದ ಅನುಮತಿಸಿದ ಮುನ್ನಡಿಗಳು ನಿಮ್ಮ LAN ಸಬ್ನೆಟ್ ಒಳಗೊಂಡಿದ್ದರೆ, ರೌಟರ್ಗೆ 192.168.1.53 ಗಾಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಸುರಂಗದೊಳಗೆ ಕಳುಹಿಸುವ ಮಾರ್ಗ ಇರುತ್ತದೆ, ಮತ್ತು ಆಚೆಯ ಬದಿಗೆ ಹಿಂತಿರುಗಿ ಮಾರ್ಗವಿಲ್ಲ: ಸುರಂಗ ಆರೋಗ್ಯವಾಗಿದ್ದರೂ ಪ್ರಶ್ನೆಗಳು ಸಮಯ ಮೀರುತ್ತವೆ. Pi-hole ಸುರಂಗ ಒಯ್ಯದ ಸಬ್ನೆಟ್ನಲ್ಲಿದ್ದಾಗ ವಿರುದ್ಧವಾಗುತ್ತದೆ. DNS ಅನ್ನು ಮತ್ತೆ ಮುಟ್ಟುವ ಮೊದಲು ವಿಳಾಸವನ್ನು ಸುರಂಗದ ಅನುಮತಿಸಿದ ಮುನ್ನಡಿಗಳು ಮತ್ತು ರೌಟರ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಎರಡೂ ಅಲ್ಲ, ಒಂದು ಪರಿಹಾರ ಆಯ್ಕೆಮಾಡಿ. ಸುರಂಗವನ್ನು DNS ನಿಂದ ದೂರವಿಡಿ — OpenVPN ನಲ್ಲಿ pull-filter ignore “dhcp-option DNS” ಮತ್ತು WireGuard ನಲ್ಲಿ AllowedIPs ನಲ್ಲಿ ಯಾವುದೇ LAN ಮುನ್ನಡಿ ಇಲ್ಲದೆ —, ಅಥವಾ ತಳ್ಳಿದ ರಿಸಾಲ್ವರ್ ಒಪ್ಪಿಕೊಂಡು ಆ ರೌಟರ್ ಹಿಂದಿನ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಸ್ಥಳೀಯ ಫಿಲ್ಟರಿಂಗ್ ಬಿಟ್ಟುಬಿಡಿ. ನೀವು ಏನೇ ಆಯ್ಕೆಮಾಡಿದರೂ ಅದನ್ನು ಪ್ರೊಫೈಲ್ನ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದೆ ಅದನ್ನು ಸಂಪಾದಿಸುವ ವ್ಯಕ್ತಿ ಇಲ್ಲದಿದ್ದರೆ ಆಕಸ್ಮಿಕವಾಗಿ ನಿರ್ಣಯವನ್ನು ತಲೆಕೆಳಗಾಗಿಸುತ್ತಾನೆ.

5. ಮರುಸಂಪರ್ಕದ ನಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ

ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಶ್ನೆ ಮಾಡಿ, ಆ ಕ್ಲೈಂಟ್ Pi-hole ನ ಲಾಗ್ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ನಂತರ ನಿರ್ಬಂಧಿಸಬೇಕಾದ ಡೊಮೇನ್ ಅನ್ನು ರಿಸಾಲ್ವ್ ಮಾಡಿ ಮತ್ತು ನಿಜವಾದ ಉತ್ತರದ ಬದಲು ನಿರ್ಬಂಧದ ಉತ್ತರ ಸಿಗುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಸುರಂಗವನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಅದೇ ಎರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಸಂಪರ್ಕದವರೆಗೆ ಮಾತ್ರ ಉಳಿಯುವ ರಿಸಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ ತಪ್ಪು ಪದರದಲ್ಲಿ ಅನ್ವಯಿಸಿದ ಪರಿಹಾರದ ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶ.

ಸುರಂಗವನ್ನು ಅವಲಂಬಿಸಿಲ್ಲದ ದ್ವಿತೀಯ ರಿಸಾಲ್ವರ್ ಮಾರ್ಗವನ್ನು ಬಿಡಿ, ಇದರಿಂದ Pi-hole ವಿಫಲವಾದಾಗ ಬ್ರೌಸಿಂಗ್ ಸಂಪೂರ್ಣ ನಿಂತುಹೋಗದೆ ಫಿಲ್ಟರ್ ಇಲ್ಲದ ಬ್ರೌಸಿಂಗ್ಗೆ ಇಳಿಯುತ್ತದೆ. ಪರೀಕ್ಷೆ ಎರಡು ಬಾರಿ ಉತ್ತೀರ್ಣವಾಗುವವರೆಗೆ ಹಿಂದಿನ DHCP ಮತ್ತು ರಿಸಾಲ್ವರ್ ಮೌಲ್ಯಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ; ರಾತ್ರಿ ಊಟದ ಸಮಯದಲ್ಲಿ ಮನೆಯ ಇಂಟರ್ನೆಟ್ ಮುರಿಯುವ ಬದಲಾವಣೆಯನ್ನು ಡೀಬಗ್ ಮಾಡುವುದು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಹಿಂತಿರುಗಿಸಬಹುದಾದ ಬದಲಾವಣೆಗಿಂತ ಬಹಳ ಕಷ್ಟ.