OpenVPN ಮೊದಲ ಸಾಲನ್ನು ತಿರಸ್ಕರಿಸುತ್ತಿದೆಯೇ? ಫೈಲ್ ಬಹುಶಃ UTF-16 ಆಗಿದೆ

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

ಪುರಾಣ: ಸಂಪಾದಕವು ನಿಮಗೆ ಫೈಲ್ ತೋರಿಸುತ್ತದೆ

ಪಠ್ಯ ಸಂಪಾದಕವು ಬೈಟ್ಗಳನ್ನು ಅಕ್ಷರಗಳಾಗಿ ಪರಿವರ್ತಿಸಲು ಅದು ಪತ್ತೆ ಮಾಡುವ ಅಥವಾ ಊಹಿಸುವ ಎನ್ಕೋಡಿಂಗ್ ಬಳಸುತ್ತದೆ. ಅದು UTF-16 ಎಂದು ಊಹಿಸಿದಾಗ, ಫೈಲ್ ಪರದೆಯ ಮೇಲೆ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಕೆಳಗಿನ ಬೈಟ್ಗಳು ಜೋಡಿಗಳಾಗಿದ್ದು ಪ್ರತಿ ಲ್ಯಾಟಿನ್ ಅಕ್ಷರದ ನಂತರ ಶೂನ್ಯ ಬೈಟ್ ಬರುತ್ತದೆ. OpenVPN ಆ ಬೈಟ್ಗಳನ್ನು ಅಕ್ಷರಗಳಾಗಿ ಓದುತ್ತದೆ, ಮತ್ತು ಅಸಂಗತಿಯು ಅದು ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಮೊದಲ ಸೂಚನೆಯಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ.

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

ವೈಫಲ್ಯದ ನಿರ್ದಿಷ್ಟ ಆಕಾರವನ್ನು ಗುರುತಿಸುವುದು ಯೋಗ್ಯ, ಏಕೆಂದರೆ ಅದು ಒಂದು ವಿಶಿಷ್ಟ ರೀತಿಯಲ್ಲಿ ರೋಗನಿರ್ಣಾಯಕವಾಗಿದೆ. ಫೈಲ್ನ ಆರಂಭದಲ್ಲೇ ಇರುವ ಟೋಕನ್, ಬೇರೆ ಯಂತ್ರಗಳಲ್ಲಿ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ, ಶಬ್ದಕೋಶದ ಪ್ರಶ್ನೆಯಲ್ಲ ಬದಲಿಗೆ ಬೈಟ್ ಕ್ರಮದ ಪ್ರಶ್ನೆ.

ಮೊದಲ ಬೈಟ್ಗಳು ನಿಜವಾಗಿ ಏನು ಹೇಳುತ್ತವೆ

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

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

ನೀವು ಹುಡುಕುತ್ತಿರುವ ಮಾದರಿ ಎಂದರೆ ಪ್ರತಿ ಎರಡನೇ ಬೈಟ್ ಶೂನ್ಯವಾಗಿರುವ ಪಠ್ಯದ ಮುಂಚಿನ ಒಂದು ಜೋಡಿ ಬೈಟ್ಗಳು. FF FE ಎಂಬುದು UTF-16 ಲಿಟಲ್-ಎಂಡಿಯನ್, FE FF ಎಂಬುದು ಬಿಗ್-ಎಂಡಿಯನ್, ಮತ್ತು EF BB BF ಎಂಬುದು ಬೈಟ್ ಕ್ರಮದ ಗುರುತಿನೊಂದಿಗೆ UTF-8 ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಗುರುತು ಇಲ್ಲದ ಸಾಮಾನ್ಯ UTF-8 ಫೈಲ್ ನೇರವಾಗಿ ಮೊದಲ ಅಕ್ಷರದ ಬೈಟ್ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಅಕ್ಷರಗಳ ನಡುವಿನ ಶೂನ್ಯ ಬೈಟ್ಗಳೇ ಮುಖ್ಯ ಸುಳಿವು. UTF-16 ಲಿಟಲ್-ಎಂಡಿಯನ್ನಲ್ಲಿ client ಪದವು ಆರರ ಬದಲು ಹನ್ನೆರಡು ಬೈಟ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ASCII ಅಕ್ಷರದ ನಂತರ ಶೂನ್ಯ ಬರುತ್ತದೆ. ಆ ರಚನೆಯನ್ನು ಸಂಪಾದಕದ ಪ್ರದರ್ಶನ ನಿಮಗೆ ತೋರಿಸಲಾರದು, ಮತ್ತು ಎರಡು ಬೈಟ್ ಅಳಿಸುವುದರಿಂದ ಅದು ಹೋಗುವುದಿಲ್ಲ.

