0x ಅಥವಾ 0s? ipsec.secrets ನಲ್ಲಿ PSK ಸ್ವರೂಪವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು

ಒಂದು ಕ್ಲೈಂಟ್ ಹಂಚಿಕೆಯ ಕೀಲಿಯೊಂದಿಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಅದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ, ಆದರೆ ನೀವು ಅಂಟಿಸಿದ ಅಕ್ಷರಗಳು ಎರಡೂ ಕಡೆ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಬಹುಶಃ ಅವು ಅದೇ ಅಕ್ಷರಗಳು; ವ್ಯತ್ಯಾಸವೆಂದರೆ ಫೈಲ್ ಅವುಗಳ ಮೇಲೆ ಯಾವ ಡಿಕೋಡಿಂಗ್ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದು. ಉದ್ಧರಣ ಚಿಹ್ನೆಗಳಲ್ಲಿನ ಸ್ಟ್ರಿಂಗ್ ಅಕ್ಷರಶಃ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ, 0x ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಟೋಕನ್ ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ಆಗಿ ಓದಲಾಗುತ್ತದೆ, ಮತ್ತು 0s ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಟೋಕನ್ Base64 ಆಗಿ ಓದಲಾಗುತ್ತದೆ. ಈ ಮೂರು ಬರವಣಿಗೆಗಳಲ್ಲಿ ಒಂದೇ ನೀವು ಉದ್ದೇಶಿಸಿದ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರಿಪಡಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತಮ ಪಾಸ್ವರ್ಡ್ ಅಲ್ಲ, ಒಂದು ಪರಿವರ್ತನೆ.

ಲಕ್ಷಣವು ಸೈಫರ್ಗಳಲ್ಲ, ಎನ್ಕೋಡಿಂಗ್ನತ್ತ ಸೂಚಿಸುತ್ತದೆ

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

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

ಒಂದು ರಹಸ್ಯ, ಫೈಲ್ ಅನ್ನು ಓದಬಹುದಾದ ಮೂರು ವಿಧಾನಗಳು

ನಾಲ್ಕು ಬೈಟ್ ಮೌಲ್ಯ key1 ಗಾಗಿ ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ಮತ್ತು Base64 ಒಂದೇ ಬೈಟ್ಗಳ ಎರಡು ಮರು-ಎನ್ಕೋಡಿಂಗ್ಗಳು, ಮತ್ತು ಆರಂಭಿಕ ಅಕ್ಷರಗಳು ಮಾತ್ರ ಪಾರ್ಸರ್ಗೆ ಯಾವುದನ್ನು ಹಿಡಿದಿದೆ ಎಂದು ಹೇಳುತ್ತವೆ. swanctl ರುಜುವಾತುಗಳು ಅದೇ ಸಂಪ್ರದಾಯವನ್ನು ಅನುಸರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಎರಡು ಇಂಟರ್ಫೇಸ್ಗಳ ನಡುವೆ ಸ್ಥಳಾಂತರಿಸಿದ ಮೌಲ್ಯವು ತನ್ನ ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಚಲಿಸಿದಾಗ ಮಾತ್ರ ಅರ್ಥವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

ಆ ಬ್ಲಾಕ್ನ ಎರಡು ವಿವರಗಳು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ. ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ಅಂಕಿಗಳು ಎರಡೂ ಕೇಸ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ 0x6b657931 ಮತ್ತು 0x6B657931 ಒಂದೇ ಮೌಲ್ಯ, ಆದರೆ ಬೆಸ ಸಂಖ್ಯೆಯ ಅಕ್ಷರಗಳನ್ನು ತಿರಸ್ಕರಿಸುವ ಬದಲು ಸದ್ದಿಲ್ಲದೆ ತಪ್ಪಾಗಿ ಓದಲಾಗುತ್ತದೆ, ಇದು ಕತ್ತರಿಸಿದ ನಂತರದ ಪ್ರತಿ ಬೈಟ್ ಅನ್ನು ಸರಿಸುತ್ತದೆ. Base64 ಪ್ಯಾಡಿಂಗ್ ಮೌಲ್ಯದ ಭಾಗವಾಗಿದೆ, ಆದ್ದರಿಂದ ಕೊನೆಯ = ಚಿಹ್ನೆಗಳಿಲ್ಲದೆ ಅಂಟಿಸಿದ ಸ್ಟ್ರಿಂಗ್ ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗುವ ಬದಲು ಬೇರೆ ಬೈಟ್ಗಳಿಗೆ ಡಿಕೋಡ್ ಆಗುತ್ತದೆ.

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

