UFW ನಿಯಮಗಳಿಂದ OpenVPN ಗೇಟ್ವೇಯನ್ನು ಒಂದು LAN ಗೆ ಸೀಮಿತಗೊಳಿಸಿ

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

ಮೊದಲು ಟೋಪೋಲಜಿ ಮತ್ತು ಅನುಮತಿಯನ್ನು ಬರೆಯಿರಿ

ಉದಾಹರಣೆ ಬಳಸುವುದು ಬಳಕೆದಾರ ಸ್ಥಳದ TUN ಸಾಧನವನ್ನು ಎಂದು ಕರೆಯಲಾದ Community OpenVPNtun0 ಸರ್ವರ್, ಕ್ಲೈಂಟ್ ಪೂಲ್ 10.77.0.0/24, ಮತ್ತು ಒಂದು ಸಂಪರ್ಕಿತ ಸಬ್ನೆಟ್ 192.168.60.0/24 lan0 ಮೇಲೆ. IPv4 ಮುಂದುವರಿಕೆ ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು LAN ಗೆ ಪೂಲ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಈಗಾಗಲೇ ಇದೆ, ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಏನೂ ಅವುಗಳ ನಡುವಿನ ಅನುವಾದವನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ.

ಈ ಹೋಸ್ಟ್ನ ಫೈರ್ವಾಲ್ UFW ಒಡೆತನದಲ್ಲಿದೆ, ಮತ್ತು ಯಾವುದೇ ಕಂಟೇನರ್ ನಿಯಮಸಂಗ್ರಹ ಅಥವಾ ಪ್ರತ್ಯೇಕ nftables ಕೋಷ್ಟಕವು ಹಿಂದಿನ ಸ್ವೀಕಾರ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಬಾರದು. ಫಿಲ್ಟರ್ ಬೈಪಾಸ್ ಮಾಡುವ ಫ್ಲೋ-ಆಫ್ಲೋಡ್ ಶಾರ್ಟ್ಕಟ್ ರಕ್ಷಣಾ ಸರಪಳಿಗಳನ್ನು ಕೇವಲ ಅಲಂಕಾರವಾಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೂ ಸಕ್ರಿಯವಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. OpenVPN ನ ಸ್ವಂತ client-to-client ಮುಂದುವರಿಕೆಯನ್ನು ನಿಷ್ಕ್ರಿಯವಾಗಿ ಬಿಡಿ, ಏಕೆಂದರೆ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಫಿಲ್ಟರ್ ಅನ್ನು ಎಂದಿಗೂ ದಾಟದ ಸಮಾನರ ನಡುವಿನ ಸಂಚಾರ ಅದರಿಂದ ಸೀಮಿತಗೊಳಿಸಲಾಗದು. ಬಾಹ್ಯ ಶ್ರೋತ ಮತ್ತು ಆಡಳಿತ ನಿಯಮಗಳು ಇರುವಂತೆಯೇ ಉಳಿಯುತ್ತವೆ, ಏಕೆಂದರೆ ಈ ಬದಲಾವಣೆ ಫೈರ್ವಾಲ್ ಬದಲಿಸುವ ಬದಲು ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಟನೆಲ್ ಸಂಚಾರವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ.

ರಕ್ಷಕರನ್ನು UFW ನ ಆರಂಭಿಕ ಸ್ವೀಕಾರಗಳ ಮುಂಚೆ ಇರಿಸಿ

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

ಫೈಲ್ನ *filter ವಿಭಾಗದಲ್ಲಿ /etc/ufw/before.rules ಇರುವ ಘೋಷಣೆಗಳ ಪಕ್ಕದಲ್ಲಿ ಮತ್ತು ಯಾವುದೇ ನಿಯಮ ಸಾಲಿನ ಮೊದಲು ಎರಡು ಸರಪಳಿಗಳನ್ನು ಘೋಷಿಸಿ.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

ಘೋಷಣೆಗಳ ನಂತರ ತಕ್ಷಣ, ಮತ್ತು ಇನ್ಪುಟ್ ಹಾಗೂ ಮುಂದುವರಿಕೆ ಅನುಮತಿಗಳ ಮೊದಲು, ಅವುಗಳೊಳಗೆ ನೆಗೆದು ಅವು ಏನನ್ನು ಅನುಮತಿಸುತ್ತವೆ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಿ.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

ಪ್ರತಿ ರಕ್ಷಕ ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ನಿರಾಕರಿಸುತ್ತದೆ ಎಂದು ಓದಿ

