OpenVPN client-connect ವಿಫಲತೆ: disconnect ನಲ್ಲಿ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಖಾತರಿಯೇ?
ತಿರಸ್ಕೃತ ಕ್ಲೈಂಟ್ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅಥವಾ ಬರೆದ ದಾಖಲೆಯನ್ನು ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ. ಕಾಲ್ಬ್ಯಾಕ್ ಒಪ್ಪಂದವನ್ನು ನಿಮ್ಮ hook ಸ್ವತಃ ಮಾಡಬೇಕಾದ ರೋಲ್ಬ್ಯಾಕ್ನೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಒಂದು client-connect ಸ್ಕ್ರಿಪ್ಟ್ ಶೂನ್ಯವಲ್ಲದ ಕೋಡ್ನೊಂದಿಗೆ ನಿರ್ಗಮಿಸಿದಾಗ, OpenVPN ಕ್ಲೈಂಟ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ, ಮತ್ತು ನಿರ್ವಾಹಕರು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಬಂಧಿತ client-disconnect ಸ್ಕ್ರಿಪ್ಟ್ ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಹಲವು ಬಾರಿ ಅದು ಎಂದಿಗೂ ಚಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ disconnect ಸಂಸ್ಕರಣೆಯು connect ಹಂತವು ಏನನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ತಿರಸ್ಕಾರ ಮತ್ತು ರೋಲ್ಬ್ಯಾಕ್ ಅನ್ನು ಒಂದೇ ಕಾರ್ಯವಿಧಾನವೆಂದು ಪರಿಗಣಿಸುವುದೇ ವಿಫಲ ಲಾಗಿನ್ ಅನ್ನು ಸೋರಿದ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅಥವಾ ಅನಾಥ ದಾಖಲೆಯಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಇವು ಎರಡು ಪ್ರತ್ಯೇಕ ಜವಾಬ್ದಾರಿಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಸ್ವಯಂಚಾಲಿತವಾಗಿದೆ. ಸರ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಬಿಟ್ಟಿದೆ ಎಂದು ದೂಷಿಸುವ ಮೊದಲು hook ನ ಸ್ವಂತ ನಿರ್ಗಮನ ಮಾರ್ಗವನ್ನು ಓದಿ.
ಶೂನ್ಯವಲ್ಲದ ನಿರ್ಗಮನವು ಕ್ಲೈಂಟ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ; ಅದು ನಿಮ್ಮ ಕೆಲಸವನ್ನು ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ
client-connect ನ ನಿರ್ಗಮನ ಸ್ಥಿತಿ ಪ್ರವೇಶದ ನಿರ್ಣಯವಾಗಿದೆ. ಶೂನ್ಯ ಎಂದರೆ ಪ್ರವೇಶ, ಬೇರೆ ಯಾವುದೇ ಮೌಲ್ಯ ಎಂದರೆ ಇನ್ಸ್ಟನ್ಸ್ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಾಪಿತವಾಗುವ ಮೊದಲು ಒಡೆಯುವುದು. ಆ ಒಪ್ಪಂದದಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಹೊರಗಿನ ಜಗತ್ತಿಗೆ ಈಗಾಗಲೇ ಏನು ಮಾಡಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುವ ಯಾವುದೂ ಇಲ್ಲ. ಸ್ಕ್ರಿಪ್ಟ್ iptables ನಿಯಮ ಸೇರಿಸಿದ್ದರೆ, ಸಾಲು ಬರೆದಿದ್ದರೆ ಅಥವಾ ಕೌಂಟರ್ ಹೆಚ್ಚಿಸಿದ್ದರೆ, ಆ ಬದಲಾವಣೆಗಳು ತಿರಸ್ಕಾರದ ನಂತರವೂ ಉಳಿಯುತ್ತವೆ.
ಅದೇ ಅಸಮಮಿತಿ ಪ್ಲಗಿನ್ಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಒಂದು ಇನ್ಸ್ಟನ್ಸ್ಗೆ ಹಲವು connect ಕಾರ್ಯಗಳು ಚಲಿಸಬಹುದು. ನಂತರದ ವೈಫಲ್ಯವು ಹಿಂದಿನ ಯಶಸ್ಸನ್ನು ಹಿಂದಿನಿಂದ ರದ್ದುಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಹಿಂದಿನ ಕಾರ್ಯಕ್ಕೆ ಸಹೋದರ ಕಾರ್ಯ ವಿಫಲವಾಯಿತು ಎಂದು ತಿಳಿಯಲು ದಾರಿಯಿಲ್ಲ.
ತಿರಸ್ಕಾರ ಸ್ವಯಂಚಾಲಿತ, ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಅಲ್ಲ
OpenVPN 2.6 ಕೈಪಿಡಿ client-disconnect ಸಂಸ್ಕರಣೆಯನ್ನು ಹಿಂದಿನ connect ಸಂಸ್ಕರಣೆಯ ಯಶಸ್ಸಿಗೆ ಜೋಡಿಸುತ್ತದೆ. ದಾಖಲಿತ ಅಪವಾದವು ಕ್ಯಾಸ್ಕೇಡ್ ಸರಪಳಿಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ: ಒಂದು connect ಹಂತ ಈಗಾಗಲೇ ಯಶಸ್ಸನ್ನು ಹಿಂತಿರುಗಿಸಿದ್ದರೆ, ನಂತರದ connect ಹಂತ ವಿಫಲವಾದರೂ, ಇನ್ಸ್ಟನ್ಸ್ ಒಡೆಯುವಾಗ ಸಂಬಂಧಿತ disconnect ಹಂತಗಳು ಹೇಗಿದ್ದರೂ ಚಲಿಸುತ್ತವೆ. ಆ ಅಪವಾದ ಸಂಕುಚಿತವಾಗಿದ್ದು ಎಷ್ಟು ಕಾಲ್ಬ್ಯಾಕ್ಗಳನ್ನು ಸಂರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ ಒಂದು shell ಸ್ಕ್ರಿಪ್ಟ್ ಪರೀಕ್ಷಿಸುವುದು ಸರಪಳಿಯ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ನಿಜವಾದ ಸಂರಚನೆಯನ್ನು ನಕ್ಷೆ ಮಾಡಿ: ಯಾವ ಸ್ಕ್ರಿಪ್ಟ್, ಯಾವ ಪ್ಲಗಿನ್ ಮತ್ತು ಯಾವ ಕ್ರಮದಲ್ಲಿ ಚಲಿಸುತ್ತವೆ. ಕೆಳಗಿನ ಕೋಷ್ಟಕವು ಅಪೂರ್ಣ ಸೆಟಪ್ ಹಿಂದೆ ಏನನ್ನು ಬಿಡುತ್ತದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
ಪ್ರತಿ ಸಾಲು ಕ್ಲೈಂಟ್ಗೆ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಮತ್ತು ಹೋಸ್ಟ್ಗೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದು ಸಂಭವಿಸಿತು ಎಂದು ಕ್ಲೈಂಟ್ ಹೇಳಲಾಗದು, ಆದ್ದರಿಂದ hook ವೈಫಲ್ಯ ಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುವ ಮೊದಲು ತಾನು ಮಾಡಿದ್ದನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು.
ವಿಫಲವಾದ ಸ್ಕ್ರಿಪ್ಟ್ ಒಳಗೇ ಪರಿಹಾರ ನೀಡಿ
ಹಂಚಿಕೆಯ ಸ್ಥಿತಿಯನ್ನು ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ಸಾಧ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸಿ: ಪ್ರಮಾಣಪತ್ರದ ಕ್ಷೇತ್ರಗಳು, ವಿಳಾಸದ ಲಭ್ಯತೆ, ಕ್ಲೈಂಟ್ ಸೇರಿರುವ ಗುಂಪು. ಅಗ್ಗದ ತಿರಸ್ಕಾರವೆಂದರೆ ಯಾವುದೇ ಹಂಚಿಕೆಗೆ ಮೊದಲು ಸಂಭವಿಸುವುದು. ಸೆಟಪ್ ಹಲವು ಬಾಹ್ಯ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒಳಗೊಂಡಾಗ, ಯಾವುವು ಪೂರ್ಣಗೊಂಡವು ಎಂಬ ದಾಖಲೆ ಇರಿಸಿ ಮತ್ತು ವೈಫಲ್ಯ ಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ವಿರುದ್ಧ ಕ್ರಮದಲ್ಲಿ ಹಿಂತಿರುಗಿಸಿ.
ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭ: ಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಫೈರ್ವಾಲ್ ನಮೂದನ್ನು ರಚಿಸುತ್ತದೆ, ನಂತರ ಅದನ್ನು ವಿವರಿಸುವ ಸ್ಥಿತಿ-ಸಾಲನ್ನು ಬರೆಯಲು ವಿಫಲವಾಗುತ್ತದೆ. ವಿಫಲವಾದ ಶಾಖೆಯು ಈಗಷ್ಟೇ ರಚಿಸಿದ ನಮೂದನ್ನು ತೆಗೆದುಹಾಕಿ ನಂತರ ಶೂನ್ಯವಲ್ಲದ ಕೋಡ್ನೊಂದಿಗೆ ನಿರ್ಗಮಿಸಬೇಕು. ಎಂದಿಗೂ ನಿಗದಿಯಾಗದಿರಬಹುದಾದ disconnect ಘಟನೆಗಾಗಿ ಕಾಯುವುದೇ ನಿಯಮವು ತಾನು ಉದ್ದೇಶಿಸಿದ ಅವಧಿಗಿಂತ ಹೆಚ್ಚು ಬದುಕುವ ರೀತಿ.
ಪರಿಹಾರವನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ ಮತ್ತು ಮಾಲೀಕತ್ವದ್ದಾಗಿಸಿ
ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಎರಡು ಬಾರಿ ಚಲಿಸಲು ಸುರಕ್ಷಿತವಾಗಿರಬೇಕು ಮತ್ತು ಏನನ್ನು ಅಳಿಸಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ನಿಖರವಾಗಿರಬೇಕು. ಹಿಂದಿನ ಪ್ರಯತ್ನದ ತಡವಾದ ಘಟನೆಯು ಹೊಸ ಅವಧಿಯ ಹಂಚಿಕೆಯನ್ನು ಕೇವಲ ಎರಡೂ ಸಾಮಾನ್ಯ ಹೆಸರು ಅಥವಾ ಮರುಬಳಕೆಯ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಹಂಚಿಕೊಂಡಿರುವುದರಿಂದ ತೆಗೆದುಹಾಕಬಾರದು. ನಿರ್ದಿಷ್ಟ ಹ್ಯಾಂಡಲ್ ಅಥವಾ ಕಾರ್ಯಾಚರಣೆ ಐಡಿಯನ್ನು ಸಂಪನ್ಮೂಲದೊಂದಿಗೆ ದಾಖಲಿಸಿ, ಮತ್ತು ಹೆಸರಿನಿಂದ ಅಲ್ಲ, ಆ ಕೀಯಿಂದ ಅಳಿಸಿ. ಡೇಟಾಬೇಸ್ ವಹಿವಾಟುಗಳು ಡೇಟಾಬೇಸ್ನ ಸ್ವಂತ ಬದಲಾವಣೆಗಳಿಗೆ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತವೆ; ಆ ಗಡಿಯ ಹೊರಗಿನ ಫೈರ್ವಾಲ್ ನಿಯಮಕ್ಕೆ ಸ್ಪಷ್ಟ ಪರಿಹಾರ ಹಂತ ಬೇಕು.
ಪ್ರಕ್ರಿಯೆಯು ಬದಲಾವಣೆ ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯ ನಡುವೆ ಸಾಯಬಹುದು ಎಂದು ಊಹಿಸಿ, ಮತ್ತು ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಬಾಹ್ಯ ಸ್ಥಿತಿಯನ್ನು ಸ್ವೀಕೃತ ಕ್ಲೈಂಟ್ ಪಟ್ಟಿಯೊಂದಿಗೆ ಹೋಲಿಸುವ ಸಮನ್ವಯಕವನ್ನು ಸೇರಿಸಿ.
ನಿಜವಾಗಿ ಭಿನ್ನವಾಗಿರುವ ಮೂರು ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಮೂರು ಸಂದರ್ಭಗಳನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ: ಏನನ್ನೂ ಹಂಚಿಕೆ ಮಾಡುವ ಮೊದಲು ತಿರಸ್ಕಾರ, ಭಾಗಶಃ ಹಂಚಿಕೆಯ ನಂತರದ ತಿರಸ್ಕಾರ, ಮತ್ತು ನಂತರ ಕೊನೆಗೊಳ್ಳುವ ಸಾಮಾನ್ಯ ಸ್ವೀಕೃತ ಅವಧಿ. ಆ ಮೂರು ವಿಭಿನ್ನ ಲಾಗ್ ಸಾಲುಗಳನ್ನು ಮತ್ತು ವಿಭಿನ್ನ ಶೇಷಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಂದರ ನಂತರ ಬಾಹ್ಯ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಕ್ಲೈಂಟ್ನ ವೈಫಲ್ಯ ಸಂದೇಶವನ್ನು ಮಾತ್ರವಲ್ಲ, ಏಕೆಂದರೆ ಮೂರರಲ್ಲಿ ಎರಡರಲ್ಲಿ ಕ್ಲೈಂಟ್ನ ವೈಫಲ್ಯವೇ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶ.
hook ನ ಹಂತ, ನಿರ್ಗಮನ ಸ್ಥಿತಿ ಮತ್ತು ಏನು ಹಂಚಲ್ಪಟ್ಟಿತು ಅಥವಾ ಬಿಡುಗಡೆಯಾಯಿತು ಎಂಬುದನ್ನು ರುಜುವಾತುಗಳನ್ನು ಬಿಟ್ಟು ಲಾಗ್ ಮಾಡಿ. ತಾನು ರಚಿಸಿದ ಸಂಪನ್ಮೂಲವನ್ನು ಹೆಸರಿಸುವ hook ಲಾಗ್ ಎಂಬುದೇ ಸೋರಿದ ನಿಯಮವನ್ನು ಆರು ತಿಂಗಳ ನಂತರ ಹುಡುಕಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.