openfortivpn ಸಂಪರ್ಕಗೊಂಡಾಗ ರೂಟ್ ಮತ್ತು DNS ಅನ್ನು ಯಾರು ಹೊಂದಿರಬೇಕು?

ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ openfortivpn ಸೆಷನ್ನಲ್ಲಿ ನಾಲ್ಕು ಹಂತಗಳು ಒಂದರ ಮೇಲೊಂದು ಜೋಡಣೆಯಾಗುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇಯಲ್ಲಿ ದೃಢೀಕರಣ ಮಾಡಿ TLS ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ನಂತರ ಆ ಸಂಪರ್ಕದೊಳಗೆ PPP ಚಲಾಯಿಸುತ್ತದೆ, ನಂತರ ವಿಳಾಸ ಮತ್ತು DNS ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಅಂತಿಮವಾಗಿ ಹೋಸ್ಟ್ ರೂಟ್ಗಳು ಮತ್ತು ರಿಝಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಮುಂದಿನದು ಇಲ್ಲದಿದ್ದರೂ ಪ್ರತಿ ಹಂತವೂ ಜೀವಂತವಾಗಿರಬಹುದು, ಮತ್ತು ಅದಕ್ಕೇ “ಸಂಪರ್ಕಗೊಂಡಿದೆ” ಎಂಬುದು ಬೆಂಬಲ ಥ್ರೆಡ್ಗಳಲ್ಲಿ ಅಷ್ಟು ಜಾರುವ ಪದ.

ಹೆಚ್ಚಿನ ಗೊಂದಲವನ್ನು ನಿವಾರಿಸುವ ನಿರ್ಧಾರವೆಂದರೆ ಕೊನೆಯ ಹಂತವನ್ನು ಯಾರು ಹೊಂದಿದ್ದಾರೆ ಎಂಬುದು. ಒಂದೋ VPN ಕ್ಲೈಂಟ್ ಸ್ವತಃ ಹೋಸ್ಟ್ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಅಥವಾ ಇನ್ನೊಂದು ಘಟಕ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡನ್ನೂ ಅರ್ಧದಾರಿಯಲ್ಲಿ ಬೆರೆಸುವುದೇ ರೂಟ್ಗಳು ಮತ್ತು ರಿಝಾಲ್ವರ್ ಕಡತಗಳು ವಿಭಿನ್ನ ಸೆಷನ್ಗಳನ್ನು ವಿವರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಒಂದೇ ಸಂಪರ್ಕದಂತೆ ಕಾಣುವ ನಾಲ್ಕು ಹಂತಗಳು

ಮೊದಲ ಹಂತ ಪ್ರವೇಶ. ಹೆಸರಿಸಲಾದ ದೃಢೀಕರಣ ಡೊಮೇನ್ ಅಥವಾ ಒಂದು ಬಾರಿಯ ಕೋಡ್ ಮೂಲಕ, ಮತ್ತು ಮುಂದುವರಿಯಲು ಬೇಕಾದ ನಿಯತಾಂಕಗಳನ್ನು ಪಡೆಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಮುದ್ರಿಸಿದಾಗ, ಅದು TLS ಸಾರಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದರ್ಥ. ಅದು PPP ಮಾತುಕತೆ ನಡೆಸಿದೆ ಎಂದರ್ಥವಲ್ಲ, ಮತ್ತು ಆಂತರಿಕ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪಬಹುದು ಎಂದಂತೂ ಅಲ್ಲ.

ಎರಡನೇ ಹಂತ PPP ಲಿಂಕ್. ಕ್ಲೈಂಟ್ ಟನಲ್ ಸಾಧನದ ವಿರುದ್ಧ PPP ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಕಡೆಗಳು ಲಿಂಕ್ ಆಯ್ಕೆಗಳು ಮತ್ತು ವಿಳಾಸಗಳ ಬಗ್ಗೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತವೆ. ಅದರ ನಂತರವೇ ಸೆಷನ್ ಯಾವ ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ ವಿಳಾಸಗಳನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಹೋಸ್ಟ್ಗೆ ತಿಳಿಯುತ್ತದೆ, ಮತ್ತು ಆಗ ಮಾತ್ರ ಟನಲ್ನತ್ತ ತೋರುವ ರೂಟ್ಗೆ ಅರ್ಥವಿರುತ್ತದೆ.