ಮೊದಲ ಸರಪಳಿ ಸಂಸ್ಕರಣೆಯನ್ನು ಮುಂದುವರಿಸುವುದು ಮೂಲವು ಪೂಲ್ನಲ್ಲಿದ್ದಾಗ, ಗಮ್ಯಸ್ಥಾನ ಆ ಒಂದು ಸಬ್ನೆಟ್ ಆಗಿದ್ದಾಗ, ನಿರ್ಗಮನ ಇಂಟರ್ಫೇಸ್ LAN ಆಗಿದ್ದಾಗ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ತನ್ನ ಹರಿವಿನ ಮೂಲ ದಿಕ್ಕಿನಲ್ಲಿ ಚಲಿಸುತ್ತಿದ್ದಾಗ ಮಾತ್ರ. ಟನೆಲ್ನಿಂದ ಬರುವ ಉಳಿದ ಎಲ್ಲವೂ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ, ಪೂಲ್ನ ಹೊರಗಿನ ಮೂಲ ಮತ್ತು ಅನುಮತಿಸಿದ ಸಬ್ನೆಟ್ನ ಆಚೆಗಿನ ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನ ಸೇರಿದಂತೆ.

ಸಮಾನರ ನಡುವಿನ ಪ್ಯಾಕೆಟ್ tun0 ಗೆ ಪ್ರವೇಶಿಸಿ ಅದರಿಂದ ನಿರ್ಗಮಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಗಮ್ಯಸ್ಥಾನ ಪರಿಶೀಲನೆಗೆ ತಲುಪುವ ಮೊದಲೇ ಅದು LAN ಇಂಟರ್ಫೇಸ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. LAN ನಿಂದ ಕ್ಲೈಂಟ್ಗಳ ಕಡೆಗೆ ಹೊಸ ಸಂಪರ್ಕಗಳು ಸಹ ಉತ್ತರ ದಿಕ್ಕಿನ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಇದು ಪೂರ್ವನಿಗದಿಯಾಗಿ ಹಿಮ್ಮುಖ ಕರೆ ಮಾರ್ಗವನ್ನು ಮುಚ್ಚುತ್ತದೆ.

RETURN ಗುರಿ ಸಾಮಾನ್ಯ UFW ನೀತಿಯನ್ನು ಜಾರಿಯಲ್ಲಿಡುತ್ತದೆ. ಈ ಸರಪಳಿಗಳು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತವೆ, ಮತ್ತು ನೀವು ಮುಂದೆ ಸೇರಿಸುವ ಮಾರ್ಗ ಅನುಮತಿ ಉಳಿದ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕೃತವಾಗುತ್ತದೆಯೇ ಎಂದು ಇನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ. ಆ ಬೇರ್ಪಡಿಕೆಯೇ ನಂತರ ಅನುಮತಿಸಿದ ಸಬ್ನೆಟ್ ಅನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಬದಲಿಸಲು ಅನುವು ಮಾಡುತ್ತದೆ. ರಕ್ಷಕರು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ನೇರವಾಗಿ ಸ್ವೀಕರಿಸಿದ್ದರೆ, ಪ್ರತಿ ಭವಿಷ್ಯದ ನಿಯಮವನ್ನು ಎರಡು ಬಾರಿ ಸೇರಿಸಬೇಕಾಗುತ್ತಿತ್ತು.

ಸಬ್ನೆಟ್ಗೆ ಅಧಿಕಾರ ನೀಡಿ ಮತ್ತು ಪಾರ್ಶ್ವ ದ್ವಾರಗಳನ್ನು ಮುಚ್ಚಿ

ಮೊದಲು ಮಾರ್ಗ ಅನುಮತಿಯ ಮುನ್ನೋಟ ನೋಡಿ, ನಂತರ ಅನ್ವಯಿಸಲು ಮುನ್ನೋಟ ಫ್ಲ್ಯಾಗ್ ತೆಗೆಯಿರಿ: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. ನಂತರ ಬಳಕೆದಾರ ನಿಯಮಗಳ ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ನಿರಾಕರಣೆ ಇನ್ನೂ ನಂತರದ ಅನುಮತಿಯ ಮೇಲೆ ಗೆಲ್ಲುತ್ತದೆ. ಇಡೀ ಸಬ್ನೆಟ್ಗೆ ಅನುಮತಿ ಸಹ ತಪ್ಪು ಆಕಾರ, ಯಾವಾಗ ಕೇವಲ ಒಂದು ಹೋಸ್ಟ್ನ HTTPS ಪೋರ್ಟ್ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು.

