UFW ಕಿಲ್ ಸ್ವಿಚ್ ನಿಮ್ಮ VPN ಅನ್ನು ತಡೆಯುತ್ತಿದೆಯೇ? ಪೀರ್‌ಗೆ ಅನುಮತಿ ನೀಡಿ

ನೀವು ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯನ್ನು ಅನುಸರಿಸಿದ್ದೀರಿ: ಹೊರಹೋಗುವಿಕೆಯನ್ನು ನಿರಾಕರಿಸಿ, ಸುರಂಗಕ್ಕೆ ಅನುಮತಿ ನೀಡಿ, ufw ಸಕ್ರಿಯಗೊಳಿಸಿ. ನಂತರ ಕ್ಲೈಂಟ್ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಲ್ಲಿ ಕಾಯುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ, ಅಥವಾ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಪುಟ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ. ಎರಡೂ ವೈಫಲ್ಯಗಳು ಒಂದೇ ಕೊರತೆಯಿಂದ ಬರುತ್ತವೆ. ಸುರಂಗ ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು ಅನುವು ಮಾಡುವ ನಿಯಮ ಇಲ್ಲ, ಏಕೆಂದರೆ ಸುರಂಗವು ನಿಮ್ಮ ಪ್ಯಾಕೆಟ್‌ಗಳು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ ಅಲ್ಲ.

tun0 ಮೇಲಿನ ಅನುಮತಿ ಮೊದಲಿಗೆ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದ ಕಾರಣ

ಸೆಷನ್ ಇದ್ದ ನಂತರ ಕ್ಲೈಂಟ್ tun0 ರಚಿಸುತ್ತದೆ. ಆ ಸೆಷನ್ ಕಟ್ಟುವ ಡೇಟಾಗ್ರಾಮ್‌ಗಳು ಪೋರ್ಟ್ 1194 ನಲ್ಲಿ ಪ್ರದಾತನಿಗೆ ಉದ್ದೇಶಿಸಿದ ಸಾಮಾನ್ಯ UDP ಪ್ಯಾಕೆಟ್‌ಗಳು, ಮತ್ತು ಅವು ಭೌತಿಕ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ wlan0 ಅಥವಾ eth0 ಮೂಲಕ ಹೊರಹೋಗುತ್ತವೆ. allow out on tun0 ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ tun0 ಆಗಿರುವ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯದಲ್ಲಿ ಅದು ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ಅದರ ಮೇಲೆ default deny outgoing ಇರಿಸಿದರೆ ಇಂಟರ್ಫೇಸ್ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲೇ ಹೊರ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಸಮಯ ಮೀರುತ್ತದೆ ಮತ್ತು TLS ಅಥವಾ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವೈಫಲ್ಯವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಇದು ಜನರನ್ನು ಪ್ರಮಾಣಪತ್ರಗಳು ಮತ್ತು MTU ನಡುವೆ ಹುಡುಕಾಡಲು ಕಳುಹಿಸುತ್ತದೆ, ಆದರೆ ಫೈರ್‌ವಾಲ್ ಸದ್ದಿಲ್ಲದೆ ಸಂಪರ್ಕವನ್ನು ತಿನ್ನುತ್ತದೆ. ನಿಮ್ಮ ಸಂಚಾರವನ್ನು ಹಿಡಿದಿಡಬೇಕಿದ್ದ ನಿಯಮವೇ ಆ ಸಂಚಾರ ಹಿಡಿದಿಡಲ್ಪಡದಂತೆ ತಡೆಯುತ್ತಿದೆ.

ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಸರಿಪಡಿಸುವಿಕೆ ಸೋರಿಕೆಯನ್ನು ಶಾಶ್ವತಗೊಳಿಸುತ್ತದೆ. sudo ufw allow out on wlan0, ಅಥವಾ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಮತ್ತೆ ಅನುಮತಿಗೆ ತಿರುಗಿಸುವುದು ಸುರಂಗವನ್ನು ಮೇಲೆತ್ತುತ್ತದೆ ಮತ್ತು ಯಂತ್ರವನ್ನು ಕಿಲ್ ಸ್ವಿಚ್ ಇಲ್ಲದೆ ಬಿಡುತ್ತದೆ: ಮುಂದಿನ ಬಾರಿ ಸುರಂಗ ಬಿದ್ದಾಗ ಎಲ್ಲವೂ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ಮೂಲಕ ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ನಾನು ನಿಖರವಾಗಿ ಆ ಎರಡು ಬದಲಾವಣೆಗಳಿಗೆ ಒಂದು ಮಧ್ಯಾಹ್ನ ಕಳೆದುಕೊಂಡೆ, ನಾನು ನಿಜವಾಗಿ ಯಾವ ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಿದ್ದೇನೆ ಎಂದು ತಿಳಿಯುವ ಮೊದಲು.