Base64 ಪಠ್ಯ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ

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

ಎರಡೂ ದಿಕ್ಕುಗಳು ತಲಾ ಒಂದು ಆಜ್ಞೆ, ಮತ್ತು ಸಂಗ್ರಹಿತ ಮೌಲ್ಯವನ್ನು ಸೃಷ್ಟಿಸಿದ ನಿಖರ ಕ್ರಿಯೆ ಎಂದು ಅವುಗಳನ್ನು ಟಿಕೆಟ್ನಲ್ಲಿ ಇಡುವುದು ಯೋಗ್ಯ. ಅವುಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಚಲಾಯಿಸಿ:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

ಪ್ರತಿ ಸಹಚರವು ವಾಸ್ತವವಾಗಿ ಯಾವ ಬೈಟ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

ದೋಷದ ಸ್ಟ್ರಿಂಗ್ನಿಂದ ಕಾರಣವನ್ನು ಊಹಿಸುವ ಬದಲು ಮೊದಲು ಡೀಮನ್ ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಹೊಂದಿರುವ ದೃಷ್ಟಿಯನ್ನು, ನಂತರ ದೃಢೀಕರಣದ ಫಲಿತಾಂಶವನ್ನು ಓದಿ. ಸಂಗ್ರಹಿತ ಉದ್ದವನ್ನು ಹೋಲಿಸುವುದು ತ್ವರಿತ ಸಮಂಜಸತೆ ಪರಿಶೀಲನೆ, ಏಕೆಂದರೆ ಎನ್ಕೋಡ್ ಆದ ಪಠ್ಯವು ಅದು ಪ್ರತಿನಿಧಿಸುವ ಬೈಟ್ಗಳಿಗಿಂತ ಉದ್ದವಾಗಿರುತ್ತದೆ. ನಂತರ ಯಾವ ಗುರುತಿನ ಸಾಲು ಹೊಂದಿಕೆಯಾಯಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪು ಸಹಚರದ ಅಡಿಯಲ್ಲಿ ಇಟ್ಟ ಸರಿಯಾದ ರಹಸ್ಯವು ತಪ್ಪಾದಂತೆಯೇ ವಿಫಲವಾಗುತ್ತದೆ. ಸಾಲುಗಳ ಕ್ರಮವೇ ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: ಮೊದಲ ಹೊಂದಾಣಿಕೆ ಗೆಲ್ಲುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೇಲ್ಭಾಗದ ಹತ್ತಿರವಿರುವ ಅಗಲವಾದ %any ಸಾಲು ನೀವು ಈಗಷ್ಟೇ ಸಂಪಾದಿಸಿದ ನಿರ್ದಿಷ್ಟ ಸಾಲನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬದಲಾಯಿಸುತ್ತದೆ.

ಫೈಲ್ ಸರಿಯಾದ ನಂತರ ಮರುಪ್ರಾರಂಭಿಸುವ ಬದಲು ಮರುಲೋಡ್ ಮಾಡಿ. ipsec rereadsecrets IKE ಡೀಮನ್ನ ಪ್ರತಿಯನ್ನು ಹೊಸದಾಗಿಸುತ್ತದೆ, ಮತ್ತು swanctl ಸಂರಚನೆ ತನ್ನದೇ ಆಜ್ಞೆಯ ಮೂಲಕ ರುಜುವಾತುಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಮರುಪ್ರಾರಂಭವು ಸ್ಥಾಪಿತವಾದ ಪ್ರತಿ ಸಂಬಂಧವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ ಮತ್ತು ನೀವು ಮಾಡಲು ಹೊರಟಿದ್ದ ಹೋಲಿಕೆಯನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ.

ಈ ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ಯಾವುದೂ ರಹಸ್ಯವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದನ್ನು ಕೇಳುವುದಿಲ್ಲ. ಉದ್ದ, ಗುರುತಿನ ಆಯ್ಕೆಗಾರ ಮತ್ತು ಸಾಲಿನ ಸ್ಥಾನ ಈ ರೀತಿಯ ಬಹುಪಾಲು ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಯಾರಿಗಾದರೂ ಹೆಕ್ಸ್ ಡಂಪ್ ಬೇಕಾಗುವ ಮೊದಲೇ.

ಫಲಿತಾಂಶವನ್ನು ಮುಚ್ಚಿಡದೆ ಫೈಲ್ ಬದಲಾಯಿಸಿ

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

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