ಇನ್ಪುಟ್ ತಿರಸ್ಕಾರ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ: ಟನೆಲ್ ಕ್ಲೈಂಟ್ಗಳು ಗೇಟ್ವೇ ಮೇಲೆಯೇ ಯಾವುದೇ ಸೇವೆ ತಲುಪಲಾರರು, ಅದರ LAN ವಿಳಾಸಕ್ಕೆ ಬಂಧಿತವಾದ DNS ಶ್ರೋತ ಸೇರಿದಂತೆ. ಅಲ್ಲಿ DNS ಹೋಸ್ಟ್ ಮಾಡಲು ತಿರಸ್ಕಾರದ ಮೊದಲು ಉದ್ದೇಶಪೂರ್ವಕ ವಿನಾಯಿತಿ ಮತ್ತು ಪರಿಷ್ಕೃತ ಅನುಮತಿ ಒಪ್ಪಂದ ಬೇಕು. UFW IPv6 ನಿರ್ವಹಿಸಿದರೆ, tun0 ಗಾಗಿ before6.rules ಫೈಲ್ನಲ್ಲೂ ಹೊಂದಿಕೆಯಾಗುವ ತಿರಸ್ಕಾರಗಳನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ IPv4 ಗಮ್ಯಸ್ಥಾನಗಳ ಪಟ್ಟಿ IPv6 ಪ್ಯಾಕೆಟ್ಗಳ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.

ಮುನ್ನೋಟವಲ್ಲ, ಲೋಡ್ ಆದ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಮರುಲೋಡ್ನ ಮುನ್ನೋಟ ನೋಡಿ, ನಿರ್ವಹಣಾ ಕಿಟಕಿಯಲ್ಲಿ ಅನ್ವಯಿಸಿ, ಮತ್ತು ಜೀವಂತ ನಿಯಮಸಂಗ್ರಹ ಓದಿ.

sudo ufw --dry-run reload
sudo ufw show raw

ಟನೆಲ್ ರಕ್ಷಕರು ಪೂರ್ವನಿಗದಿ ಸ್ಥಿತಿ ಮತ್ತು ICMP ಅನುಮತಿಗಳ ಮೊದಲು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಸಾಮಾನ್ಯ ufw status ಕೈಯಿಂದ ಸಂಪಾದಿಸಿದ before ನಿಯಮಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕಾರ್ಯನಿರ್ವಾಹಕರು ನಿಯಮ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತಾರೆ, ಆದರೆ ಅದು ವಾಸ್ತವವಾಗಿ ಲೋಡ್ ಆಗಿದೆ. ತುಣುಕು ಹುಡುಕುವ ಬದಲು ಒರಟು ಪಟ್ಟಿಯನ್ನು ಮೇಲಿನಿಂದ ಕೆಳಗೆ ಓದಿ. ರಕ್ಷಕರು ಸ್ಥಿತಿ ಅನುಮತಿಯ ನಂತರ ಕಾಣಿಸಿಕೊಂಡರೆ, ಗಡಿ ಫೈಲ್ ಸೂಚಿಸುವುದನ್ನು ಮಾಡುತ್ತಿಲ್ಲ.

ನಂತರ ಪಠ್ಯವಲ್ಲ, ವರ್ತನೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ಅನುಮತಿಸಿದ ಹೋಸ್ಟ್ಗೆ ಹೊಸ ಸಂಪರ್ಕ ತೆರೆದು ಉತ್ತರ ನೋಡಿ, ಸಬ್ನೆಟ್ನ ಹೊರಗಿನ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ನಿರುಪದ್ರವ ವಿನಂತಿ ಕಳುಹಿಸಿ ಅದು ಸಾಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಸಮಾನರ ನಡುವಿನ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಿಸಿ, ಗೇಟ್ವೇ ಸ್ಥಳೀಯ ಸೇವೆ ಪ್ರಯತ್ನಿಸಿ, ಮತ್ತು ಕೇಳದ LAN-ನಿಂದ-ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಿಸಿ. ಬದಲಾವಣೆಗೆ ಮೊದಲು ಇದ್ದ ಒಂದು ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿನ ಹರಿವನ್ನು ಸೇರಿಸಿ, ಮತ್ತು ಯಂತ್ರದ ಇಡೀ ಟ್ರ್ಯಾಕಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಖಾಲಿ ಮಾಡುವ ಬದಲು ಆ ಹರಿವನ್ನು ಮಾತ್ರ ಅಳಿಸಿ.

ನಿಯಮಗಳ ಪಕ್ಕದಲ್ಲಿ ಮಿತಿಗಳನ್ನು ದಾಖಲಿಸಿ: ಇದು ಸಾಗಣೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಬೇರೆ ಏನನ್ನೂ ಅಲ್ಲ. ಇದು ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕ ಬಳಸುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ, ಅನುಮತಿಸಿದ LAN ಹೋಸ್ಟ್ ಸಂಚಾರವನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ, ಮತ್ತು ಅನುಮತಿಸಿದ ಸೇವೆಗಳ ಒಳಗಿನ ದೃಢೀಕರಣವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.