ಎರಡು ಪ್ಯಾಕೆಟ್ ಗುಂಪುಗಳಿಗೆ ಏನು ಬೇಕು

ನಿಮ್ಮ ಸಂಚಾರ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಎರಡು ಬಾರಿ, ಎರಡು ಆಕಾರಗಳಲ್ಲಿ ದಾಟುತ್ತದೆ. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಸುರಂಗದ ವಿಳಾಸದಿಂದ tun0 ಮೂಲಕ ಹೊರಕ್ಕೆ ಹೋಗುತ್ತದೆ. ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ ಭೌತಿಕ ವಿಳಾಸದಿಂದ ಪೀರ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ತಂತಿಯಲ್ಲಿ ಕಾಣುವ ಏಕೈಕ ವಸ್ತು ಅದೇ. ಪ್ರತಿ ಆಕಾರಕ್ಕೆ ಒಂದು ನಿಯಮ:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೊಫೈಲ್‌ನವುಗಳಿಂದ ಬದಲಾಯಿಸಿ. WireGuard ಪೀರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ 51820/udp ನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತವೆ; TCP 443 ಮೂಲಕ ಸಾಗುವ OpenVPN ಪ್ರೊಫೈಲ್‌ಗಳಿಗೆ ಬದಲಾಗಿ ಆ ಪೋರ್ಟ್ ಬೇಕು. ವಿವರಗಳು ಭಿನ್ನ, ಆಕಾರ ಅಲ್ಲ: ಎರಡೂ ನಿಯಮಗಳು ಸಂಕುಚಿತ, ಮತ್ತು ಒಟ್ಟಾಗಿ ಸುರಂಗ ಕೆಳಗಿರುವಾಗ ಯಂತ್ರ ತಲುಪಬಹುದಾದ ಏಕೈಕ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಅವು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ.

ಕ್ರಮವು ಎರಡನೇ ಪುರಾಣ. ಕಚ್ಚಾ iptables ನೊಂದಿಗೆ ನೀವು ಸರಪಣಿಯನ್ನು ಮೇಲಿನಿಂದ ಕೆಳಕ್ಕೆ ಓದಿ ಯಾವ ನಿಯಮ ಗೆಲ್ಲುತ್ತದೆ ಎಂದು ತರ್ಕಿಸುತ್ತೀರಿ. ufw ನೀವು ಟೈಪ್ ಮಾಡಿದ ಪಟ್ಟಿಯ ಸುತ್ತಲಿನ ತೆಳು ಹೊದಿಕೆ ಅಲ್ಲ; ಅದು ನಿಮ್ಮ ನಿಯಮಗಳನ್ನು ತನ್ನದೇ ಸರಪಣಿಗಳಿಗೆ ಸಂಕಲಿಸುತ್ತದೆ ಮತ್ತು ಸೇರಿಸುವ ಬಿಂದುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ufw status ಅವುಗಳನ್ನು ufw ಕ್ರಮದಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ, ನಿಮ್ಮ ಕ್ರಮದಲ್ಲಿ ಅಲ್ಲ. ನಿಯಮವು ನಿರ್ಲಕ್ಷಿಸಲ್ಪಟ್ಟಂತೆ ಕಂಡಾಗ, ಏನನ್ನಾದರೂ ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು ufw show added ಅನ್ನು ಸಂಕಲಿತ ಗುಂಪಿನೊಂದಿಗೆ iptables -S | grep ufw ಹೋಲಿಸಿ.

ಅಪವಾದವು ಒಂದು ವಿಳಾಸದ ಅಗಲದಲ್ಲಿಯೇ ಉಳಿಯಬೇಕು