ಮೂರನೇ ಹಂತ ಆ ಮಾಹಿತಿಯನ್ನು ಹೋಸ್ಟ್ಗೆ ಅನ್ವಯಿಸುವುದು, ಮತ್ತು ಇಲ್ಲಿಯೇ ಮಾಲೀಕತ್ವ ಮುಖ್ಯ. ಕ್ಲೈಂಟ್ ರೂಟ್ಗಳನ್ನು ಸೇರಿಸಿ ರಿಝಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ಮರುಬರೆಯಬಹುದು, ಅಥವಾ ಹಿಂದೆ ಸರಿಯುವಂತೆ ಹೇಳಿ ಎರಡನ್ನೂ ಆ ಯಂತ್ರದಲ್ಲಿ ಜಾಲವನ್ನು ನಿರ್ವಹಿಸುವ ಯಾವುದಕ್ಕಾದರೂ ಬಿಡಬಹುದು. ಯೋಜನೆಯ README ಇವುಗಳನ್ನು ಒಂದೇ ಸ್ವಯಂಚಾಲಿತ ವರ್ತನೆಯ ಬದಲು ಪ್ರತ್ಯೇಕ ಜವಾಬ್ದಾರಿಗಳೆಂದು ವಿವರಿಸುತ್ತದೆ.

ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಯಾರು ಸಂಪಾದಿಸುತ್ತಾರೆ

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

ಬೇರೆ ಯಾವುದೋ ನಿಜವಾಗಿ ರೂಟಿಂಗ್ ಹೊಂದಿದ್ದಾಗ ಮಾತ್ರ ಹಸ್ತಾಂತರವನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಜಾಲ ನಿರ್ವಾಹಕ ಸಂಯೋಜನೆ, ಕಂಟೇನರ್ ಜಾಲ ನಾಮಸ್ಥಳ, ಅಥವಾ ಇಡೀ ಸೈಟ್ನ ರೂಟಿಂಗ್ ಏಜೆಂಟ್ ಅದೇ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಸ್ಥಾಪಿಸಿ ಸ್ವಚ್ಛಗೊಳಿಸುವುದನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿರಬಹುದು. ಆಗ no-routes ಆಯ್ಕೆಯನ್ನು ರವಾನಿಸುವುದು ಇಬ್ಬರು ಬರಹಗಾರರು ಒಂದೇ ಕೋಷ್ಟಕಕ್ಕಾಗಿ ಹೋರಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದು ಸ್ವಚ್ಛ ವೈಫಲ್ಯದ ಬದಲು ಒಂದು ಉಪಜಾಲದ ಮಧ್ಯಂತರ ನಷ್ಟವಾಗಿ ಕಾಣುವ ಸ್ಪರ್ಧೆ.

ಅತಿವ್ಯಾಪ್ತಿ ಹಸ್ತಾಂತರದ ಎರಡನೇ ಕಾರಣ. ತಳ್ಳಲಾದ ರೂಟ್ಗಳಲ್ಲಿ ಸ್ಥಳೀಯ ಜಾಲ ಈಗಾಗಲೇ ಬಳಸುವ ಪೂರ್ವಪ್ರತ್ಯಯ ಇದ್ದರೆ, ಕ್ಲೈಂಟ್ ನಿಮಗಾಗಿ ಘರ್ಷಣೆಯನ್ನು ಪರಿಹರಿಸಲಾರದು. ಆ ಪೂರ್ವಪ್ರತ್ಯಯ ಟನಲ್ ಮೂಲಕ, ಭೌತಿಕ ಲಿಂಕ್ ಮೂಲಕ, ಅಥವಾ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ರೂಟ್ ಮೂಲಕ ತಲುಪಬಹುದೇ ಎಂದು ಯಾರಾದರೂ ನಿರ್ಧರಿಸಬೇಕು, ಮತ್ತು ಆ ನಿರ್ಧಾರ ಟೋಪಾಲಜಿ ಹೊಂದಿರುವವರದು.

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

DNS ಮತ್ತು ರಿಝಾಲ್ವರ್ ಕಡತವನ್ನು ಯಾರು ಹೊಂದಿದ್ದಾರೆ

DNS ಅದೇ ನಿರ್ಧಾರ, ಹೆಚ್ಚು ತೀಕ್ಷ್ಣ ಅಂಚುಗಳೊಂದಿಗೆ. ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇ ಅಥವಾ PPP ಸಹವರ್ತಿ ವರದಿ ಮಾಡುವ DNS ಸರ್ವರ್ಗಳನ್ನು ಸ್ವೀಕರಿಸಿ ಅವುಗಳನ್ನು ಹೋಸ್ಟ್ ರಿಝಾಲ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ ಬರೆಯಬಹುದು. ಸರಳ ಯಂತ್ರದಲ್ಲಿ ನೀವು ಬಯಸುವುದು ಅದನ್ನೇ, ಏಕೆಂದರೆ ಆಂತರಿಕ ಹೆಸರುಗಳು ಆಗ ಟನಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಾಗ ಮಾತ್ರ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ.

