VPN ಮೂಲಕ PostgreSQL: pg_hba ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ

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

ಒಟ್ಟುಗೂಡಿಸಬಾರದ ಮೂರು ನಿರ್ಧಾರಗಳು

ಸರ್ವರ್ ಎಲ್ಲಿ ಕೇಳುತ್ತದೆ ಎಂಬುದು ಒಂದು ನಿರ್ಧಾರ. ಯಾವ ಸಂಚಾರ ಆ ವಿಳಾಸವನ್ನು ತಲುಪಬಹುದು ಎಂಬುದು ಎರಡನೆಯದು, ಅದನ್ನು ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ ಮತ್ತು ಅದರ ಮುಂದಿನ ಯಾವುದೇ ಜಾಲರಿ ಗಡಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಯಾವ ಡೇಟಾಬೇಸ್ ಗುರುತು ಯಾವ ಮೂಲದಿಂದ ದೃಢೀಕರಿಸಬಹುದು ಎಂಬುದು ಮೂರನೆಯದು, ಅದನ್ನು pg_hba.conf ನಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.

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

ಸರ್ವರ್ ಎಲ್ಲಿ ಕೇಳುತ್ತದೆ

ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಗಲ್ಲ, ಯಂತ್ರಕ್ಕೆ ನಿಜವಾಗಿ ನಿಗದಿಪಡಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿ:

listen_addresses = '10.20.0.30'

ಡೇಟಾಬೇಸ್ ತನ್ನದೇ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲದೆ VPN ಗೇಟ್ವೇ ಹಿಂದೆ ಇರಬಹುದು, ಮತ್ತು ಅದಕ್ಕೇ ವಿಳಾಸವೇ ಹೆಸರಿಸಲು ಸರಿಯಾದ ವಸ್ತು. ಈ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸಲು ಪೂರ್ಣ ಮರುಪ್ರಾರಂಭ ಬೇಕು; ಮರುಲೋಡ್ ಸಾಕಾಗುವುದಿಲ್ಲ.

ನಂತರ ಪೋರ್ಟ್, ಸಾಮಾನ್ಯವಾಗಿ 5432, ಹೋಸ್ಟ್ನಲ್ಲಿ ಮತ್ತು ಅದರ ಮುಂದಿನ ಪ್ರತಿ ಗಡಿಯಲ್ಲಿ ಫಿಲ್ಟರ್ ಮಾಡಿ. ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸುವುದು ಸಾರ್ವಜನಿಕ ನಿರಾಕರಣೆಯ ಸಾಕ್ಷಿಯಲ್ಲ, ಏಕೆಂದರೆ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ ಅಥವಾ ಕ್ಲೌಡ್ ವಿಳಾಸ ಮ್ಯಾಪಿಂಗ್ ಇನ್ನೂ ಆ ಖಾಸಗಿ ಲಿಸನರ್ಗೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತಲುಪಿಸಬಹುದು.

HBA ನಿಜವಾಗಿ ನೋಡುವ ವಿಳಾಸ

ರೂಟೆಡ್ ಪ್ರವೇಶದಲ್ಲಿ ಸರ್ವರ್ ಪ್ರತಿ ಕ್ಲೈಂಟ್ನ ಒಳಗಿನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಮೂಲ ಅನುವಾದದಲ್ಲಿ ಅದು ಬದಲಿಗೆ ಗೇಟ್ವೇಯ ಅನುವಾದಿತ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಆ ಒಂದೇ ಮೌಲ್ಯಕ್ಕೆ ಕುಸಿಯುತ್ತದೆ. ಅನುಮತಿಸಲು ಪ್ರಿಫಿಕ್ಸ್ ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಸರ್ವರ್ನ ಸ್ವಂತ ಸಂಪರ್ಕ ಸಾಕ್ಷ್ಯಗಳ ಮೂಲಕ ಮೂಲವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಈಗಾಗಲೇ TLS ಮತ್ತು SCRAM ಬಳಸುವ ನಿಯೋಜನೆಗೆ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಕುಚಿತ ದೂರಸ್ಥ ಪ್ರವೇಶದ ಉದಾಹರಣೆ ಹೀಗಿದೆ:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

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

ಅನುವಾದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದ್ದಾಗ, HBA ಕ್ಲೈಂಟ್ಗಳನ್ನು ಅವರ ಮೂಲ ವಿಳಾಸಗಳಿಂದ ಬೇರ್ಪಡಿಸಲಾರದು. ಜಾಲರಿ ಪ್ರವೇಶವನ್ನು ಬಿಗಿಯಾಗಿಡಿ ಮತ್ತು ನೈಜ ಡೇಟಾಬೇಸ್ ರುಜುವಾತುಗಳನ್ನು ಕೇಳಿ, ಮತ್ತು trust ದೃಢೀಕರಣವನ್ನು ನಿಜವಾದ ಖಾತೆಯಿಂದ ಎಂದಿಗೂ ಬದಲಾಯಿಸಬೇಡಿ.

ಮೊದಲ ಹೊಂದಾಣಿಕೆಯೇ ಗೆಲುವು, ಬದಲಿ ಇಲ್ಲ

PostgreSQL ಫೈಲ್ ಅನ್ನು ಮೇಲಿನಿಂದ ಕೆಳಗೆ ಓದಿ, ಸಂಪರ್ಕಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಮೊದಲ ದಾಖಲೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಆ ದಾಖಲೆಯ ದೃಢೀಕರಣ ವಿಫಲವಾದರೆ ಎರಡನೇ ಪ್ರಯತ್ನವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹಿಂದಿನ ವಿಶಾಲ ಅನುಮತಿ ನಂತರದ ನಿರಾಕರಣೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಸೋಲಿಸುತ್ತದೆ.

ಜಾಗರೂಕತೆಯಿಂದ ಬರೆದ ನಿರಾಕರಣೆ ಎಂದಿಗೂ ಜಾರಿಗೆ ಬಾರದಿರುವುದಕ್ಕೆ ಈ ಕ್ರಮ ನಿಯಮವೇ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಕಾರಣ. ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳನ್ನು ಮೊದಲು, ವಿಶಾಲವಾದವನ್ನು ಕೊನೆಯಲ್ಲಿ ಇರಿಸಿ, ನಂತರ ಫೈಲ್ ಅನ್ನು ಗುಂಪಾಗಿ ಅಲ್ಲ, ಕ್ರಮವಾಗಿ ಓದಿ. ಕೆಳಗೆ ಸೇರಿಸಿದ ನಿಯಮ ನೀತಿಯಲ್ಲ, ಅದು ಟಿಪ್ಪಣಿ. ಫೈಲ್ ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಅದನ್ನು ಮೇಲೆ ಸರಿಸಿ ಮರುಲೋಡ್ ಮಾಡಿ.

HBA ಉಲ್ಲೇಖ ಕ್ರಮ ಮತ್ತು host ಹಾಗೂ hostssl ದಾಖಲೆಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಎರಡನ್ನೂ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ನಿಯಮದ ಉದ್ದೇಶ ಸಂಪರ್ಕವು ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿರಬೇಕು ಎಂಬುದಾದಾಗ ಇದು ಮುಖ್ಯ.

ಮರುಲೋಡ್, ಮರುಪ್ರಾರಂಭ ಮತ್ತು ನಿರಾಕರಿಸಿದ ಸಂದರ್ಭ

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

ಲಿಸನರ್ ಬದಲಾವಣೆಗಳಿಗೆ ಅವುಗಳದೇ ಮರುಪ್ರಾರಂಭ ಬೇಕು, ಮತ್ತು ಬದಲಾವಣೆಗೆ ಪರಿಣಾಮವಿಲ್ಲದಂತೆ ಕಂಡಾಗ ಎರಡು ಕ್ರಿಯೆಗಳನ್ನು ಗೊಂದಲಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ.

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