ಎರಡು ಸರ್ವರ್ಗಳಲ್ಲಿ ಒಂದು VPN ಖಾತೆ: ಮೂರು ಸ್ಥಿತಿ ಲೆಡ್ಜರ್ಗಳು
ಹಂಚಿದ ಪ್ರವೇಶ, ನೋಡ್-ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಸಂರಚನೆ ಮತ್ತು ಜೀವಂತ ಸೆಷನ್‌ಗಳು ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು. ಒಂದು ಖಾತೆಯನ್ನು ನೋಡ್‌ಗಳ ನಡುವೆ ನಕಲಿಸುವ ಮೊದಲು ಇವನ್ನು ಬೇರ್ಪಡಿಸಿ.
ಎರಡು VPN ನೋಡ್‌ಗಳಲ್ಲಿ ಯಾವುದಕ್ಕಾದರೂ ಸೈನ್ ಇನ್ ಮಾಡಬಲ್ಲ ಒಂದು ಖಾತೆ, ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಶ್ನೆಯಾಗುವ ಬಹಳ ಮೊದಲೇ ವಿನ್ಯಾಸ ಪ್ರಶ್ನೆಯನ್ನು ಎತ್ತುತ್ತದೆ. ಖಾತೆಯ ನೋಟ, ಪ್ರತಿ ನೋಡ್‌ನ ಸ್ವಂತ ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಹಿಡಿದಿರುವ ಸೆಷನ್, ಇವು ಮೂರು ವಿಭಿನ್ನ ರೀತಿಯ ಸ್ಥಿತಿಗಳು, ಮತ್ತು ಅವನ್ನು ಒಂದೆಡೆಯಿಂದ ಇನ್ನೊಂದೆಡೆಗೆ ನಕಲಿಸಿದಾಗ ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಮೂರನ್ನೂ ಒಂದೇ ವ್ಯವಸ್ಥೆಗೆ ನಕಲಿಸುವುದು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಸಾಮಾನ್ಯ ದಾರಿ.
ಕೆಳಗಿನ ಮೂರು ಲೆಡ್ಜರ್‌ಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಪ್ರತಿಯೊಂದೂ ಯಾವುದು ಅಧಿಕೃತ, ಯಾವುದು ಸ್ಥಳೀಯ ಮತ್ತು ಇನ್ನೊಂದು ನೋಡ್ ಇಲ್ಲದಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಗಳು ಒಂದರಿಂದ ಇನ್ನೊಂದು ಬರುವುದಿಲ್ಲ.
ಯಾರು ಸಂಪರ್ಕಿಸಬಹುದು: ಒಂದು ಅಧಿಕಾರ, ಅನೇಕ ನೋಡ್‌ಗಳು
ಪ್ರವೇಶ ಲೆಡ್ಜರ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ: ಯಾವ ಗುರುತಿನ ಮೂಲ ಅಧಿಕೃತ, ಯಾವ ಪ್ರಮಾಣಪತ್ರ ನೀಡುವವರನ್ನು ನಂಬಲಾಗುತ್ತದೆ, ಯಾವ ಖಾತೆಗಳು ಅರ್ಹ, ಯಾವ ಎರಡನೇ ಅಂಶ ಅನ್ವಯಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಖಾತೆ ಎಲ್ಲಿಯವರೆಗೆ ತಲುಪಬಹುದು. ನಂತರ ಪ್ರತಿ ನೋಡ್ ಬದಲಾವಣೆಗಳನ್ನು ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ಬೇಗ ಎಂದು ಬರೆಯಿರಿ.
ಹಂಚಿದ ಡೇಟಾಬೇಸ್ ಆ ಉತ್ತರದ ಒಂದು ಸಂಭಾವ್ಯ ಅಂಗ. ಪ್ರತಿ ಸಂಬಂಧಿತ ನೀತಿಯೂ ಅಲ್ಲೇ ಇರುತ್ತದೆ ಅಥವಾ ಪ್ರತಿ ನೋಡ್ ಒಂದೇ ಕ್ಷಣದಲ್ಲಿ ಬದಲಾವಣೆಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಇದು ಸಾಕ್ಷಿಯಲ್ಲ. ನೋಡ್ A ನಲ್ಲಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದರೂ ನೋಡ್ B ನಲ್ಲಿ ಇನ್ನೂ ಸ್ವೀಕರಿಸಲ್ಪಡುವ ಖಾತೆ ಎಂದರೆ ಆಫ್‌ಬೋರ್ಡಿಂಗ್ ಪ್ರಕ್ರಿಯೆ ಮುಗಿದಿಲ್ಲ.
ಅಧಿಕಾರ ತಲುಪಲಾಗದಿದ್ದಾಗ ನೋಡ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ ರುಜುವಾತುಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ಭದ್ರತಾ ವೆಚ್ಚವಿರುವ ನೀತಿ ಆಯ್ಕೆ, ಮತ್ತು ಅವನ್ನು ನಿರಾಕರಿಸುವುದು ಲಭ್ಯತೆಯ ವೆಚ್ಚವಿರುವ ನೀತಿ ಆಯ್ಕೆ. ಎರಡೂ ಸಮರ್ಥನೀಯ; ದಾಖಲೆ ಇಲ್ಲದೆ ಬಿಡುವುದು ಅಲ್ಲ.
ನೀಡುವವರ ಅಧಿಕಾರವನ್ನು ಖಾತೆ ಡೇಟಾದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಹಲವು ಗೇಟ್‌ವೇಗಳು ಅದರ ಸಹಿ ಕೀಲಿಯನ್ನು ಹಿಡಿಯದೆಯೇ ಒಂದೇ CA ಅನ್ನು ನಂಬಬಹುದು, ಮತ್ತು ಪ್ರತಿ ನೋಡ್‌ಗೆ ಇನ್ನೂ ತನ್ನದೇ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ತನ್ನದೇ ಕ್ಲೈಂಟ್-ಬದಿಯ ನಂಬಿಕೆ ಸಂಬಂಧ ಬೇಕು.
ನೋಡ್ ಏನನ್ನು ಹೊಂದಿದೆ: ವಿಳಾಸಗಳು ಮತ್ತು ಮಾರ್ಗಗಳು
ಎರಡನೇ ಲೆಡ್ಜರ್ ಪ್ರತಿ ನೋಡ್‌ಗೆ ಸ್ಥಳೀಯ: ಆಲಿಸುವ ವಿಳಾಸ, ಸರ್ವರ್ ಗುರುತು, ವಿಳಾಸ ಪೂಲ್, ಖಾಸಗಿ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಮಾರ್ಗಗಳು, ಪರಿಹಾರಕ ನೀತಿ ಮತ್ತು ಸಂಚಾರವು ಇಂಟರ್ನೆಟ್‌ನತ್ತ ಹೇಗೆ ಹೊರಡುತ್ತದೆ. ಅದೇ ಖಾತೆಯನ್ನು ಯಾವುದೇ ನೋಡ್ ಸೇವಿಸಬಹುದು, ಆದರೆ ಈ ವಸ್ತುಗಳು ಬೇರೆಯಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ.
ಹಿಂತಿರುಗುವ ಮಾರ್ಗವೇ ಮರೆತುಹೋಗುವ ಭಾಗ. ಎರಡೂ ನೋಡ್‌ಗಳು ಒಂದೇ ಪೂಲ್‌ನಿಂದ ವಿಳಾಸಗಳನ್ನು ಹಂಚಿದರೆ, ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ಯಾವ ನೋಡ್‌ಗೆ ಸೇರಿದೆ ಎಂದು ಹೇಳಲಾಗದು, ಮತ್ತು ಉತ್ತರ ತಪ್ಪು ಸ್ಥಳಕ್ಕೆ ಹೋಗಬಹುದು. ಬೇರೆ ಪೂಲ್‌ಗಳಿಗೂ ಮಾರ್ಗಗಳು ಮತ್ತು ಅನುಮತಿಗಳು ಬೇಕು, ಆದ್ದರಿಂದ ಬೇರೆ ಸಂಖ್ಯಾ ಶ್ರೇಣಿ ಪೂರ್ಣ ವಿನ್ಯಾಸವಲ್ಲ.
ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಂದು ನೋಡ್‌ಗೆ ಕಳುಹಿಸಿ. DNS ಆಯ್ಕೆ, ಕ್ಲೈಂಟ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪಟ್ಟಿಗಳು ಮತ್ತು ಫ್ರಂಟ್-ಎಂಡ್ ಸೇವೆ ವಿಭಿನ್ನ ಆರೋಗ್ಯ ಮತ್ತು ವೈಫಲ್ಯ-ಬದಲಾವಣೆ ವರ್ತನೆಯಿರುವ ವಿಭಿನ್ನ ಕಾರ್ಯವಿಧಾನಗಳು. ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಸರಿ; “ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್” ಅನ್ನು ವಿನ್ಯಾಸ ಎಂದು ಪರಿಗಣಿಸುವುದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ವೈಫಲ್ಯದ ವರ್ತನೆಯನ್ನು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಬಿಡುತ್ತದೆ.
ದಾಖಲಿತ ಉತ್ಪನ್ನ ಉದಾಹರಣೆ ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ. Pritunl ನ ನಕಲು ದಾಖಲೆ VPN ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಪ್ರತಿ ಪ್ರತಿಗೆ ವಸ್ತುವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ, ಮತ್ತು ಬೇರೆ ಪ್ರತಿಗಳಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ಗಳು ಒಬ್ಬರನ್ನೊಬ್ಬರು ತಲುಪಲು ಹೆಚ್ಚುವರಿ ಮಾರ್ಗಗಳು ಮತ್ತು ಸಂಪರ್ಕ ಬೇಕು. ಇದು ಉತ್ಪನ್ನ-ನಿರ್ದಿಷ್ಟ ಏರ್ಪಾಡು, Community OpenVPN ಗೆ ಪಾಕವಿಧಾನವಲ್ಲ, ಆದರೆ ಪ್ರತಿಯೊಂದನ್ನು ಸೇರಿಸುವುದು ಖಾತೆ ಸಂಗ್ರಹವಷ್ಟೇ ಅಲ್ಲ, ನೆಟ್‌ವರ್ಕನ್ನೂ ಬದಲಾಯಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಸೆಷನ್ ಎಂದರೇನು: ಜೀವಂತ ಸ್ಥಿತಿ, ಸಾಲಲ್ಲ
ಮೂರನೇ ಲೆಡ್ಜರ್ ಜೀವಂತ ಸೆಷನ್. ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ಗೆ ಅದನ್ನು ಸ್ವೀಕರಿಸಿದ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಸ್ಥಿತಿ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಹಂಚಿಕೆ ಇರುತ್ತದೆ. ಖಾತೆ ಇನ್ನೊಂದು ನೋಡ್‌ನಲ್ಲಿ ತಿಳಿದಿದ್ದರೂ ಆ ನೋಡ್‌ಗೆ ಸೆಷನ್, ಕೀಲಿಗಳು ಅಥವಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದುವರಿಸುವ ಸಾಮರ್ಥ್ಯ ಸಿಗುವುದಿಲ್ಲ.
ನೋಡ್ ವಿಫಲವಾದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ. ಬೆಂಬಲಿತ ಫಲಿತಾಂಶ ಹೊಸ ದೃಢೀಕರಣ ಮತ್ತು ಹೊಸ ವಿಳಾಸದೊಂದಿಗೆ ಇನ್ನೊಂದು ನೋಡ್‌ಗೆ ಮರುಸಂಪರ್ಕವಾಗಿರಬಹುದು, ನಂತರ ಅನ್ವಯವು ತನ್ನದೇ ರೀತಿಯಲ್ಲಿ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅಡೆತಡೆಯಿಲ್ಲದ ಹಸ್ತಾಂತರ ಬೇಕಾದರೆ, ಆ ಅಗತ್ಯಕ್ಕೆ ಸ್ಪಷ್ಟ ಅನುಷ್ಠಾನ ಬೆಂಬಲ ಬೇಕು, ಡೇಟಾಬೇಸ್ ನಕಲಿನಿಂದ ಊಹೆ ಅಲ್ಲ. ಉತ್ತರವನ್ನು ಆನ್-ಕಾಲ್ ಎಂಜಿನಿಯರ್ ಕಂಡುಕೊಳ್ಳಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಬರೆಯಿರಿ.
ಸಾಮರ್ಥ್ಯದ ನಿಯಮಗಳಿಗೂ ಅದೇ ಪರಿಗಣನೆ ಬೇಕು. ಖಾತೆಗೆ ಎರಡು ಏಕಕಾಲಿಕ ಸೆಷನ್‌ಗಳ ಮಿತಿಯನ್ನು ನೋಡ್‌ಗಳ ನಡುವೆ ಜಾರಿಗೊಳಿಸಲು ಯಾವುದೋ ಅಧಿಕಾರಕ್ಕೆ ಆಕ್ರಮಿತ ಸ್ಥಳಗಳ ಸಂಯೋಜಿತ ನೋಟ ಇದ್ದರೆ ಮಾತ್ರ ಸಾಧ್ಯ. ನೋಡ್-ಸ್ಥಳೀಯ ಪಟ್ಟಿಗಳು ಮತ್ತು ಐತಿಹಾಸಿಕ ಖಾತೆ ದಾಖಲೆ ಆ ನೋಟವಾಗಿ ಸೇರುವುದಿಲ್ಲ.
ಮೂರು ಲೆಡ್ಜರ್‌ಗಳ ಪರೀಕ್ಷೆ
ಪ್ರತಿಯೊಂದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ನೋಡ್ A ಮೂಲಕ ಸೈನ್ ಇನ್ ಮಾಡಿ, ನಂತರ ನೋಡ್ B ಮೂಲಕ, ಮತ್ತು ಎರಡೂ ನಿರೀಕ್ಷಿತ ವಿಳಾಸ ಶ್ರೇಣಿಗಳೊಂದಿಗೆ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಒಂದು ಗುರುತನ್ನು ಹಿಂಪಡೆದು ಎರಡೂ ನೋಡ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಪರೀಕ್ಷಿಸಿದ ಒಂದನ್ನಷ್ಟೇ ಅಲ್ಲ. ನಂತರ ಒಂದು ನೋಡ್ ನಿಲ್ಲಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಮತ್ತು ಖಾಸಗಿ ಅನ್ವಯ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತವೆ ಎಂದು ಗಮನಿಸಿ.
ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿ. B ಗೆ ಸಂಪರ್ಕಿಸಿ A ಯ ಹಿಂದಿನ ಸಂಪನ್ಮೂಲದಿಂದ ಉತ್ತರಗಳನ್ನು ಪಡೆಯಲಾಗದ ಕ್ಲೈಂಟ್ ಪ್ರವೇಶ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣನಾಗಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ವಿಫಲನಾಗಿದ್ದಾನೆ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸ ವರದಿಯಲ್ಲಿ ಕಾಣಬೇಕು.
ಮೂರೂ ಲೆಡ್ಜರ್‌ಗಳಿಗೆ ಸ್ಪಷ್ಟ ಮಾಲೀಕ, ಬದಲಾವಣೆಯ ಮಾರ್ಗ ಮತ್ತು ವೈಫಲ್ಯದ ವರ್ತನೆ ಇದ್ದಾಗ ಮಾತ್ರ ಬಹು-ನೋಡ್ ಖಾತೆ ವಿನ್ಯಾಸ ಪೂರ್ಣವಾಗುತ್ತದೆ. ನೋಡ್‌ಗಳ ನಡುವೆ ಸಂರಚನಾ ಕಡತವನ್ನು ನಕಲಿಸುವುದು ಆ ಪ್ರಶ್ನೆಗಳ ಒಂದಕ್ಕೂ ಉತ್ತರ ನೀಡುವುದಿಲ್ಲ.