DD-WRT ನಲ್ಲಿ OpenVPN 2.5 ಕೇಳುಗ ಸತ್ತಿದೆಯೇ? ಅದು ರಚಿಸಿದ ಕಾನ್ಫಿಗ್ ಓದಿ

DD-WRT ನಲ್ಲಿ ಸತ್ತ ಕೇಳುಗ ಎಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಡೀಮನ್ ತನ್ನ ಕಾನ್ಫಿಗ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡುವಾಗಲೇ ನಿರ್ಗಮಿಸಿತು ಎಂದು, ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಪೋರ್ಟ್ ಅನ್ನು ತಡೆದದ್ದಲ್ಲ. OpenVPN 2.5 ಹಳೆಯ ಕಾನ್ಫಿಗ್‌ಗಳು ಅವಲಂಬಿಸಿದ್ದ ಹಲವು ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿಸಿತು, ಮತ್ತು ಹಳೆಯ ಬಿಲ್ಡ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ರಚಿಸಿದ ಕಾನ್ಫಿಗ್ ಸಾಕೆಟ್ ತೆರೆಯುವ ಮೊದಲೇ ನಿರಾಕರಿಸಬಹುದು. ಕಾರಣ ರೌಟರ್‌ನ ಸ್ವಂತ ಲಾಗ್‌ನಲ್ಲಿದೆ, ಇನ್‌ಪುಟ್ ರಚಿಸಿದ ಫೈಲ್‌ನಲ್ಲಿದೆ. ಎರಡನ್ನೂ ಈ ಕ್ರಮದಲ್ಲಿ ಓದುವುದು ಯಾವುದೇ ಪ್ಯಾಕೆಟ್ ಕ್ಯಾಪ್ಚರ್‌ಗಿಂತ ವೇಗವಾಗಿದೆ.

ಡೀಮನ್ ಫೈರ್‌ವಾಲ್ ಅಲ್ಲ

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

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡು ಪರಿಶೀಲನೆಗಳಿಂದ ಇವನ್ನು ಬೇರ್ಪಡಿಸಿ, ಏಕೆಂದರೆ ಸತ್ತ ಡೀಮನ್ ಮೇಲೆ ಫೈರ್‌ವಾಲ್ ಸಂಪಾದನೆ ಎರಡನೇ ಚರಾಕ್ಷರವನ್ನು ಸೇರಿಸುತ್ತದೆ ಅಷ್ಟೇ.

DD-WRT ರಚಿಸಿದ ಕಾನ್ಫಿಗ್ ಓದಿ

DD-WRT ನೀವು ವೆಬ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಪಠ್ಯವನ್ನು OpenVPN ಗೆ ಕೊಡುವುದಿಲ್ಲ. ಅದು ರಚಿಸಿದ ಕಾನ್ಫಿಗ್ ಅನ್ನು /tmp/openvpn/openvpn.conf ಗೆ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಆ ಫೈಲ್‌ನೊಂದಿಗೆ ಡೀಮನ್ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಇಂಟರ್ಫೇಸ್ ಕ್ಷೇತ್ರಗಳು ಮತ್ತು Additional Config ನ ಯಾವುದೇ ಪಠ್ಯ OpenVPN ಅವನ್ನು ನೋಡುವ ಮೊದಲೇ ವಿಲೀನವಾಗುತ್ತವೆ. ನೀವು ರಚಿಸಿದ ಫೈಲ್ ಬದಲು ಫಾರ್ಮ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡಿದರೆ, ನೀವು ಉದ್ದೇಶವನ್ನು ಓದುತ್ತಿದ್ದೀರಿ, ನಿಜವಾದ ಇನ್‌ಪುಟ್ ಅಲ್ಲ. ಮರುಬೂಟ್ /tmp ಅನ್ನು ಅಳಿಸುವ ಮೊದಲು ಆ ಫೈಲ್ ಅನ್ನು ಶಾಶ್ವತ ಸ್ಥಳಕ್ಕೆ ನಕಲಿಸಿ.

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

ರಚಿಸಿದ ಫೈಲ್ ಖಾಲಿಯಾಗಿದ್ದರೆ ಅಥವಾ ಇಲ್ಲದಿದ್ದರೆ, ಡೀಮನ್ ಪ್ರಾರಂಭವಾಗುವವರೆಗೂ ತಲುಪಿಲ್ಲ, ಮತ್ತು ಸಮಸ್ಯೆ OpenVPN ಗಿಂತ ಮೇಲಿದೆ.

OpenVPN 2.5 ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದು

OpenVPN 2.5 ncp-ciphers ಅನ್ನು data-ciphers ನಿಂದ ಬದಲಿಸಿತು, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಕನಿಷ್ಠ TLS ಆವೃತ್ತಿಯನ್ನು 1.2 ಗೆ ಏರಿಸಿತು. ಇದು ಸಂಕೋಚನದ ನಿರ್ವಹಣೆಯನ್ನೂ ಬದಲಿಸಿತು, ಹಾಗಾಗಿ ಸಂಕೋಚನ ನೀಡುವ ಸಹವರ್ತಿ ಕಾನ್ಫಿಗ್ ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಸದಿದ್ದರೆ ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ns-cert-type ನಂತಹ ಹಳೆಯ ಆಯ್ಕೆ ಹೆಸರುಗಳನ್ನು remote-cert-tls ಪರವಾಗಿ ಬಳಕೆಯಲ್ಲಿಲ್ಲ ಎಂದು ಘೋಷಿಸಿತು. ಈ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯೂ ಹಿಂದೆ ಕೆಲಸ ಮಾಡಿದ ಕಾನ್ಫಿಗ್ ಅನ್ನು ಪಾರ್ಸ್ ಅಥವಾ ಮಾತುಕತೆಯ ವೈಫಲ್ಯವಾಗಿಸುತ್ತದೆ.

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

ಲಾಗ್‌ನಲ್ಲಿ ಮೊದಲ ದೋಷವನ್ನು ಓದಿ, ಕೊನೆಯದನ್ನಲ್ಲ. ಪಾರ್ಸಿಂಗ್ ಮೊದಲ ಕೆಟ್ಟ ನಿರ್ದೇಶದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ, ಅದರ ನಂತರದ್ದೆಲ್ಲಾ ನಿಲ್ಲಿಸುವಿಕೆಯ ಗದ್ದಲ.

Broadcom-ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಾಪೇಕ್ಷೆಗಳು

Broadcom ಬಿಲ್ಡ್‌ಗಳಲ್ಲಿ ಡೀಮನ್ ಬಳಸುವ ಮೊದಲು ಸುರಂಗ ಸಾಧನ ಇರಬೇಕು. tun ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಆಗಿದೆಯೇ ಮತ್ತು /dev/net/tun ಇದೆಯೇ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸಾಧನ ಇಲ್ಲದಿದ್ದರೆ ಪ್ರಮಾಣಪತ್ರಗಳಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರಾರಂಭ ವೈಫಲ್ಯ ಉಂಟಾಗುತ್ತದೆ. DD-WRT ಮಾರ್ಗಗಳು ಮತ್ತು DNS ಗಾಗಿ ರಚಿಸುವ ಸಹಾಯಕ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಗೂ ಇದೇ ಅನ್ವಯಿಸುತ್ತದೆ: ಅವು ಇಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗದಿದ್ದರೆ, ಡೀಮನ್ ಪ್ರಾರಂಭವಾಗಿ ಕೂಡ ತನ್ನ ಸೆಟಪ್ ಪೂರ್ಣಗೊಳಿಸದೇ ಇರಬಹುದು.

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

ನಂತರ ಸಾಮಾನ್ಯ ಸೇವೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಿ, ಏಕೆಂದರೆ ಮುಂಭಾಗದ ಡೀಮನ್ ಮತ್ತು init ಸ್ಕ್ರಿಪ್ಟ್ ಪೋರ್ಟ್‌ಗಾಗಿ ಹೋರಾಡುತ್ತವೆ.

ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಕೇಳುಗ ಇದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

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

ಕ್ಲೈಂಟ್ ಬದಿಯ ಡೀಬಗಿಂಗ್ ಕೇಳುಗ ಇದ್ದ ನಂತರವೇ ಅರ್ಥಪೂರ್ಣ. ಆಗ ಕ್ಲೈಂಟ್‌ನ ಸೈಫರ್ ಮತ್ತು TLS ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಸರ್ವರ್‌ನ data-ciphers ಪಟ್ಟಿ ಮತ್ತು ಕನಿಷ್ಠ ಆವೃತ್ತಿಗೆ ಹೊಂದುತ್ತವೆಯೇ, ಮತ್ತು ಪೋರ್ಟ್ ನಿಜವಾಗಿ ರೌಟರ್‌ಗೆ ಮುಂದೂಡಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ರಚಿಸಿದ ಕಾನ್ಫಿಗ್ ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿದ ಲಾಗ್ ಸಾಲನ್ನು ಇರಿಸಿ. ಮುಂದಿನ ಫರ್ಮ್‌ವೇರ್ ನವೀಕರಣ ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಮತ್ತೆ ಬದಲಿಸಬಹುದು, ಮತ್ತು ಆ ದಾಖಲೆಯೇ ಪುನರಾವರ್ತನೆಯನ್ನು ಐದು ನಿಮಿಷದ ಪರಿಶೀಲನೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.