OpenVPN ಕ್ಲೈಂಟ್‌ಗಳನ್ನು Cloudflare ಮೂಲಕ ರೂಟ್ ಮಾಡುವುದೇ? ಮೊದಲು ಪಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ
ಸಾಧನ ಕ್ಲೈಂಟ್ ರೂಟರ್ ಅಲ್ಲ. Cloudflare ಪಾತ್ರವು ಇತರ ಹೋಸ್ಟ್‌ಗಳ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಸರ್ವರ್‌ನ ಸ್ವಂತ ಸುರಂಗವನ್ನು ಅದರ ಹಳೆಯ ಮಾರ್ಗದಲ್ಲೇ ಇರಿಸಿ.
ನಿಮ್ಮ ಬಳಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ OpenVPN ಸರ್ವರ್ ಇದೆ ಮತ್ತು Cloudflare ನ ಸಾಧನ ತಂತ್ರಾಂಶವನ್ನೂ ಚಲಾಯಿಸುವ ಹೋಸ್ಟ್ ಇದೆ, ಮತ್ತು ಮುಂದಿನ ಸ್ಪಷ್ಟ ಹೆಜ್ಜೆ ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಅಲ್ಲಿಗೆ ನಿರ್ದೇಶಿಸುವಂತೆ ಕಾಣುತ್ತದೆ. ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಎರಡು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಂಪರ್ಕಗಳು ಸೇರಿ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಆಗುವುದಿಲ್ಲ. ಕೊರತೆಯಿರುವುದು ಬೇರೊಬ್ಬರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಲು ದಾಖಲಿತ ಪಾತ್ರ, ಮತ್ತು ಆ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬಂದಾಗ ಅವುಗಳನ್ನು ವರ್ಗೀಕರಿಸುವ ನೀತಿ.
ಯಾವುದೇ ನಿಯಮಕ್ಕೂ ಮೊದಲು ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳು: ಯಾವ ಸಂಚಾರ ಒಳಬರುತ್ತದೆ, ಅದು ಮುಂದೆ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ, ಉತ್ತರಗಳು ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಹೇಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಆ ಎರಡನೇ ಮಾರ್ಗ ವಿಫಲವಾದಾಗ ವಿನ್ಯಾಸ ಏನು ಮಾಡುತ್ತದೆ. ಮೊದಲ ಎರಡು ಸಾಮರ್ಥ್ಯದ ಪ್ರಶ್ನೆಗಳು.
ಒಂದು ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಎರಡು ಸೇವೆಗಳು ಟ್ರಾನ್ಸಿಟ್ ಮಾರ್ಗವಲ್ಲ
ಸಾಧನ ಕ್ಲೈಂಟ್ ತಾನು ಚಲಿಸುವ ಯಂತ್ರದಲ್ಲಿ ಹುಟ್ಟುವ ಸಂಚಾರವನ್ನು ನಿರ್ವಹಿಸಲು ನಿರ್ಮಿಸಲಾಗಿದೆ. ಅದು ಹೆಸರಿನ ವಿಭಜನೆ ಅಥವಾ ಆಯ್ದ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರವನ್ನು ಪ್ರತಿಬಂಧಿಸಿ ತನ್ನ ಸ್ವಂತ ಸುರಂಗದ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ನೀತಿ ಆ ಸಾಧನದ ಬಳಕೆದಾರ ಮತ್ತು ಆ ಸಾಧನದ ಪ್ರಕ್ರಿಯೆಗಳಿಗಾಗಿ ಬರೆಯಲಾಗಿದೆ. OpenVPN ಕ್ಲೈಂಟ್‌ನಿಂದ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ ಸ್ಥಳೀಯ ಔಟ್‌ಪುಟ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಅದೇ ನಿಯಮಗಳು ಅದನ್ನು ವರ್ಗೀಕರಿಸುವುದಿಲ್ಲ. ಇದು ವಿಸ್ತೃತ ನಿಯಮದಿಂದ ಮುಚ್ಚಬಹುದಾದ ಸಂರಚನಾ ವಿವರವಲ್ಲ, ಏಕೆಂದರೆ ತಂತ್ರಾಂಶವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವಲ್ಪವೂ ನೋಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಇದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಆದ್ದರಿಂದ ವಿನ್ಯಾಸದ ಪ್ರಶ್ನೆ ಸಾಮರ್ಥ್ಯದ ಪ್ರಶ್ನೆ. ಒಂದೋ ಸ್ಥಾಪಿತ ಉತ್ಪನ್ನದಲ್ಲಿ ಇತರ ಜಾಲಗಳಿಗೆ ಸಂಚಾರವನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ದಾಖಲಿತ ಪಾತ್ರವಿದೆ, ಅಥವಾ ಟ್ರಾನ್ಸಿಟ್ ಕಾರ್ಯವು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಡೆಗೆ ಸೇರಿದೆ.
Cloudflare ನ ಯಾವ ಪಾತ್ರಕ್ಕೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಲು ಅನುಮತಿ ಇದೆ
Cloudflare ನ ಸಾಧನ ಕ್ಲೈಂಟ್ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಭಿನ್ನವಾದ ಮೋಡ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ: ಹೆಸರಿನ ವಿಭಜನೆ ಮಾತ್ರ, ಸಾಧನದಿಂದ ಸಂಚಾರ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಎರಡೂ. ಆ ಮೋಡ್‌ಗಳಲ್ಲಿ ಯಾವುದೂ ಬೇರೆ ಸುರಂಗದ ಮೂಲಕ ಬರುವ ಖಾಸಗಿ ಶ್ರೇಣಿಗೆ ಹೋಸ್ಟ್ ಅನ್ನು ರೂಟರ್ ಆಗಿ ಮಾಡುವುದಿಲ್ಲ. ಮೀಸಲಾದ ರೂಟಿಂಗ್ ಪಾತ್ರವು ತನ್ನದೇ ಕನೆಕ್ಟರ್, ನೋಂದಣಿ ಮತ್ತು ಜಾಲ ಮಾದರಿಯನ್ನು ಹೊಂದಿರುವ ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನ.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
ಅದರ ಸುತ್ತ ಮಾರ್ಗಗಳನ್ನು ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಸ್ಥಾಪಿತ ಪಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ. ಕನೆಕ್ಟರ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ ರಚಿಸುತ್ತದೆ, ಅದು ನಿರ್ದಿಷ್ಟ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಅಥವಾ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಘೋಷಿಸುತ್ತದೆಯೇ, ಮತ್ತು ಸ್ಥಳೀಯ ನೀತಿ ಸ್ಥಳೀಯ ಪ್ಯಾಕೆಟ್‌ಗಳಂತೆಯೇ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೂ ಅನ್ವಯವಾಗುತ್ತದೆಯೇ ಎಂದು ಓದಿ. ಸ್ಥಳೀಯ ಸಂಚಾರ ಮಾತ್ರ ನಿರ್ವಹಿಸಲ್ಪಟ್ಟರೆ, ಅನುವಾದ ನಿಯಮ ಹೇಗೇ ಬರೆದರೂ OpenVPN ಸರ್ವರ್ ಟ್ರಾನ್ಸಿಟ್ ಬಿಂದುವಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಇಲ್ಲಿ ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನದ ಅವಶ್ಯಕತೆಯನ್ನು ನಿಖರವಾಗಿ ಹೇಳಬೇಕು. ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಕ್ಲೈಂಟ್ ಸಂಚಾರಕ್ಕಾಗಿ Cloudflare ಒದಗಿಸುವ ನಿರ್ಗಮನವು ನಿರ್ದಿಷ್ಟ ಬಳಕೆಯ ಸಂದರ್ಭವಾಗಿದ್ದು, ನಿಮ್ಮ ಬಳಿ ನಿಜವಾಗಿ ಇರುವ ಸೇವೆಯ ವಿರುದ್ಧ ಅದನ್ನು ಖಚಿತಪಡಿಸಬೇಕು.
ಹೊರಗಿನ ಸುರಂಗವನ್ನು ಹೊಸ ಮಾರ್ಗದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಇರಿಸಿ
ಹೊಸ ಇಂಟರ್ಫೇಸ್‌ನ ಕಡೆಗೆ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿದ ಕ್ಷಣದಲ್ಲೇ ಸರ್ವರ್‌ನ ಸ್ವಂತ ಹೊರಹೋಗುವ ಸಂಚಾರವು ಅದಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮತ್ತು ಅದರಲ್ಲಿ OpenVPN ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ನೀಡುವ ಉತ್ತರಗಳು ಮತ್ತು ಯಂತ್ರಕ್ಕೆ ನಿಮ್ಮ SSH ಅಧಿವೇಶನವೂ ಸೇರಿವೆ. ಸಾಮಾನ್ಯ ಲಕ್ಷಣವೆಂದರೆ ಸ್ಥಾಪನೆಯಾಗಿ ನಂತರ ಸಾಯುವ ಸುರಂಗ, ಅಥವಾ ಬದಲಾವಣೆ ಕೆಲಸ ಮಾಡಿದಂತೆ ಕಾಣುತ್ತಿರುವಾಗ ಹೊರಗೆ ಲಾಕ್ ಆಗುವ ನಿರ್ವಾಹಕ. ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಾಗಿ ip route get ಅನ್ನು ಮೊದಲು ಮತ್ತು ನಂತರ ಹೋಲಿಸಿ, ಮತ್ತು ಸರ್ವರ್‌ನ ಸ್ವಂತ ಸಾಗಣೆಯನ್ನು ಅದು ಇದ್ದಲ್ಲೇ ಇರಿಸಲು ನೀತಿ ಆಧಾರಿತ ರೂಟಿಂಗ್ ಅಥವಾ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಬಳಸಿ. ಆ ಹೋಲಿಕೆಯನ್ನು ಯಂತ್ರದಿಂದಲೇ ನಡೆಸಿ, ಏಕೆಂದರೆ ಸರ್ವರ್ ತನ್ನ ಮಾರ್ಗದ ಬಗ್ಗೆ ಹೊಂದಿರುವ ದೃಷ್ಟಿಯೇ ಮುಖ್ಯ.
ಸರ್ವರ್‌ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಇರುವ ವಿನಾಯಿತಿ ಸ್ವತಃ ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ರತಿ ದೂರದ ನಿರ್ವಾಹಕನ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇರೆ ಹರಿವು. ಆ ಹರಿವುಗಳಲ್ಲಿ ಯಾವುದು ಬದಲಾವಣೆಯನ್ನು ಉಳಿದುಕೊಳ್ಳಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ, ನಂತರ ಮೊದಲನೆಯದು ಉಳಿದವನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಪ್ರತಿಯೊಂದನ್ನು ಪರಿಶೀಲಿಸಿ.
ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಮತ್ತು ಅನುವಾದವನ್ನು ಒಂದು ಹರಿವಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ
ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸ್ಥಳೀಯ ಔಟ್‌ಪುಟ್ ಮಾರ್ಗವಲ್ಲ, ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಮುಖ್ಯವಾದ ನಿಯಮ forward ಕೊಕ್ಕಿನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ. ಮುಂದಿನ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅನುವಾದ ಬೇಕಾದಲ್ಲಿ, ಮೂಲವನ್ನು ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ, ಗಮ್ಯವನ್ನು ಅನುಮತಿಸಿದ್ದಕ್ಕೆ ಮತ್ತು ನಿರ್ಗಮನವನ್ನು ಆ ಒಂದೇ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಇಂಟರ್ಫೇಸ್‌ಗೆ ಮಾತ್ರ ಬದ್ಧವಾದ masquerade ನಿಯಮವು ತಾನೇ ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಬೇರೆ ಯಾವುದೇ ಫಿಲ್ಟರ್ ಮೀರಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ.
ವಿಫಲತೆಯಲ್ಲಿ ಮುಚ್ಚುವ ನಡವಳಿಕೆಯನ್ನು ಮೊದಲೇ ನಿರ್ಧರಿಸಿ, ನಂತರ ಅದನ್ನು ಪರೀಕ್ಷಿಸಿ. ಮುಂದಿನ ಮಾರ್ಗವನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಸಾಮಾನ್ಯ ಅಪ್‌ಲಿಂಕ್‌ಗೆ ಮೌನವಾಗಿ ಹಿಂತಿರುಗುವ ಬದಲು ಉದ್ದೇಶಿತ ನಿರ್ಗಮನವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಸಂಚಾರ ತಪ್ಪು ಬಾಗಿಲಿನಿಂದ ಹೊರಡುವವರೆಗೂ ಯಾರೂ ಗಮನಿಸದ ಫಲಿತಾಂಶ ಅದೇ. ಹೆಸರಿನ ವಿಭಜನೆ ಮತ್ತು IPv6 ಗಾಗಿ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ v4 ಗೆ ಮಾತ್ರ ಇರುವ ನಿಯಮಗಳ ಗುಂಪು v6 ಮಾರ್ಗವನ್ನು ತೆರೆದಿಡುತ್ತದೆ.
ನೀವು ನಿಂತ ನಾಲ್ಕು ಉತ್ತರಗಳನ್ನು ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನು ಸಾಬೀತುಪಡಿಸುವ ವೀಕ್ಷಣೆಯನ್ನು ಬರೆಯಿರಿ. ನೀವು ವಿವರಿಸಬಹುದಾದ ಟ್ರಾನ್ಸಿಟ್ ಮಾರ್ಗವೇ ಮುಂದಿನ ಘಟನೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಮಾರ್ಗ.