ಆಧುನಿಕ Linux ಹೋಸ್ಟ್ನಲ್ಲಿ ರಿಝಾಲ್ವರ್ ಅನ್ನು ಸ್ಥಳೀಯ ಸ್ಟಬ್ ನಿರ್ವಹಿಸಬಹುದು, ಮತ್ತು ಆ ಸ್ಟಬ್ನ ಬೆನ್ನ ಹಿಂದೆ ರಿಝಾಲ್ವರ್ ಕಡತವನ್ನು ಮರುಬರೆಯುವುದು ಸರಿಯಾಗಿ ಕಾಣುವ ಆದರೆ ಅಸಂಗತವಾಗಿ ವರ್ತಿಸುವ ಸಂರಚನೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ಈಗಾಗಲೇ ರಿಝಾಲ್ವರ್ ನಿರ್ವಾಹಕವನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ, ಅದಕ್ಕೆ DNS ಮಾಲೀಕತ್ವ ಬಿಡಿ ಮತ್ತು ಅದರ ಬೆಂಬಲಿತ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಟನಲ್ನ ಸರ್ವರ್ಗಳನ್ನು ಅದಕ್ಕೆ ಒದಗಿಸಿ. ಕ್ಲೈಂಟ್ನ no-dns ಆಯ್ಕೆ ಅಲ್ಲಿ ಸರಿಯಾದ ಆಯ್ಕೆ, ಪರ್ಯಾಯ ಉಪಾಯವಲ್ಲ.

ವಿಭಜಿತ DNS ಕಡತವನ್ನು ಯಾರು ಬರುತ್ತಾರೆ ಎಂಬುದಕ್ಕಿಂತ ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆ. ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ಟನಲ್ ಮೂಲಕ ಕಳುಹಿಸುವುದು ಸರಳ ಮತ್ತು ನಿಧಾನ; ಅದರ ಮೂಲಕ ಕೇವಲ ಆಂತರಿಕ ವಲಯಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರತಿ-ಡೊಮೇನ್ ಸಂರಚನೆ ಬೇಕು, ಅದನ್ನು ಹೆಚ್ಚಿನ ಸರಳ ಕ್ಲೈಂಟ್ಗಳು ಒದಗಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ನ ರಿಝಾಲ್ವರ್ ಬದಲಾವಣೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೊದಲು ಹೋಸ್ಟ್ಗೆ ಯಾವ ವರ್ತನೆ ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ. ಇಲ್ಲಿ ತಪ್ಪು ಆಯ್ಕೆ ಟನಲ್ ಸ್ವತಃ ಸರಿಯಾಗಿದ್ದರೂ ಹೆಸರು-ಪರಿಹಾರ ಅಡಚಣೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ಸವಲತ್ತು, ಸಿದ್ಧತೆ ಮತ್ತು ಹಸ್ತಾಂತರ

ಟನಲ್ ಸಾಧನವನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಹೋಸ್ಟ್ ರೂಟ್ಗಳು ಅಥವಾ ರಿಝಾಲ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಸಂಪಾದಿಸುವುದು ಉನ್ನತ ಜಾಲ ಅಧಿಕಾರ ಬೇಕಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯ ತಪ್ಪೆಂದರೆ ಆದ್ದರಿಂದ ಎಲ್ಲವೂ root ಆಗಿ ಚಲಿಸಬೇಕು ಎಂದು ತೀರ್ಮಾನಿಸುವುದು, ಬ್ರೌಸರ್ ಅಥವಾ ಟನಲ್ ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್ ಸೇರಿದಂತೆ. ಸವಲತ್ತಿನ ಭಾಗವನ್ನು ಚಿಕ್ಕದಾಗಿ ಇರಿಸಿ: ಕ್ಲೈಂಟ್ ಮತ್ತು ಅದರ ಸಂರಚನಾ ಕಡತ, ನಿರ್ವಾಹಕನ ಮಾಲೀಕತ್ವದಲ್ಲಿ, ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್ಗಳು ತಮ್ಮ ಸಾಮಾನ್ಯ ಖಾತೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ.

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

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