ಪೀರ್ ನಿಯಮವು ಕ್ಲೈಂಟ್ ಡಯಲ್ ಮಾಡುವ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವವರೆಗೆ ಮಾತ್ರ ಸರಿಯಾಗಿರುತ್ತದೆ. ಪ್ರದಾತರು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ತಿರುಗಿಸುತ್ತಾರೆ, ಮತ್ತು ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಪರಿಹರಿಸುವ ಪ್ರೊಫೈಲ್ DNS ಬದಲಾವಣೆಯನ್ನು ಹೊಸ ವಿಳಾಸಕ್ಕೆ ಅನುಸರಿಸುತ್ತದೆ, ಆದರೆ ನಿಯಮವು ಹಳೆಯದನ್ನೇ ಸೂಚಿಸುತ್ತಿರುತ್ತದೆ. ತಿಂಗಳುಗಟ್ಟಲೆ ಕೆಲಸ ಮಾಡಿದ ಸುರಂಗ ಏಳಲು ನಿಲ್ಲಿಸಿದಾಗ, ಏನನ್ನಾದರೂ ವಿಸ್ತರಿಸುವ ಮೊದಲು ನಿಯಮದಲ್ಲಿನ ವಿಳಾಸವನ್ನು ಕ್ಲೈಂಟ್ ಹುಡುಕುತ್ತಿರುವ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಇಡೀ ಸಬ್‌ನೆಟ್‌ಗೆ, ಅಥವಾ ಪೋರ್ಟ್ 1194 ನಲ್ಲಿನ ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ವಿಸ್ತರಿಸುವುದು ನೀತಿಯನ್ನು ಮತ್ತೆ ರಂಧ್ರವಿರುವ ಫೈರ್‌ವಾಲ್ ಆಗಿ ಮಾಡುತ್ತದೆ. ಅಪವಾದವೇ ಕಿಲ್ ಸ್ವಿಚ್; ಅದು ಅಗಲವಾದ ನಂತರ, ನಿಲ್ಲಿಸಲು ಏನೂ ಉಳಿಯುವುದಿಲ್ಲ. ಅದನ್ನು ಒಂದೇ ವಿಳಾಸದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಯಾವ ಪ್ರೊಫೈಲ್ ಹಾಗೂ ಪ್ರದಾತಕ್ಕೆ ಸೇರಿದೆ ಎಂದು ಹೆಸರಿಸುವ ಕಾಮೆಂಟ್ ಬಿಡಿ, ಏಕೆಂದರೆ ಆರು ತಿಂಗಳ ನಂತರ ವಿಳಾಸವು ಕ್ರಮವಿಲ್ಲದಂತೆ ಕಾಣುತ್ತದೆ.

ಹೆಸರು ಪರಿಹಾರವು ತನ್ನದೇ ಸಾಲಿಗೆ ಅರ್ಹವಾಗಿದೆ. ಹುಡುಕಾಟವು ಸುರಂಗ ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುವ ಮೊದಲು, ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮೇಲೆ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಟ್ಟುನಿಟ್ಟಿನ ಹೊರಹೋಗುವ-ನಿರಾಕರಣೆ ನೀತಿಯು ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಸರ್ವರ್ ಅನ್ನು ಕಂಡುಕೊಳ್ಳಲಾಗದಂತೆ ಬಿಡಬಹುದು. ನಿಮ್ಮ ರಿಜಾಲ್ವರ್‌ನ ವಿಳಾಸಕ್ಕೆ ಪೋರ್ಟ್ 53 ಅನ್ನು ಅನುಮತಿಸಿ, ಅಥವಾ ಒಮ್ಮೆ ಪರಿಹರಿಸಿ ವಿಳಾಸವನ್ನು ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಪಿನ್ ಮಾಡಿ. ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ DNS ಅನ್ನು ಅನುಮತಿಸುವುದು ನಿರ್ಧಾರ, ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ.

ಸುರಂಗ ಅಗತ್ಯವಾಗುವ ಮೊದಲೇ ನೀತಿಯನ್ನು ನಿರ್ಮಿಸಿ

ufw enable ಇಡೀ ನೀತಿಯನ್ನು ಒಮ್ಮೆಗೇ ಅನ್ವಯಿಸಿ ತನ್ನ ಸರಪಣಿಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ನೀತಿಯನ್ನು ಬದಲಿಸುವುದೂ ಅವುಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡುತ್ತದೆ. ufw ಕೈಪಿಡಿ ಇದು SSH ನಂತಹ ಇರುವ ಸಂಪರ್ಕಗಳನ್ನು ಬೀಳಿಸಬಹುದು ಎಂದು ಎಚ್ಚರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಆದೇಶಗಳು ಈ ಕ್ರಮದಲ್ಲಿ ಹೋಗುತ್ತವೆ, SSH ನಿಯಮವು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೊದಲು ಮತ್ತು ಕನ್ಸೋಲ್ ಸೆಷನ್ ತೆರೆದಿರಿಸಿ:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆ ಬ್ಲಾಕ್‌ನಿಂದ ಹೊರಗಿಡಲಾಗಿದೆ. ಅದು ಪ್ರತಿ ನಿಯಮವನ್ನು ಅಳಿಸಿ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ದೂರದ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮುಂದಿನ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯೇ ನಿಮ್ಮ ಸೆಷನ್ ಅನ್ನು ಬೀಳಿಸುತ್ತದೆ. ನೀವು ಹೇಗಾದರೂ ಮರುಹೊಂದಿಸಿದರೆ, SSH ನಿಯಮವನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಮುಂದೆ ಹೋಗುವ ಮೊದಲು ಕನ್ಸೋಲ್ ಮೂಲಕ ಹಿಂತಿರುಗುವ ಎರಡನೇ ದಾರಿಯನ್ನು ಖಚಿತಪಡಿಸಿ.

