ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು VPN ಅಪ್ಲಿಕೇಶನ್‌ಗಳು: ಯಾವ kill switch ನಿಜವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ?
ಎರಡನೇ VPN ಕ್ಲೈಂಟ್ ಮೊದಲನೆಯ kill switch ಅನ್ನು ಎಂದಿಗೂ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ. ಯಾವ ನೀತಿ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮದನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು.
ಎರಡು VPN ಕ್ಲೈಂಟ್‌ಗಳು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಅವುಗಳ kill switch ಒಂದೇ ನೀತಿಯಾಗಿ ಸೇರುವುದಿಲ್ಲ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಸುರಂಗಕ್ಕೆ ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದು ಇದೆ ಎಂದು ಯಾವುದೂ ತಿಳಿದಿಲ್ಲ. ಕೆಲಸದ ಕ್ಲೈಂಟ್ ಮೊದಲು ಸಂಪರ್ಕಗೊಂಡಾಗ ನಾನು ಇದನ್ನು ಎದುರಿಸಿದೆ: ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಹಸ್ತಲಾಘವವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗಲಿಲ್ಲ, ಹತ್ತು ನಿಮಿಷ „Connecting“ ನಲ್ಲಿ ಕುಳಿತಿತು, ಮತ್ತು ಮೊದಲ ಸುರಂಗ ಎಲ್ಲವನ್ನೂ ಸದ್ದಿಲ್ಲದೆ ಒಯ್ಯಿತು. ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್ ರಕ್ಷಿಸಲ್ಪಡುತ್ತದೆಯೇ ಎಂಬುದು ಮೂರು ಷರತ್ತುಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ, ಎರಡೂ ಚಿಹ್ನೆಗಳು ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳುವುದನ್ನು ಅಲ್ಲ.
kill switch ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಸೀಮಿತವಾಗಿದೆ
ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಒಂದೇ kill switch ಧ್ವಜವಿಲ್ಲ. ಅಂತಹ ಧ್ವಜವನ್ನು ಜಾಹೀರಾತು ಮಾಡುವ ಕ್ಲೈಂಟ್ ನಿಯಮಗಳ ಗುಂಪನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ: ನನ್ನ ಸುರಂಗದ ಮೂಲಕ ಹೊರಗೆ ಹೋಗದ ಎಲ್ಲವನ್ನೂ ಬೀಳಿಸು, ಮತ್ತು ಸುರಂಗ ಮಾಯವಾದಾಗ ಹೆಚ್ಚಾಗಿ fail closed ವರ್ತಿಸು. Linux ನಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯವಾಗಿ nftables ಅಥವಾ iptables ಸರಪಳಿ, Windows ನಲ್ಲಿ Windows Filtering Platform ಶೋಧಕಗಳ ಗುಂಪು, Android ಮತ್ತು iOS ನಲ್ಲಿ ಸುರಂಗ ಸೇವೆಯ ಸ್ವಂತ ಮಾರ್ಗನಿರ್ದೇಶನ ಮತ್ತು VPN ಇಲ್ಲದೆ ಸಂಪರ್ಕಗಳನ್ನು ತಡೆಯುವ ಆ ವ್ಯವಸ್ಥೆ ಸೆಟ್ಟಿಂಗ್. Android VPN ಮಾರ್ಗದರ್ಶಿ ಈ ಸೇವಾ ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ನಿಮಗೆ ವೇದಿಕೆಯ ದೃಷ್ಟಿಕೋನ ಬೇಕಿದ್ದರೆ.
ವ್ಯಾಪ್ತಿಯೇ ಮುಖ್ಯ ಭಾಗ. „wg0 ಔಟ್‌ಪುಟ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ಕೊಡು“ ಎಂಬ ನಿಯಮವು ಎರಡನೇ ಸುರಂಗ ಇದೆಯೇ ಎಂದು ಲೆಕ್ಕಿಸುವುದಿಲ್ಲ. ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ wg1 ಅನ್ನು ಎತ್ತಿದರೆ, ಮೊದಲ ಕ್ಲೈಂಟ್‌ನ ನಿಯಮಗಳು ಆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯ ಸಂಚಾರವೆಂದು ಪರಿಗಣಿಸುತ್ತವೆ: ಸಾಮಾನ್ಯವಾಗಿ ಬೀಳಿಸಲ್ಪಡುತ್ತವೆ, ಕೆಲವೊಮ್ಮೆ ಅನುಮತಿಸಲ್ಪಡುತ್ತವೆ. ಹೇಗಿದ್ದರೂ ನಿರ್ಣಯ ಮೊದಲ ಕ್ಲೈಂಟ್‌ದೇ, ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್ ಕಾಯುತ್ತಿದೆ ಎಂದು ಅದಕ್ಕೆ ಗೊತ್ತಿಲ್ಲ.
ಯಾರು ಆವರಿಸಲ್ಪಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು
ಪ್ರತಿ ಸಂಯೋಜನೆಯನ್ನು ಎಣಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಮೂರು ಪ್ರಶ್ನೆಗಳು ಇದನ್ನು ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತವೆ.
- ವೇದಿಕೆ ಎರಡನೇ ಸುರಂಗಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತದೆಯೇ? ಹೆಚ್ಚಿನ Android ಫೋನ್‌ಗಳು ಮತ್ತು iPhone ಗಳು ಪ್ರತಿ ಬಳಕೆದಾರ ಪ್ರೊಫೈಲ್‌ಗೆ ಒಂದೇ ಸಕ್ರಿಯ VPN ಸೇವೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಹಾಗಾಗಿ ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಎಂದಿಗೂ ಸುರಂಗ ಇರುವುದಿಲ್ಲ, ಏನನ್ನೂ ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ. ನಿಮಗೆ ಒಂದೇ ನೀತಿ ಸಿಗುತ್ತದೆ, ಜಾಗವನ್ನು ಗೆದ್ದ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ.
- ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಯಾವ ಪ್ರಕ್ರಿಯೆಯ ಒಡೆತನದಲ್ಲಿದೆ? Windows, macOS ಮತ್ತು Linux ಎರಡು ಸುರಂಗಗಳನ್ನು ಸಲೀಸಾಗಿ ಹೊರುತ್ತವೆ. ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ಕೊನೆಯದಾಗಿ ಅಥವಾ ಉತ್ತಮ ಮೆಟ್ರಿಕ್‌ನೊಂದಿಗೆ ಸೆಟ್ ಮಾಡಿದ ಕ್ಲೈಂಟ್‌ನದು, ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ನಿಷ್ಕ್ರಿಯವಾಗಿದೆ. Linux ನಲ್ಲಿ wg-quick ನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮೋಡ್ ಖಾಸಗಿ ಕೋಷ್ಟಕ ಮತ್ತು fwmark ನಿಯಮದೊಂದಿಗೆ ನೀತಿ ಆಧಾರಿತ ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಬಳಸುತ್ತದೆ, ಹಾಗಾಗಿ ಎರಡನೇ wg-quick ಸುರಂಗವು ಮೊದಲನೆಯದನ್ನು ಬದಲಿಸುವ ಬದಲು ಸ್ಪರ್ಧಾತ್ಮಕ ನಿಯಮವನ್ನು ಸೇರಿಸುತ್ತದೆ.
- ಎರಡನೇ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಸರ್ವರ್‌ನ್ನು ತಲುಪಬಲ್ಲದೇ? ಮೊದಲ kill switch ಡೀಫಾಲ್ಟ್ ನಿರಾಕರಣೆಯಾಗಿದ್ದರೆ, ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬಾಹ್ಯ ಅಂತ್ಯಬಿಂದು ಇನ್ನೊಂದು ಬೀಳಿಸಿದ ಗಮ್ಯಸ್ಥಾನ ಮಾತ್ರ. ಅದು ಸದ್ದಿಲ್ಲದೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಎಂದಿಗೂ ದೋಷ ವರದಿ ಮಾಡುವುದಿಲ್ಲ.
ಸಣ್ಣ ಆವೃತ್ತಿ, ಬೆಂಬಲ ಥ್ರೆಡ್‌ಗಳಿಗೆ:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
ಆ ಸಾಲುಗಳಲ್ಲಿ ಎರಡು ಸಿಸ್ಟಮ್ ಟ್ರೇ ಚಿಹ್ನೆಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಚಿಹ್ನೆಯೇ ಇಲ್ಲಿ ಲಭ್ಯವಿರುವ ಅತ್ಯಂತ ದುರ್ಬಲ ಸಾಕ್ಷ್ಯ.
ಮೊದಲು ಏನು ವಿಫಲವಾಗುತ್ತದೆ, ಅದು ಹೇಗೆ ಕಾಣುತ್ತದೆ
ಇನ್ನೊಂದು ಆರೋಗ್ಯಕರವಾಗಿರುವಾಗ ಒಂದು ಕ್ಲೈಂಟ್ „Connecting“ ನಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುವುದು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಅಂತ್ಯಬಿಂದು ಹಸಿವು: ಚಾಲನೆಯಲ್ಲಿರುವ kill switch ಎರಡನೇ ಕ್ಲೈಂಟ್‌ನ ತನ್ನ ಸರ್ವರ್‌ಗೆ ಇರುವ ಹಸ್ತಲಾಘವವನ್ನು ಬೀಳಿಸುತ್ತದೆ. ಇದನ್ನು ಅಗ್ಗವಾಗಿ ಪರಿಶೀಲಿಸಲು ಮೊದಲ ಕ್ಲೈಂಟ್‌ನ ತಡೆ ನಿಯಮಗಳನ್ನು ಒಂದು ಪ್ರಯತ್ನಕ್ಕೆ ನಿಲ್ಲಿಸಿ. ಎರಡನೆಯದು ತಕ್ಷಣ ಸಂಪರ್ಕಗೊಂಡರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ ಸಿಕ್ಕಿತು.
DNS ಎರಡನೇ ವೈಫಲ್ಯ. ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಇಂಟರ್ಫೇಸ್ಗೆ ಪರಿಹಾರಕ ಸಂರಚನೆಯನ್ನು ಸೆಟ್ ಮಾಡುತ್ತವೆ, ಕೆಲವು ನೇರವಾಗಿ ಜಾಗತಿಕ ಪಟ್ಟಿಯನ್ನೇ ಮೇಲೆ ಬರೆಯುತ್ತವೆ. ಎರಡೂ ಸುರಂಗಗಳು ಮೇಲಿರುವಾಗ ಪ್ರಶ್ನೆಗಳು ಒಂದು ಬದಿಯಿಂದ ಹೊರಹೋಗಬಹುದು, ಪರಿಹಾರಕ ಇನ್ನೊಂದು ಬದಿಗೆ ಸೇರಿರುತ್ತದೆ. ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ, ಉಳಿದದ್ದು ತಲುಪಲಾಗದ ಹೆಸರು ಸರ್ವರ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ: ಪುಟಗಳು ಒಂದು ನಿಮಿಷ ನಿಲ್ಲುತ್ತವೆ ಮತ್ತು ನಂತರ ಮತ್ತೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ, VPN ಇನ್ನೂ ಸಂಪರ್ಕಗೊಂಡಂತೆ ತೋರಿಸುತ್ತದೆ.
ಮೂರನೆಯದು ಮಾರ್ಗಗಳ ತೂಗಾಟ. ಮರುಸಂಪರ್ಕಗಳು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಮರುಕ್ರಮಗೊಳಿಸುತ್ತವೆ, ಇಂಟರ್ಫೇಸ್ಗೆ ಬದ್ಧವಾದ kill switch ಅದನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ. ಕ್ಷಣದ ಹಿಂದೆ ಸುರಂಗದಲ್ಲಿದ್ದ ಸಂಚಾರ ಈಗ ಬೀಳಿಸುವ ನಿಯಮಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ಇದು ಬಳಕೆದಾರರ ಕಡೆಯಿಂದ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುವ VPN ಎಂದು ಓದಲ್ಪಡುತ್ತದೆ.
ನಿಜವಾಗಿ ಯಾವ ನೀತಿ ಜಾರಿಯಲ್ಲಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ
ಇದನ್ನು ಹಾನಿಕರವಲ್ಲದ ಸಂಚಾರದೊಂದಿಗೆ ಮಾಡಿ, ನಿಮಗೆ ನಷ್ಟವಾಗುವಂಥದ್ದರೊಂದಿಗೆ ಅಲ್ಲ.
Linux ನಲ್ಲಿ ಕರ್ನೆಲ್‌ಗೆ ಕೇಳಿ ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಯಾವುದಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ. ip -4 route show default ಹೊರಹೋಗುವ ಮಾರ್ಗವಿರುವ ಸುರಂಗವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ip rule show ನೀತಿ ಆಧಾರಿತ ಮಾರ್ಗನಿರ್ದೇಶನ ಆಟದಲ್ಲಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. sudo nft list ruleset | grep -n oifname ಬೀಳಿಸುವಿಕೆಗಳು ಇಂಟರ್ಫೇಸ್ ಹೆಸರು, ಗುರುತು ಅಥವಾ ಇಡೀ ಔಟ್‌ಪುಟ್ ಸರಪಳಿಗೆ ಬದ್ಧವಾಗಿವೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.
Windows ನಲ್ಲಿ ಅದೇ ಕಥೆ ಮಾರ್ಗ ಮೆಟ್ರಿಕ್ ಮತ್ತು ಶೋಧಕ ಪಟ್ಟಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric ಮತ್ತು Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS ನಲ್ಲಿ, netstat -rn -f inet | head -5 ಮತ್ತು scutil --dns | head -20.
ನಂತರ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಹಂತವನ್ನು ಮಾಡಿ: ಸುರಂಗವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಲ್ಲಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಸಂಚಾರ ನಿಜವಾಗಿಯೂ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಸಂಪರ್ಕಗೊಂಡ ಚಿಹ್ನೆ ಇಂಟರ್ಫೇಸ್ ಸ್ಥಿತಿ, ಜಾರಿಗೊಳಿಸುವಿಕೆ ಅಲ್ಲ.
ಯಾವಾಗ ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳು ತಪ್ಪು ವಿನ್ಯಾಸ
ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್ ಹಿಂದಿನ ಏಕೈಕ ಬೇಡಿಕೆ ಹೆಚ್ಚು ರಕ್ಷಣೆಯಾಗಿದ್ದರೆ, ಅದನ್ನು ತೆಗೆದುಹಾಕಿ. ಪರಸ್ಪರ ಕ್ರಿಯಿಸುವ ಎರಡು ತಡೆ ನೀತಿಗಳು ಒಂದಕ್ಕಿಂತ ಕಡಿಮೆ ಊಹಿಸಬಹುದಾದವು, ಮತ್ತು ಪ್ರತಿ ಮರುಸಂಪರ್ಕವೂ ಯಾವುದೇ ಮಾರಾಟಗಾರನೂ ಪರೀಕ್ಷಿಸದ ಸ್ಥಿತಿಗೆ ಬೀಳುವ ಅವಕಾಶ.
ನಿಜವಾಗಿ ಸರಪಳಿ ಬೇಕಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ ವಾಣಿಜ್ಯ ಹಾರಿಕೆಯಿಂದ ತಲುಪುವ ಸಾಂಸ್ಥಿಕ ಗೇಟ್‌ವೇ, ಒಂದೇ ಜಾರಿ ಬಿಂದು ಇರುವ ವಿನ್ಯಾಸವನ್ನು ಆರಿಸಿ. ಅದರರ್ಥ ಸಾಮಾನ್ಯವಾಗಿ ಸರಪಳಿಗೆ ಬೆಂಬಲ ನೀಡುವ ಒಂದು ರೌಟರ್ ಅಥವಾ ಒಂದೇ ಕ್ಲೈಂಟ್, ಒಂದೇ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸುವ ಎರಡು ಡೆಸ್ಕ್ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲ. ನಿರ್ವಹಿತ ಸಾಧನದಲ್ಲಿ ಅನುಮೋದಿತ ಕ್ಲೈಂಟ್ ಅನ್ನು ಇಟ್ಟುಕೊಂಡು ಉಳಿದೆಲ್ಲವನ್ನೂ ವ್ಯಾಪ್ತಿಯ ಹೊರಗೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಟ್ರೇನಲ್ಲಿ ಏನೇ ತೋರಿಸಿದರೂ.
ಎರಡನ್ನೂ ಇಟ್ಟುಕೊಳ್ಳುವ ಮೊದಲು ಪರಿಶೀಲನಾ ಪಟ್ಟಿ
ಪಟ್ಟಿಯನ್ನು ಕ್ರಮವಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿ; ಮೊದಲು ವಿಫಲವಾಗುವ ಅಂಶವೇ ಸರಿಪಡಿಸಬೇಕಾದದ್ದು.
- ನಿಖರವಾಗಿ ಒಂದು ಕ್ಲೈಂಟ್ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮತ್ತು ಪರಿಹಾರಕವನ್ನು ಹೊಂದಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
- ಎರಡನೇ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮೇಲೆ ಇಡಲು ಬಯಸಿದರೆ ಅದರ ಸರ್ವರ್‌ನ ಅಂತ್ಯಬಿಂದುವಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿ ನೀಡಿ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ನವೀಕರಣದ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ.
- ಯಾವುದೇ ಸುರಂಗ ಬಿದ್ದಾಗ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶವನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ಅದೇ ಸಂದರ್ಭವನ್ನು ಪರೀಕ್ಷಿಸಿ.
- ಮರುಪ್ರಾರಂಭದ ನಂತರ ವೈಫಲ್ಯ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ಪ್ರಾರಂಭ ಕ್ರಮ ಬೇರೆಯಾಗಿದ್ದಾಗ.
- ನಿರ್ವಹಿತ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ಮಾಲೀಕರನ್ನು ಕೇಳಿ.
ಮೂರನೇ ಹಂತ ವಿಫಲವಾದರೆ, ಪ್ರಾಮಾಣಿಕ ಉತ್ತರವೆಂದರೆ ಒಂದೇ ಕ್ಲೈಂಟ್ ನಿಮಗೆ ನೀತಿಯನ್ನು ನೀಡುತ್ತಿದೆ. ಯಾರನ್ನು ನಂಬುತ್ತೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ ಇನ್ನೊಂದನ್ನು ಬಿಡಿ.