VPN ವಿಳಾಸಕ್ಕೆ ಜೋಡಿಸಲಾದ NFS ರಫ್ತು: ಅದು ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ
ರಫ್ತು ನಿಯಮವು ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಂದ ಬಂತು ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ; AUTH_SYS ಸ್ಥಳೀಯ UID ಅನ್ನು ಘೋಷಿಸುತ್ತದೆ ಮತ್ತು Kerberos ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಫೈಲ್ ಸೇವೆಗೆ ಯಾವುದು ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ.
ಒಂದು ಹೋಸ್ಟ್ ಡೈರೆಕ್ಟರಿಯನ್ನು VPN ವಿಳಾಸಕ್ಕೆ ರಫ್ತು ಮಾಡುತ್ತದೆ, ಮೌಂಟ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಮತ್ತು ವಿನ್ಯಾಸವನ್ನು ದೃಢೀಕೃತ ಎಂದು ಬರೆಯಲಾಗುತ್ತದೆ. ಆ ನಿಯಮವು ನಿಜವಾಗಿ ಸೀಮಿತಗೊಳಿಸುವುದು ಪ್ಯಾಕೆಟ್ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ ಎಂದು ಕಾಣುತ್ತದೆಯೋ ಅದನ್ನು ಮಾತ್ರ. ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಡೆಸುತ್ತಿರುವ ವ್ಯಕ್ತಿ ತಾನು ಹೇಳಿಕೊಳ್ಳುವವನೇ ಹೌದೇ ಎಂಬುದು NFS ಭದ್ರತಾ ಫ್ಲೇವರ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಮತ್ತು ಈ ರೀತಿಯ ಹೆಚ್ಚಿನ ರಫ್ತುಗಳಲ್ಲಿ ಯಾರೂ ಅದನ್ನು ಡೀಫಾಲ್ಟ್ನಿಂದ ಬದಲಿಸಿಲ್ಲ.
ಒಂದೇ ವಿನಂತಿಯಲ್ಲಿ ಮೂರು ಗುರುತುಗಳು ಕಾಣಿಸಬಹುದು
VPN ಪೀರ್ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಪೀರ್ ಕೀಯಂತಹ ನೋಂದಾಯಿತ ಗುರುತನ್ನು ಹೊತ್ತಿರುತ್ತದೆ. ಒಳಗಿನ IP ಪ್ಯಾಕೆಟ್ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊತ್ತಿರುತ್ತದೆ. ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಯು ಅದರ NFS ಕಾರ್ಯವಿಧಾನ ಒದಗಿಸುವ ಬಳಕೆದಾರ ರುಜುವಾತುಗಳನ್ನು ಹೊತ್ತಿರುತ್ತದೆ. ವಿಳಾಸವನ್ನು ಮೂರರಿಗೂ ಪ್ರತಿನಿಧಿಯಾಗಿ ಪರಿಗಣಿಸುವ ವಿನ್ಯಾಸವು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದ್ದ ಭಾಗವನ್ನೇ ಸದ್ದಿಲ್ಲದೆ ಊಹಿಸಿಕೊಂಡಿದೆ.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ಆ ಮೂರು ಸಾಲುಗಳನ್ನು ಬರೆಯುವುದೇ ಇಡೀ ಅಭ್ಯಾಸ. ರಫ್ತು ಸುರಕ್ಷಿತವೇ ಎಂಬ ಚರ್ಚೆಯ ಬಹುಪಾಲು ಯಾವ ನಿಯಂತ್ರಣ ಯಾವ ಸಾಲಿನಲ್ಲಿ ಇರುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾದಾಗ ಕುಸಿಯುತ್ತದೆ.
ವಿಳಾಸದ ಮಾಲೀಕತ್ವವು ಅನುಷ್ಠಾನದ ವಿವರ
ಗೇಟ್ವೇ ಸ್ವೀಕೃತ ಪೀರ್ಗೆ ಸುರಂಗ ವಿಳಾಸವನ್ನು ನಿಯೋಜಿಸಬಹುದು, ಅಥವಾ ಅದಕ್ಕೆ ಮಾರ್ಗನಿರ್ದೇಶಿತ ಉಪಜಾಲವನ್ನು ಅಧಿಕೃತಗೊಳಿಸಬಹುದು. ನಂತರ ಅನುಷ್ಠಾನವು ಒಳಗಿನ ಮೂಲವು ಬೇರೆ ಕ್ಲೈಂಟ್ಗೆ ಸೇರಿದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆಯೇ ಎಂಬುದು ಆ ಅನುಷ್ಠಾನದ ಗುಣಲಕ್ಷಣ, ಮತ್ತು ಊಹಿಸುವ ಬದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯ.
ಸಾಂಪ್ರದಾಯಿಕ Community OpenVPN ಬಳಕೆದಾರ-ಸ್ಥಳ ಸರ್ವರ್ ಕೋಡ್, ಉದಾಹರಣೆಗೆ, ಪ್ಯಾಕೆಟ್ TUN ಸಾಧನದ ಮೂಲಕ ತಲುಪಿಸುವ ಮೊದಲು ಬೇರೆ ಕ್ಲೈಂಟ್ಗೆ ಸಂಬಂಧಿಸಿದ ಮೂಲವನ್ನು ನಿರಾಕರಿಸಬಹುದು. ಅದು ನಿಜವಾದ ಮೌಲ್ಯವಿರುವ ವಿಳಾಸ-ಮಾಲೀಕತ್ವ ಪರಿಶೀಲನೆ, ಮತ್ತು ಅದು ಇನ್ನೂ NFS ಬಳಕೆದಾರ ದೃಢೀಕರಣವಲ್ಲ, ಏಕೆಂದರೆ ಯಾವ ಖಾತೆ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡುತ್ತಿದೆ ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ.
ಮೂಲ ಅನುವಾದವು ಅದನ್ನೂ ಸವೆಸುತ್ತದೆ. NAT ಗೇಟ್ವೇ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ಒಂದೇ ವಿಳಾಸವಾಗಿ ತೋರಿಸಬಹುದು, ಆಗ ರಫ್ತು ನಿಯಮವು ಅದರ ಹಿಂದಿನ ಜನರನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾರದು. ನಿಯಮದ ಮೇಲ್ನೋಟದ ಸೂಕ್ಷ್ಮತೆ ಆಗ ರೇಖಾಚಿತ್ರದಿಂದ ಕಾಪಾಡಲ್ಪಟ್ಟ ಕಲ್ಪನೆಯಾಗುತ್ತದೆ. ರಫ್ತು ಮುಖ್ಯವಾದರೆ, ಯಾರು ಯಾರಿಗೆ ಬದಲಾಗಿ ಎಣಿಕೆಯಾಗುತ್ತಾರೆ ಎಂದು ಅನುವಾದಕರಿಗೆ ಬಿಡದೆ ವಿಳಾಸೀಕರಣವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ.
ರಫ್ತನ್ನು ನಂಬುವ ಮೊದಲು ಭದ್ರತಾ ಫ್ಲೇವರ್ ಓದಿ
Red Hat ನ NFS ಮಾರ್ಗದರ್ಶನವು AUTH_SYS ಮೂಲಕ ಸ್ಥಳೀಯ UNIX UID ಮತ್ತು GID ಬಳಸುವ sec=sys ಅನ್ನು Kerberos ಕ್ರಮಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. krb5 ಬಳಕೆದಾರ ದೃಢೀಕರಣ ಸೇರಿಸುತ್ತದೆ, krb5i ಅಖಂಡತೆ ರಕ್ಷಣೆ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು krb5p ಸಂಚಾರಕ್ಕೆ ಗೋಪ್ಯತೆ ರಕ್ಷಣೆ ಸೇರಿಸುತ್ತದೆ.
AUTH_SYS ರುಜುವಾತಿನಲ್ಲಿ ಕರೆಗಾರನ UID ಮತ್ತು ಗುಂಪು ಗುರುತಿಸುವಿಕೆಗಳಂತಹ ಕ್ಷೇತ್ರಗಳಿರುತ್ತವೆ, ಮತ್ತು RFC 5531 ಈ ಫ್ಲೇವರ್ ತಾನಾಗಿಯೇ ಯಾವುದೇ ಭದ್ರತೆ ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಬಾಹ್ಯ ರಕ್ಷಣೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಎಚ್ಚರಿಸುತ್ತದೆ. ಅದನ್ನು VPN ಒಳಗೆ ನಡೆಸುವುದು ಸಾಗಣೆಗೆ ರಕ್ಷಣೆ ನೀಡುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಒಳಗಿನ ಹೇಳಿಕೆಯಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.
exportfs -v
showmount -e nfs.example.internalಕ್ಲೈಂಟ್ ಪಟ್ಟಿಯನ್ನು ಓದುವ ಮೊದಲು ಆ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಫ್ಲೇವರ್ ಓದಿ. ಸೀಮಿತವಾಗಿ ಕಾಣುವ ರಫ್ತು ಕೇವಲ ವಿಳಾಸದಿಂದ ಸೀಮಿತವಾಗಿರಬಹುದು, ಆದರೆ ಪ್ರತಿ ಕರೆಗಾರನೂ ಇನ್ನೂ ತನಗಿಷ್ಟವಾದ UID ಅನ್ನು ಘೋಷಿಸುತ್ತಾನೆ.
ಮಾದರಿಯನ್ನು ಆರಿಸಿ, ನಂತರ ಅನುಮತಿಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ
ನೀವು ನಿಜವಾಗಿ ನಿರ್ವಹಿಸುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಸೂಕ್ತವಾದ ಫೈಲ್-ಸೇವಾ ದೃಢೀಕರಣ ಮಾದರಿಯನ್ನು ಆರಿಸಿ. Kerberos ತನ್ನ ಹಿಂದೆ ಗುರುತು ಮತ್ತು ಸೇವಾ ನಿಯೋಜನೆ ಅಗತ್ಯವಿದೆ, ಆದ್ದರಿಂದ ಒಂದು ಮೌಂಟ್ ಆಯ್ಕೆಯನ್ನು ಬದಲಿಸುವುದು ವಲಸೆ ಅಲ್ಲ ಮತ್ತು Kerberos ಡೊಮೇನ್, ಪ್ರಿನ್ಸಿಪಾಲ್ಗಳು ಮತ್ತು keytabಗಳು ಇರುವವರೆಗೆ ಅದು ಕೇವಲ ವಿಫಲವಾಗುತ್ತದೆ.
ಎರಡೂ ಮಾದರಿಗಳಲ್ಲಿ, ದೃಢೀಕೃತ ಪ್ರಿನ್ಸಿಪಾಲ್ ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ರಫ್ತು ಅನುಮತಿಗಳನ್ನು ಮತ್ತು ಫೈಲ್ಸಿಸ್ಟಂ ಅಧಿಕಾರವನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ. ದೃಢೀಕರಣವು ಯಾರು ಕೇಳುತ್ತಿದ್ದಾರೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಅಧಿಕಾರವು ಉತ್ತರ ಹೌದು ಆಗಿರಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಈ ಎರಡನ್ನೂ ಒಂದೇ ಸೆಟ್ಟಿಂಗ್ಗೆ ಸೇರಿಸುವುದೇ ವಲಸೆಯು ಹಳೆಯ ಸಂರಚನೆಗಿಂತ ಹೆಚ್ಚು ನೀಡುವ ರೀತಿ.
ವಿಳಾಸ ನಿಯಮವನ್ನು ಅದರ ನಿಜವಾದ ಉದ್ದೇಶಕ್ಕೆ ಬಳಸಿ
ಸೇವೆಯನ್ನು ಅನುಮೋದಿತ ಮಾರ್ಗ ಮತ್ತು ಮೂಲಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವುದು ಇನ್ನೂ ಯೋಗ್ಯ, VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತು NFS ಸರ್ವರ್ ಒಂದೇ ಯಂತ್ರವನ್ನು ಹಂಚಿಕೊಂಡಾಗ ಹೋಸ್ಟ್ ಇನ್ಪುಟ್ ನೀತಿಯೂ ಸೇರಿದಂತೆ. ಸಂಚಾರವನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿಯಮಗಳು ಈ ಕೆಳಗಿನವುಗಳಿಗೆ ಗುರಿಯಾಗಿರುವ ವಿನಂತಿಗಳನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ: ಅದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇವೆ. ಈ ಅಂತರವು ಖಾಸಗಿಯಾಗಿರಬೇಕಿದ್ದ ಆಶ್ಚರ್ಯಕರ ಸಂಖ್ಯೆಯ ರಫ್ತುಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸುರಂಗ ನಿಯಮಗಳು ಅದನ್ನು ಆವರಿಸುತ್ತವೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಸ್ಥಳೀಯ ಇನ್ಪುಟ್ ನೀತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪರಿಶೀಲಿಸಿ.
ಬೇರೆ ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಮೂಲ-ಅನುವಾದ ಮಾಡುವ ಗೇಟ್ವೇ ನಿಯಮವನ್ನು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಪೂರೈಸಲಾರದು ಎಂದು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಅದನ್ನು ವಿಳಾಸವನ್ನು ನಕಲಿ ಮಾಡುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೌಂಟ್ಗೆ ಖಾತರಿ ಎಂಬ ಹೇಳಿಕೆಯಲ್ಲ, ಮೂಲವನ್ನು ಸ್ಥಾಪಿಸುವ ಕಾರಣವೆಂದು ಪರಿಗಣಿಸಿ.
ಒಂದರ ಬದಲು ಮೂರು ಸ್ವೀಕೃತಿ ಪ್ರಕರಣಗಳನ್ನು ನಡೆಸಿ. ಅನುಮೋದಿತ ಕ್ಲೈಂಟ್ನೊಂದಿಗೆ ಅನುಮೋದಿತ ಬಳಕೆದಾರನಾಗಿ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಎಂದೂ ಅನುಮೋದಿಸದ ಪೀರ್ನಿಂದ ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಅನುಮೋದಿತ ಬಳಕೆದಾರನಿಗೆ ಇನ್ನೂ ಅನುಮತಿಸದ ಯಾವುದನ್ನಾದರೂ ಪ್ರಯತ್ನಿಸಿ. ನಂತರ ಅಧಿಕೃತ ಕ್ಲೈಂಟ್ ರಾಜಿಯಾದರೆ ಏನು ಬದಲಾಗುತ್ತದೆ ಎಂದು ಕೇಳಿ, ಏಕೆಂದರೆ ಸಾಗಣೆ ದೃಢೀಕರಣವು ಆ ಯಂತ್ರದ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನೂ ವಿಶ್ವಾಸಾರ್ಹಗೊಳಿಸುವುದಿಲ್ಲ. ಕದಿಯಲಾದ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಕುತೂಹಲಿ ಸ್ಥಳೀಯ ಖಾತೆ ಬೇರೆ ಬೇರೆ ನಿಯಂತ್ರಣಗಳಿರುವ ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು.