SSH ಮತ್ತು VPN ಒಳಬರುವ ನಿಯಮಗಳು: ಅನುಮತಿ ಪಟ್ಟಿ ನಿಜವಾಗಿ ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ

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

ಒಂದು SSH ಪ್ರಯತ್ನವನ್ನು ಒಳಬರುವ ಕೊಕ್ಕೆಯವರೆಗೆ ಅನುಸರಿಸಿ

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

ನಂತರ ಆಲಿಸುವವರನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಇಲ್ಲದ ಸೇವೆಯನ್ನು ಯಾವ ನಿಯಮವೂ ಉಳಿಸಲಾರದು. ss -ltnp ಚಲಾಯಿಸಿ ಮತ್ತು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಪೋರ್ಟ್ ಹಾಗೂ ವಿಳಾಸ ಕುಟುಂಬಕ್ಕೆ ಏನಾದರೂ ಬದ್ಧವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ssh -v ಓದಿ ಅದು ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ನೋಡಿ.

ಮುಂದುಗಡೆ ಕಳುಹಿಸುವುದು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ

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

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

ಬಿಡುವುದು ಮತ್ತು ನಿರಾಕರಿಸುವುದು ಕ್ರಿಯೆಗಳು, ನೀತಿಗಳಲ್ಲ

ಮೂಲ ಸರಣಿಯ ನೀತಿ ಸ್ವೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಬಿಸಾಡುತ್ತದೆ, ಮತ್ತು ಆಯ್ಕೆಗಳ ಪೂರ್ಣ ಪಟ್ಟಿ ಅಷ್ಟೇ, ಎಂದು nftables ಉಲ್ಲೇಖ ಹೇಳುತ್ತದೆ. ನಿರಾಕರಣೆ ಆಯ್ದ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗಿನ ನಿಯಮ-ಕ್ರಿಯೆಯಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ನೀತಿಯಾಗಿ ಬರೆಯುವುದು nftables ಮತ್ತು iptables ಎರಡರಲ್ಲೂ ವಿಫಲವಾಗುತ್ತದೆ. ವಾಸ್ತವದಲ್ಲಿ drop ಕ್ಲೈಂಟ್‌ಗೆ ಯಾವ ಮಾಹಿತಿಯನ್ನೂ ಕೊಡುವುದಿಲ್ಲ, ಆದರೆ reject ಅದಕ್ಕೆ ಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದ ದೋಷವನ್ನು ಕೊಡುತ್ತದೆ.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

ನಿಜವಾಗಿ ಬೇಕಾದ ನಿಯಂತ್ರಣ ಸಂಚಾರವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ

ಎಲ್ಲಾ ICMP ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದು ಮಾರ್ಗದ MTU ಶೋಧನೆಯನ್ನು ಮುರಿಯುವ ಜನಪ್ರಿಯ ಡೀಫಾಲ್ಟ್, ಮತ್ತು ಲಕ್ಷಣವೆಂದರೆ ಸ್ಥಾಪನೆಯಾಗಿ ನಂತರ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ ನಿಲ್ಲುವ ಸಂಪರ್ಕ. IPv6 ನಲ್ಲಿ ನೆರೆಹೊರೆ ಶೋಧನೆ ತನ್ನದೇ ICMPv6 ಪ್ರಕಾರಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಅವನ್ನು ಬಿಸಾಡಿದರೆ ಯಾವುದೇ TCP ನಿಯಮ ಪರಿಶೀಲನೆಗೆ ಮೊದಲೇ ಕೊಂಡಿ ಮುರಿಯುತ್ತದೆ. ಎರಡೂ ಸಹ ವ್ಯಾಪಕ ಅನುಮತಿಗಳಲ್ಲ, ಹೆಸರಿಸಿದ ಅವಲಂಬನೆಗಳಾಗಿ ಅನುಮತಿ ಪಟ್ಟಿಗೆ ಸೇರುತ್ತವೆ. ಶೋಧನೆಯನ್ನು ಮೌನವಾಗಿ ಮುರಿಯುವ ನೀತಿ ಸ್ವಲ್ಪ ರೋಗನಿರ್ಣಯ ಸಂಚಾರವನ್ನು ಒಪ್ಪುವ ನೀತಿಗಿಂತ ಕೆಟ್ಟದು.

ನೀವು ಪ್ರಾರಂಭಿಸಿದ ಸಂಪರ್ಕಗಳಿಗೆ established ಮತ್ತು related ಸ್ಥಿತಿಗಳನ್ನು ಅನುಮತಿಸಿ, ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸ್ಥಿತಿ-ಅರಿವಿನ ಎಂಜಿನ್‌ಗೆ ಬಿಡಿ. ನಂತರ ಪ್ರತಿಕ್ರಿಯೆಯ ಮಾರ್ಗ ಮುಂದೆ ನಿರ್ಬಂಧಿತವಾಗಿಲ್ಲ ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಹೊರಹೋಗುವ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಇರುವ ನಿರ್ಬಂಧ ನೀವು ಹೋಸ್ಟ್ ಮೇಲೆ ಹಾಕಲಿದ್ದ ಅದೇ ಟೈಮ್‌ಔಟ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಹಳೆಯ ಮಾರ್ಗವನ್ನು ತ್ಯಜಿಸುವ ಮೊದಲು ಚೇತರಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

VPN ಸೇವೆಗೆ, ಎಂದಿಗೂ ಸಂಪರ್ಕಿಸದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಮುಂದುವರಿಸಿದ ಅಧಿವೇಶನ ಹೊಸದು ಮಾತುಕತೆ ನಡೆಸಬೇಕಾದ ಸ್ಥಿತಿಯನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಯಶಸ್ವಿಯಾದ ನಿಖರ ನಿಯಮಗಳ ಗುಂಪನ್ನು ಚೆಕ್ಸಮ್ ಅಥವಾ ಪ್ರತಿಯೊಂದಿಗೆ ದಾಖಲಿಸಿ, ನಂತರದ ಸಂಪಾದನೆ ಊಹಿಸುವ ಬದಲು ಹೋಲಿಸಬಹುದು. ನಿಯಮಗಳ ಕ್ರಮದ ಮಾಲೀಕರೊಂದಿಗೆ ಸಮನ್ವಯ ಮಾಡಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ನಿಯಮ ನೀವು ಸೇರಿಸಿದ ನಿಯಮದ ಮೇಲೆ ಮೌನವಾಗಿ ಗೆಲ್ಲುತ್ತದೆ.