ಕ್ರಮವು ಅಲಂಕಾರಿಕವಲ್ಲ. ufw ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಸೇರಿಸಿದ ನಿಯಮಗಳು ಏನನ್ನೂ ಫ್ಲಶ್ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ಡೀಫಾಲ್ಟ್ ನೀತಿಯನ್ನು ತಿರುಗಿಸಿದ ಕ್ಷಣ ಸರಪಣಿಗಳು ಮರುಲೋಡ್ ಆಗುತ್ತವೆ, ಮತ್ತು ಹಳೆಯ ನೀತಿ ಅನುಮತಿಸಿದ ಸೆಷನ್ ಅವುಗಳೊಂದಿಗೆ ಹೋಗುತ್ತದೆ. ಡೀಫಾಲ್ಟ್‌ಗಳು, ಅನುಮತಿಗಳು ಮತ್ತು ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯನ್ನು ಒಂದೇ ಹಾದಿಯಲ್ಲಿ ಮಾಡಿ, ಯಂತ್ರವನ್ನು ಅವಲಂಬಿಸದ ಪ್ರವೇಶ ಮಾರ್ಗ ಇನ್ನೂ ಇರುವಾಗ.

ತಡೆಯಲಾದ ಸ್ಥಿತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ರದ್ದತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ

ಪರೀಕ್ಷಿಸದ ಕಿಲ್ ಸ್ವಿಚ್ ಒಂದು ಊಹೆ. ಕ್ಲೈಂಟ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು ಪುಟ ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ: ಅದು ವಿಫಲವಾಗಬೇಕು. ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಅದು ಯಾವುದೇ ನಿಯಮವನ್ನು ಮುಟ್ಟದೆ ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು. sudo ufw status verbose ಡೀಫಾಲ್ಟ್‌ಗಳು ಮತ್ತು ಲಾಗಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಮತ್ತು ufw status numbered ಪರೀಕ್ಷಾ ನಿಯಮವು ತನ್ನ ಉದ್ದೇಶವನ್ನು ಮೀರಿ ಬದುಕಿದಾಗ ಯಾವುದನ್ನು ಅಳಿಸಬೇಕೆಂದು ತೋರಿಸುತ್ತದೆ.

ಹಿಮ್ಮುಖ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಮುಂದಿನ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ. ಹೊರಹೋಗುವ-ನಿರಾಕರಣೆ ಮತ್ತು ಸತ್ತ ಸುರಂಗವಿರುವ ಯಂತ್ರವು ತನ್ನ ಸ್ವಂತ ದುರಸ್ತಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗದು, ಆದ್ದರಿಂದ ರದ್ದತಿಯು ಡಿಸ್ಕ್‌ನಲ್ಲಿರಬೇಕು ಮತ್ತು ಕನ್ಸೋಲ್‌ನಿಂದ ಓದಬಹುದಾಗಿರಬೇಕು:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

ಸುರಂಗ ಈಗಾಗಲೇ ಕೆಳಗಿರುವಾಗ ಮತ್ತು ನಿಯಮಗಳನ್ನು ತೆಗೆಯಬೇಕಾದಾಗ ಅದನ್ನು ಚಲಾಯಿಸಿ, ನಿಯಮಿತ ಹಂತವಾಗಿ ಅಲ್ಲ. ಟರ್ಮಿನಲ್ ಮುಚ್ಚುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳು ನಿಜವಾಗಿರಬೇಕು: ಪೀರ್ ನಿಯಮವು ನಿಖರವಾಗಿ ಒಂದು ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, DNS ಗೆ ಹೆಸರಿಸಿದ ಅಪವಾದವಿದೆ, ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಅನುಮತಿಗಳ ನಂತರ ಬಂದಿದೆ, ಮತ್ತು ಸುರಂಗವನ್ನು ಎಳೆದರೆ ಸಾಮಾನ್ಯ ಸಂಚಾರ ಸಾಯುತ್ತದೆ ಆದರೆ ಕ್ಲೈಂಟ್ ಶಾಶ್ವತವಾಗಿ ಸಾಯುವುದಿಲ್ಲ.