OpenVPN ಕ್ಲೈಂಟ್ ಬ್ಲಾಕ್ ನಿಯಮ FORWARD ತಲುಪದಿರಲು ಕಾರಣ

ಒಂದೇ OpenVPN ಸರ್ವರ್ನಲ್ಲಿರುವ ಎರಡು ಕ್ಲೈಂಟ್ಗಳು ತಮ್ಮ ಪೂಲ್ಗಾಗಿ DROP ನಿಯಮ ಸೇರಿಸಿದ ನಂತರವೂ ಪರಸ್ಪರ ತಲುಪಬಹುದು. ನಿಯಮ FORWARD ಸರಪಳಿಯಲ್ಲಿದೆ, ಸಂಚಾರ ಸ್ಪಷ್ಟವಾಗಿ ಹರಿಯುತ್ತಿದೆ, ಆದರೆ ಆ ನಿಯಮದ ಕೌಂಟರ್ ಶೂನ್ಯದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. ಸಹಜ ತೀರ್ಮಾನ ಏನೆಂದರೆ ಫೈರ್ವಾಲ್ ಮುರಿದಿದೆ. ಹೆಚ್ಚಿನ ಸಲ ಪ್ಯಾಕೆಟ್ ಸರಪಳಿಗೆ ಪ್ರವೇಶಿಸಿಯೇ ಇಲ್ಲ.

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

ಪೀರ್ ಪ್ಯಾಕೆಟ್ ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಎರಡು ಮಾರ್ಗಗಳು

ಆಂತರಿಕ ಫಾರ್ವರ್ಡಿಂಗ್ ಆಯ್ಕೆ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ, ಕ್ಲೈಂಟ್ A ಯಿಂದ ಪ್ಯಾಕೆಟ್ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಅದರ ಗಮ್ಯಸ್ಥಾನ ಕ್ಲೈಂಟ್ B ಗೆ ನಿಗದಿಪಡಿಸಿದ ವಿಳಾಸದ ಒಳಗಿರುತ್ತದೆ. ಸರ್ವರ್ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಅದನ್ನು ಅದೇ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕವೇ ಹಿಂತಿರುಗಿ ಕಳುಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ B ಯ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗ ಸರ್ವರ್ನದಾಗಿದೆ. ಇದು ಹೋಸ್ಟ್ ಮೂಲಕ ಒಳಗೆ-ಹೊರಗೆ ಹೋಗುವ ಹರಿವು, ಮತ್ತು IPv4 ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವೇ ಅದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ.

ಆಂತರಿಕ ಫಾರ್ವರ್ಡಿಂಗ್ ಆಯ್ಕೆ ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ, ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ಗೆ ಹೊಂದಿಸಿ ನೇರವಾಗಿ ಆ ಕ್ಲೈಂಟ್ಗೆ ಮರಳಿ ಬರೆಯುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಡೀಮನ್ ಒಳಗೆ ನಿರ್ವಹಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಟನಲ್ ಸಾಧನಕ್ಕೆ ಮತ್ತೆ ಎಂದಿಗೂ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಲ್ಪಡುತ್ತದೆ. OpenVPN 2.6 ಕೈಪಿಡಿ ಈ ಆಯ್ಕೆಯನ್ನು ಆಂತರಿಕ ಕ್ಲೈಂಟ್ನಿಂದ-ಕ್ಲೈಂಟ್ಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅದನ್ನು ನೋಡಲಾಗದಿರಲು ಇದೇ ಕಾರಣ.

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

ಕೌಂಟರ್ ಎಂದಿಗೂ ಚಲಿಸದಿದ್ದಾಗ

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

ಮೂರನೆಯದು ಸ್ಥಾನ. ಸರಪಳಿಯಲ್ಲಿ ಮೊದಲಿನ ನಿಯಮ ನಿಮ್ಮ DROP ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುವ ಮೊದಲೇ ಹರಿವನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಮತ್ತು ನಂತರದ ನಿಯಮ ಫಲಿತಾಂಶವನ್ನು ನಿಜವಾಗಿ ನಿರ್ಧರಿಸುವಂಥದ್ದಾಗಿರಬಹುದು. ಕೌಂಟರ್ಗಳು ಕಾಣುವಂತೆ ಸರಪಳಿಯನ್ನು ಕ್ರಮವಾಗಿ ಓದಿ, ನಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿದಾಗ ಯಾವ ನಿಯಮದ ಎಣಿಕೆ ಹೆಚ್ಚಾಗುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.

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

ಫಿಲ್ಟರ್ ಮಾಡಬಲ್ಲ ಗಡಿಯನ್ನು ಆರಿಸುವುದು

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

ನಂತರ ಹರಿವನ್ನು ನಿಖರವಾಗಿ ಹೊಂದಿಸಿ. ಸಂಚಾರ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಟನಲ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೇವಲ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಪರಿಗಣಿಸುವ ನಿಯಮಗಳು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ವಿಳಾಸ ಆಧಾರಿತ ನಿಯಮಗಳಿಗೆ ಪ್ರಸ್ತುತ ಪೂಲ್ ಬೇಕು, ಮತ್ತು ಅವು ಮರಳುವ ದಿಕ್ಕನ್ನೂ ಮುಂದಿನ ದಿಕ್ಕಿನಂತೆಯೇ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

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

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

ನಿಯಮವನ್ನು ನಂಬುವ ಬದಲು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು

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

ಸರ್ವರ್ ಸಂರಚನೆಯನ್ನು ಮರುಲೋಡ್ ಮಾಡಿದ ನಂತರ ಮತ್ತು ಕ್ಲೈಂಟ್ ಮರುಸಂಪರ್ಕಗೊಂಡ ನಂತರ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಆಂತರಿಕ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಪೂಲ್ ಹಂಚಿಕೆಗಳು ರನ್ಟೈಮ್ ಸ್ಥಿತಿ. ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಕೌಂಟರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ದಿಕ್ಕಿಗೆ ಹೊಂದಿಕೆಯಾಗಿ ಉತ್ತರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮವು ಶೀಘ್ರ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಗಮನಿಸಲು ಕಷ್ಟವಾದ ಭಾಗಶಃ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಪ್ರತ್ಯೇಕತೆ ಎಂದರೆ ಹರಿವನ್ನು ನಿಜವಾಗಿ ಹೊತ್ತೊಯ್ಯುವ ಗಡಿಯಲ್ಲಿ ಗಮನಿಸಿದ ಫಲಿತಾಂಶ. ಹೋಸ್ಟ್ನ ಎಲ್ಲೋ ಇರುವ DROP ನಿಯಮ ಸಾಕ್ಷ್ಯವಲ್ಲ; ವಿಫಲವಾದ ಸಂಪರ್ಕ ಮತ್ತು ಅದನ್ನು ಉಂಟುಮಾಡಿದ ನಿಯಮದ ಚಲಿಸಿದ ಕೌಂಟರ್ ಸಾಕ್ಷ್ಯ.