VPN ರೂಟ್ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮ: ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಯಾವುದು ಬಿಡುತ್ತಿದೆ?
ರೂಟ್ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಫಿಲ್ಟರ್ ಅನುಮತಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ವಿಸ್ತರಿಸುವ ಮೊದಲು ಅದೇ ಮೂಲ, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ದಿಕ್ಕಿಗೆ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ.
ಒಂದೇ ಪ್ಯಾಕೆಟ್‌ಗೆ ಎರಡು ಸ್ವತಂತ್ರ ನಿರ್ಧಾರಗಳು ಸಂಭವಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ವಿನಂತಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಕೊನೆಗೊಳಿಸಬಹುದು. ರೂಟ್ ಹುಡುಕಾಟವು ಒಂದು ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ನಂತರ ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ ಆ ಸಂಯೋಜನೆಗೆ ಅನುಮತಿ ಇದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸಮಯ ಮೀರುವಿಕೆ ನಿಮಗೆ ಎರಡರಲ್ಲಿ ಒಂದು ನಿರಾಕರಿಸಿತು, ಯಾವುದು ಎಂದಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ದುರಸ್ತಿ ಸಾಮಾನ್ಯವಾಗಿ ಊಹೆಯಾಗಿರುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
ಎರಡು ನಿರ್ಧಾರಗಳು, ಒಂದು ಪ್ಯಾಕೆಟ್, ಇಬ್ಬರು ಮಾಲೀಕರು
ರೂಟ್ ಹುಡುಕಾಟವು ಮೊದಲು ನೀತಿ ನಿಯಮಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ, ನಂತರ ಅವು ತೋರಿಸುವ ಕೋಷ್ಟಕವನ್ನು, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಹೊಂದುವ ಅತ್ಯಂತ ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಟನಲ್ ರೂಟ್ ಸ್ಥಾಪಿಸಿದ ಕ್ಲೈಂಟ್ ಆ ನಿರ್ಧಾರದ ಮಾಲೀಕ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮದಲ್ಲಿ ಯಾವುದೂ ಅದನ್ನು ಬದಲಿಸಲಾರದು. ಹುಡುಕಾಟವು ಅನಿರೀಕ್ಷಿತ ಸ್ಥಳಕ್ಕೆ ತೋರಿಸಿದಾಗ, ಪ್ರತಿ ನಂತರದ ಹಂತವೂ ತಪ್ಪು ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಫಿಲ್ಟರಿಂಗ್ ಪ್ರತ್ಯೇಕ. Linux ಹೋಸ್ಟ್‌ನಲ್ಲಿ netfilter ಕೊಕ್ಕೆಗಳು ಪ್ಯಾಕೆಟ್ ಯಾರಿಗೆ ಎಂಬುದರ ಆಧಾರದಲ್ಲಿ ಸಂಚಾರವನ್ನು ವಿಭಜಿಸುತ್ತವೆ: ಔಟ್‌ಪುಟ್ ಯಂತ್ರವನ್ನು ಬಿಡುತ್ತದೆ, ಇನ್‌ಪುಟ್ ಅದರಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಫಾರ್ವರ್ಡ್ ಅದರ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. VPN ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿ ಅವುಗಳನ್ನು LAN ಗೆ ರೂಟ್ ಮಾಡುವ ಗೇಟ್‌ವೇಗೆ ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಹೆಚ್ಚಿನ ಡೀಫಾಲ್ಟ್ ಸಂರಚನೆಗಳು ಖಾಲಿ ಬಿಡುವ ಸರಪಳಿ ಅದೇ.
ಮೂಲ ಆಯ್ಕೆ ಅದೇ ನಿರ್ಧಾರಕ್ಕೆ ಸೇರಿದೆ, ಮತ್ತು ಅಲ್ಲಿಯೇ ಹೆಚ್ಚಿನ ಹೊಂದಾಣಿಕೆಗಳು ಅಡಗಿವೆ. ರೂಟ್ ಒಂದನ್ನು ಹೆಸರಿಸದ ಹೊರತು ಕರ್ಣೆಲ್ ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಮೂಲ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ LAN ಉಪಜಾಲಕ್ಕೆ ಬರೆದ ಫಿಲ್ಟರ್ ನಿಯಮವು ಟನಲ್ ವಿಳಾಸದೊಂದಿಗೆ ಹೊರಡುವ ಪ್ಯಾಕೆಟ್‌ಗೆ ಎಂದಿಗೂ ಹೊಂದುವುದಿಲ್ಲ.
ಹುಡುಕಾಟವು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು ಎಂದು ಓದಿ
ನಿರ್ಧಾರವನ್ನು ಊಹಿಸುವ ಬದಲು ಮುದ್ರಿಸಿ. ಕೆಳಗಿನ ಆಜ್ಞೆಯು ಆ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕರ್ಣೆಲ್ ಬಳಸುವ ರೂಟ್ ಅನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಅದು ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲ ಸೇರಿದಂತೆ:
ip route get 10.8.0.5 ip route get 10.8.0.5 from 192.0.2.44 ip rule show ip route show table all | sed -n '1,40p'
VPN ಕ್ಲೈಂಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮುಖ್ಯ ಕೋಷ್ಟಕದ ಕೆಳಗಿನ ಆದ್ಯತೆಗಳಲ್ಲಿ ನೀತಿ ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸ್ವಚ್ಛವಾದ ಮುಖ್ಯ ಕೋಷ್ಟಕ ತನ್ನಷ್ಟಕ್ಕೇ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ನಿಯಮಗಳ ಆದ್ಯತೆಗಳನ್ನು ಅವು ಆಯ್ಕೆ ಮಾಡುವ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಟನಲ್ ರೂಟ್ ಒಮ್ಮೆ ಕೈಯಿಂದ ಸೇರಿಸುವ ಬದಲು ಮರುಸಂಪರ್ಕದ ನಂತರ ಉಳಿಯುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ನೀತಿ ಆಧಾರಿತ IPsec ರೂಟಿಂಗ್ ಒಳಗೊಳ್ಳದ ಮೂರನೇ ಹೊಂದಾಣಿಕೆ ಹಂತವನ್ನು ಸೇರಿಸುತ್ತದೆ, ಎಂದು strongSwan ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು ಟನಲ್ ಮತ್ತು ಸಾರಿಗೆ ಸಂರಚನೆಗಳಿಗೆ ವಿವರಿಸುತ್ತವೆ. ಭದ್ರತಾ ನೀತಿ ಸಂಚಾರವನ್ನು ಪೂರ್ವಪ್ರತ್ಯಯ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್‌ನಿಂದ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ರೂಟ್ ರಕ್ಷಿಸದ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ. ರೂಟ್ ಆಗಿದ್ದರೂ ಹೊಂದುವ ಸೆಲೆಕ್ಟರ್ ಇಲ್ಲದ ಉಪಜಾಲವು ಒಂದೋ ಅರಕ್ಷಿತವಾಗಿ ಉಳಿಯುತ್ತದೆ ಅಥವಾ ಸಂರಚನೆಯನ್ನು ಅವಲಂಬಿಸಿ ಎಸೆಯಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಫೈರ್‌ವಾಲ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವುದಿಲ್ಲ. ನೀತಿಯನ್ನು ಮುದ್ರಿಸಿ ಮತ್ತು ಅದರ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಟನಲ್ ಸಾಗಿಸುತ್ತದೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಫಿಲ್ಟರಿಂಗ್ ಕೊಕ್ಕೆಯಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತದೆ, ರೂಟ್‌ನಲ್ಲಿ ಅಲ್ಲ
VPN ಆಲಿಸುವವರಿಗೆ ಅನುಮತಿ ನೀಡುವ ನಿಯಮವು ಗೇಟ್‌ವೇಗೆ ಸ್ವತಃ ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರದ ಬಗ್ಗೆ ನಿಯಮ. ಆ ಗೇಟ್‌ವೇಯ ಹಿಂದಿನ ಹೋಸ್ಟ್‌ಗಳನ್ನು ತಲುಪುವ ಕ್ಲೈಂಟ್‌ಗಳ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಸಂಚಾರವು ಬೇರೆ ಸರಪಳಿಯ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ನಿಯಮ ಸಮೂಹವನ್ನು ಒಂದು ಸಮತಟ್ಟಾದ ಪಟ್ಟಿಯಾಗಿ ಓದುವುದು ಸರಿಯಾಗಿ ಕಾಣುವ ನಿಯಮ ಎಂದಿಗೂ ಬೆಂಕಿ ಹೊತ್ತಿಕೊಳ್ಳದ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಕೌಂಟರ್‌ಗಳು ಪ್ರಶ್ನೆಯನ್ನು ಬೇಗನೆ ನಿರ್ಣಯಿಸುತ್ತವೆ. ಶೂನ್ಯ ಪ್ಯಾಕೆಟ್ ಎಣಿಕೆಯ ನಿಯಮವನ್ನು ಎಂದಿಗೂ ತಲುಪಿಲ್ಲ, ಇದು ತಪ್ಪು ಸರಪಳಿ, ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಹಿಂದಿನ ಬಿಡುವಿಕೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಬಿಡುವಿಕೆ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಹೆಚ್ಚುತ್ತಿರುವ ಎಣಿಕೆಯ ನಿಯಮವೇ ನೀವು ಹುಡುಕುತ್ತಿದ್ದ ಗಡಿ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ತಪ್ಪಾಗಿ ರೂಟ್ ಆಗುವ ಬದಲು ಎಸೆಯಲ್ಪಡುತ್ತದೆ.
ಕ್ಲೈಂಟ್ ಬಳಸುವ ಮಾರ್ಗದ ಮೂಲಕ ಪ್ರೋಬ್ ಕಳುಹಿಸಿ
ಗೇಟ್‌ವೇಯಲ್ಲೇ ನಡೆಸುವ ಪರೀಕ್ಷೆಗಳು ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಔಟ್‌ಪುಟ್ ಮತ್ತು ಇನ್‌ಪುಟ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತವೆ. ಅದು ಕ್ಲೈಂಟ್‌ನ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ವಿನಂತಿಗಿಂತ ಬೇರೆ ಮಾರ್ಗ, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ಸ್ಥಳೀಯ curl ಕಾಣುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ವಿಫಲವಾಗುವ ಯಂತ್ರದಿಂದ ಪರೀಕ್ಷಿಸಿ, ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪಿನ್ ಮಾಡಿ.
nc -vz -w 3 10.8.0.5 443 ping -c 3 -W 1 10.8.0.5 tcpdump -ni any host 10.8.0.5 and port 443 iptables -vnL FORWARD --line-numbers nft list ruleset | sed -n '1,60p'
ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಉಳಿದ ಪ್ರಕರಣಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಬಿಟ್ಟು ಎಂದಿಗೂ ತಲುಪದ SYN ಎಂದರೆ ರೂಟಿಂಗ್, ಗೂಢಲಿಪೀಕರಣ ಅಥವಾ ಮೇಲ್ಮುಖ ಪ್ರವೇಶ ಪಟ್ಟಿ. ತಲುಪಿ ಉತ್ತರ ಪಡೆಯದ SYN ಎಂದರೆ ಸೇವೆ ಅಥವಾ ಅದರ ಹೋಸ್ಟ್ ಫಿಲ್ಟರ್, ಮತ್ತು ಟನಲ್ ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ.
ಹಿಂತಿರುಗುವ ಸಂಚಾರ ತನ್ನದೇ ನೋಟಕ್ಕೆ ಅರ್ಹ. ಅಸಮಪಾರ್ಶ್ವ ರೂಟಿಂಗ್ ಜೊತೆಗೆ ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಫಿಲ್ಟರಿಂಗ್ ತಪ್ಪು ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬರುವ ಉತ್ತರಗಳನ್ನು ಎಸೆಯುತ್ತದೆ, ಇದು ನಿರ್ಬಂಧಿತ ಪೋರ್ಟ್‌ಗಿಂತ ಏಕಮುಖ ಸಂಪರ್ಕವಾಗಿ ಕಾಣುತ್ತದೆ. ಫೈರ್‌ವಾಲ್ ತಾನು ಉಂಟುಮಾಡದ ಲಕ್ಷಣಕ್ಕೆ ದೂಷಿಸುವ ಮೊದಲು sysctl ಮೌಲ್ಯವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಲಾಗಿಂಗ್ ಮೊದಲ ಹೆಜ್ಜೆಯಲ್ಲ, ಎರಡನೇ ಅಭಿಪ್ರಾಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಫಾರ್ವರ್ಡ್ ಸರಪಳಿಯಲ್ಲಿನ ತಾತ್ಕಾಲಿಕ ಲಾಗ್ ಹೇಳಿಕೆ ಅದನ್ನು ಹೊಡೆದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ವಿಳಾಸಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರ ತೆಗೆದುಹಾಕುವುದು ಸುಲಭ. ಅದನ್ನು ಶಾಶ್ವತವಾಗಿ ಬಿಟ್ಟರೆ ನೀವು ಉತ್ತರದ ಬದಲು ಲಾಗ್ ಪರಿಮಾಣದ ಸಮಸ್ಯೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೀರಿ.
ಪ್ರತಿ ಬದಲಾವಣೆಯನ್ನು ಮರುಸಂಪರ್ಕದ ನಂತರ ಉಳಿಯುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ
ip route add ನಿಂದ ಸೇರಿಸಿದ ರೂಟ್ ಇಂಟರ್ಫೇಸ್ ಕೆಳಗೆ ಹೋಗುವವರೆಗೆ ಬದುಕುತ್ತದೆ. ಅದನ್ನು ಬದಲಿಗೆ ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಉಳಿಸಿ: NetworkManager ಸಂಪರ್ಕದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ರೂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು netplan ಅವುಗಳನ್ನು ಬೂಟ್‌ಗಳ ನಡುವೆ ಇಡುತ್ತದೆ. ಅದೇ ನಿಯಮ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಫೈರ್‌ವಾಲ್ ಅಪವಾದಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಅದು ಮುಂದಿನ ಮರುಲೋಡ್ ನಂತರ ಹೋಗುತ್ತದೆ.
ಸರ್ವರ್-ಸೈಡ್ ನಿಯಮಗಳು ಸೇವೆ ಪ್ರಾರಂಭದಲ್ಲಿ ಲೋಡ್ ಮಾಡುವ ಸಂರಚನಾ ಫೈಲ್‌ಗೆ ಸೇರಿವೆ, ನೀವು ಮುಚ್ಚಿದಾಗ ಕೊನೆಗೊಳ್ಳುವ ಸಂವಾದಾತ್ಮಕ ಅಧಿವೇಶನಕ್ಕಲ್ಲ. ನಿಯಮ ಬರೆಯಿರಿ, ಮರುಲೋಡ್ ಮಾಡಿ, ಮತ್ತು ಕೌಂಟರ್ ಚಲಿಸಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ವಾಕ್ಯರಚನೆಯನ್ನು ತಿರಸ್ಕರಿಸಿದ ಮರುಲೋಡ್ ಹಳೆಯ ನಿಯಮ ಸಮೂಹವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಅದರ ಜಾಗದಲ್ಲಿ ಬಿಡುತ್ತದೆ.
ನಂತರ ಮೂಲ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಯಾವ ಪದರ ಬದಲಾಯಿತು ಎಂದು ದಾಖಲಿಸಿ. ಫಿಲ್ಟರ್ ಬದಲಾವಣೆಯೂ ಬೇಕಿದ್ದ ರೂಟ್ ಸರಿಪಡಿಸುವಿಕೆ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಮೊದಲನೆಯದು ಹೋಯಿತು ಎಂದು ತಿಳಿದ ನಂತರ ಎರಡನೇ ವೈಫಲ್ಯವನ್ನು ಓದುವುದು ಬಹಳ ಸುಲಭ. ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ದಿನಾಂಕ ಮತ್ತು ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ರೂಟಿಂಗ್ ಮತ್ತು ಫಿಲ್ಟರಿಂಗ್ ಎರಡರ ಡೀಫಾಲ್ಟ್‌ಗಳು ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಬದಲಾಗುತ್ತವೆ. ಆ ಟಿಪ್ಪಣಿಯನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಇಡಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಎರಡು ಹಂತದ ಪ್ರಯಾಣವನ್ನು ಪುನರಾವರ್ತಿಸದೆ ನೀವು ನಿಲ್ಲಿಸಿದ ಸ್ಥಳದಿಂದ ಪ್ರಾರಂಭಿಸಲಿ.