ಇಲ್ಲಿ ಒಂದು ಮುಖ್ಯ ಸೂಕ್ಷ್ಮತೆ ಇದೆ: OpenVPN ನ ಸಂರಚನಾ ಓದುಗು ಫೈಲ್ನ ಆರಂಭದಲ್ಲಿನ UTF-8 ಬೈಟ್ ಕ್ರಮದ ಗುರುತನ್ನು ನಿಜವಾಗಿಯೂ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, 2.6 ಸಂರಚನಾ ಓದುಗು ತೋರಿಸುವಂತೆ. ಆ ಸಹನಶೀಲತೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಆ ಗುರುತಿಗೆ ಸಂಬಂಧಿಸಿದ್ದು, ಅಕ್ಷರಗಳು ಶೂನ್ಯಗಳಿಂದ ತುಂಬಿರುವ UTF-16 ಫೈಲ್ಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಎರಡು ಗುರುತುಗಳನ್ನು ಒಂದೇ ಸಮಸ್ಯೆ ಎಂದು ಪರಿಗಣಿಸುವುದು ಪುರಾಣದ ಎರಡನೇ ಅರ್ಧ.

ಸರಿಪಡಿಸಿದ ಎನ್ಕೋಡಿಂಗ್ ಏನನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ

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

ನಂತರ ನಿಜವಾದ ಎನ್ಕೋಡಿಂಗ್ ಪರಿವರ್ತನೆ ಮಾಡಿ, ಒಂದೋ ಸಂಪಾದಕದ ಸ್ಪಷ್ಟ ಎನ್ಕೋಡಿಂಗ್ ಮೆನು ಮೂಲಕ, ಅಥವಾ ತನ್ನ ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಎನ್ಕೋಡಿಂಗ್ ತಿಳಿಸುವ ಪರಿವರ್ತಕದಿಂದ:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

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

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

ಸರಿಪಡಿಸಿದ ಎನ್ಕೋಡಿಂಗ್ ಸರಿಪಡಿಸದಿರುವುದು

ಎನ್ಕೋಡಿಂಗ್ ಪಠ್ಯವನ್ನು ಹೇಗೆ ಓದಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ನಿಮ್ಮ ಮುಂದಿರುವ ಕ್ಲೈಂಟ್ಗೆ ಆಯ್ಕೆಗಳು ಮಾನ್ಯವೇ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಬೇರೆ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ರಫ್ತು ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ಸ್ವಚ್ಛವಾಗಿ ವಿಶ್ಲೇಷಣೆಯಾಗಬಹುದು ಮತ್ತು ಆದರೂ ಚಾಲನೆಯಲ್ಲಿರುವ ಬಿಲ್ಡ್ ಬೆಂಬಲಿಸದ ಆಯ್ಕೆಯಿಂದ ಅಥವಾ ಆ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅದರ ಆರ್ಗ್ಯುಮೆಂಟ್ ಬೇರೆ ಅರ್ಥ ನೀಡುವ ಸೂಚನೆಯಿಂದ ತಿರಸ್ಕೃತವಾಗಬಹುದು.

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

ಇದರಲ್ಲಿ ತೊಡಗಿರುವಾಗ ತನಿಖೆಯನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಇರಿಸಿ. ಸಾರ್ವಜನಿಕ ಆನ್ಲೈನ್ ಪರಿವರ್ತಕಗಳು ಮತ್ತು ಅಂಟಿಸಿದ hex ಡಂಪ್ಗಳು ಖಾಸಗಿ ಕೀ ಇರಬಹುದಾದ ಫೈಲ್ಗೆ ಕೆಟ್ಟ ಸ್ಥಳ, ಏಕೆಂದರೆ ಎನ್ಕೋಡಿಂಗ್ ಸಮಸ್ಯೆ ಸುಲಭವಾಗಿ ಸರಿಪಡಿಸಬಹುದು, ಸೋರಿದ ಕೀ ಅಲ್ಲ.