🥇 ZeroTech ನಲ್ಲಿ ನಾವು Apple Safari ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ

ಲೇಖನವು ಯಾರಿಗೆ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ:

ಕ್ಲೈಂಟ್ ಸರ್ಟ್ ಏನೆಂದು ತಿಳಿದಿದೆ ಮತ್ತು ಮೊಬೈಲ್ ಸಫಾರಿಯಲ್ಲಿ ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳು ಏಕೆ ಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ;
ನಾನು ವೆಬ್ ಸೇವೆಗಳನ್ನು ಜನರ ಸೀಮಿತ ವಲಯಕ್ಕೆ ಅಥವಾ ನನಗೆ ಮಾತ್ರ ಪ್ರಕಟಿಸಲು ಬಯಸುತ್ತೇನೆ;
ಎಲ್ಲವನ್ನೂ ಈಗಾಗಲೇ ಯಾರೋ ಮಾಡಿದ್ದಾರೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ ಮತ್ತು ಜಗತ್ತನ್ನು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಅನುಕೂಲಕರ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿಸಲು ಬಯಸುತ್ತಾರೆ.

ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳ ಇತಿಹಾಸವು ಸುಮಾರು 8 ವರ್ಷಗಳ ಹಿಂದೆ ಪ್ರಾರಂಭವಾಯಿತು. ಹಿಂದೆ, ವಿಧಾನಗಳನ್ನು ದೀರ್ಘ http ವಿನಂತಿಗಳ ರೂಪದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತಿತ್ತು (ವಾಸ್ತವವಾಗಿ ಪ್ರತಿಕ್ರಿಯೆಗಳು): ಬಳಕೆದಾರರ ಬ್ರೌಸರ್ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯ ನಂತರ ಅದು ಮತ್ತೆ ಸಂಪರ್ಕಪಡಿಸಿ ಮತ್ತು ಕಾಯುವವರೆಗೆ ಏನಾದರೂ ಉತ್ತರಿಸಲು ಕಾಯುತ್ತಿದೆ. ಆದರೆ ನಂತರ ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡವು.

ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ, ಇದು ಲಿಂಕ್ ಲೇಯರ್ ಆಗಿರುವುದರಿಂದ https ವಿನಂತಿಗಳನ್ನು ಬಳಸಲಾಗದ ಶುದ್ಧ PHP ಯಲ್ಲಿ ನಾವು ನಮ್ಮದೇ ಆದ ಅನುಷ್ಠಾನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ಬಹಳ ಹಿಂದೆಯೇ, ಬಹುತೇಕ ಎಲ್ಲಾ ವೆಬ್ ಸರ್ವರ್‌ಗಳು https ಮೂಲಕ ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಗಳನ್ನು ಕಲಿಯಲು ಮತ್ತು ಸಂಪರ್ಕವನ್ನು ಬೆಂಬಲಿಸಲು: ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಲು ಕಲಿತವು.

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

ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಇದ್ದರೂ, ಇದು ಇನ್ನೂ ಕಳಪೆಯಾಗಿ ಬೆಂಬಲಿತವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಇದು ಬಹಳಷ್ಟು ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಮತ್ತು (ಬಹುಶಃ :slightly_smiling_face: ) ಅದಕ್ಕಾಗಿಯೇ IOS ಬ್ರೌಸರ್‌ಗಳು (ಎಲ್ಲಾ ಸಫಾರಿ ಹೊರತುಪಡಿಸಿ) ಅದನ್ನು ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ ಮತ್ತು ಸ್ಥಳೀಯ ಪ್ರಮಾಣಪತ್ರ ಅಂಗಡಿಯಿಂದ ಅದನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಲಾಗಿನ್/ಪಾಸ್ ಅಥವಾ ssh ಕೀಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಪ್ರಮಾಣಪತ್ರಗಳು ಅನೇಕ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿವೆ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ಮೂಲಕ ಅಗತ್ಯ ಪೋರ್ಟ್‌ಗಳನ್ನು ಮುಚ್ಚುತ್ತವೆ. ಆದರೆ ಇದು ಅದರ ಬಗ್ಗೆ ಅಲ್ಲ.

ಐಒಎಸ್ನಲ್ಲಿ, ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ಥಾಪಿಸುವ ವಿಧಾನವು ತುಂಬಾ ಸರಳವಾಗಿದೆ (ನಿರ್ದಿಷ್ಟತೆಗಳಿಲ್ಲದೆ), ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದನ್ನು ಸೂಚನೆಗಳ ಪ್ರಕಾರ ಮಾಡಲಾಗುತ್ತದೆ, ಅದರಲ್ಲಿ ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ ಮತ್ತು ಸಫಾರಿ ಬ್ರೌಸರ್ಗೆ ಮಾತ್ರ ಲಭ್ಯವಿದೆ. ದುರದೃಷ್ಟವಶಾತ್, ವೆಬ್ ಸಾಕೆಟ್‌ಗಳಿಗಾಗಿ ಕ್ಲೈಂಟ್ ಸೆರ್ಟ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ಸಫಾರಿಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಅಂತಹ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಹಲವು ಸೂಚನೆಗಳಿವೆ, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದನ್ನು ಸಾಧಿಸಲಾಗುವುದಿಲ್ಲ.

ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಾವು ಈ ಕೆಳಗಿನ ಯೋಜನೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ: ಸಮಸ್ಯೆ/ಊಹೆ/ಪರಿಹಾರ.

ಸಮಸ್ಯೆ: IOS ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಬೆಂಬಲವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ Safari ಮೊಬೈಲ್ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರದಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುವಾಗ ವೆಬ್ ಸಾಕೆಟ್‌ಗಳಿಗೆ ಯಾವುದೇ ಬೆಂಬಲವಿಲ್ಲ.

ಕಲ್ಪನೆಗಳು:

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

ಅನುಷ್ಠಾನದ ನಂತರ ಗೋಚರಿಸುವ ಸ್ಥಿತಿ.

ಉದ್ದೇಶ: ಸೇವೆಗಳ ನಿರ್ವಹಣೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯವು ಐಒಎಸ್‌ನಲ್ಲಿ ಮೊಬೈಲ್ ಫೋನ್‌ನಿಂದ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯಕ್ರಮಗಳಿಲ್ಲದೆ (ವಿಪಿಎನ್‌ನಂತಹ) ಏಕೀಕೃತ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿರಬೇಕು.

ಹೆಚ್ಚುವರಿ ಗುರಿ: ಮೊಬೈಲ್ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ವಿಷಯದ ವೇಗದ ವಿತರಣೆಯೊಂದಿಗೆ ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳು/ಫೋನ್ ದಟ್ಟಣೆಯನ್ನು ಉಳಿಸುವುದು (ವೆಬ್ ಸಾಕೆಟ್‌ಗಳಿಲ್ಲದ ಕೆಲವು ಸೇವೆಗಳು ಅನಗತ್ಯ ವಿನಂತಿಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ).

ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು?

1. ತೆರೆಯುವ ಪುಟಗಳು:

— например, https://teamcity.yourdomain.com в мобильном браузере Safari (доступен также в десктопной версии) — вызывает успешное подключение к веб-сокетам.
— например, https://teamcity.yourdomain.com/admin/admin.html?item=diagnostics&tab=webS…— показывает ping/pong.
— например, https://rancher.yourdomain.com/p/c-84bnv:p-vkszd/workload/deployment:danidb:ph…-> viewlogs — показывает логи контейнера.

2. ಅಥವಾ ಡೆವಲಪರ್ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ:

ಊಹೆಯ ಪರೀಕ್ಷೆ:

1. ಆಂತರಿಕ/ಬಾಹ್ಯ ಪ್ರಾಕ್ಸಿಡ್ ಸಂಪನ್ಮೂಲಗಳ ವೆಬ್ ಸಾಕೆಟ್‌ಗಳಿಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು (ಯಾವುದೂ ಇರುವುದಿಲ್ಲ ಎಂದು ತಿಳಿದುಕೊಂಡು) ಬಳಸಲು ಅಂತಹ ವಿನಾಯಿತಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ.

2 ಪರಿಹಾರಗಳು ಇಲ್ಲಿ ಕಂಡುಬಂದಿವೆ:

ಎ) ಮಟ್ಟದಲ್ಲಿ

<Location sock*> SSLVerifyClient optional </Location>
<Location /> SSLVerifyClient require </Location>

ಪ್ರವೇಶ ಮಟ್ಟವನ್ನು ಬದಲಾಯಿಸಿ.

ಈ ವಿಧಾನವು ಈ ಕೆಳಗಿನ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ:

ಪ್ರಾಕ್ಸಿಡ್ ಸಂಪನ್ಮೂಲಕ್ಕೆ ವಿನಂತಿಯ ನಂತರ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಸಂಭವಿಸುತ್ತದೆ, ಅಂದರೆ ಪೋಸ್ಟ್ ವಿನಂತಿಯ ಹ್ಯಾಂಡ್‌ಶೇಕ್. ಇದರರ್ಥ ಪ್ರಾಕ್ಸಿಯು ಮೊದಲು ಲೋಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಸಂರಕ್ಷಿತ ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತದೆ. ಇದು ಕೆಟ್ಟದು, ಆದರೆ ವಿಮರ್ಶಾತ್ಮಕವಲ್ಲ;
http2 ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ. ಇದು ಇನ್ನೂ ಡ್ರಾಫ್ಟ್‌ನಲ್ಲಿದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ತಯಾರಕರಿಗೆ ಇದನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಎಂದು ತಿಳಿದಿಲ್ಲ #tls1.3 http2 ಪೋಸ್ಟ್ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಬಗ್ಗೆ ಮಾಹಿತಿ (ಈಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ) RFC 8740 "HTTP/1.3 ಜೊತೆಗೆ TLS 2 ಅನ್ನು ಬಳಸುವುದು" ಕಾರ್ಯಗತಗೊಳಿಸಿ;
ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಏಕೀಕರಿಸುವುದು ಹೇಗೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.

b) ಮೂಲಭೂತ ಮಟ್ಟದಲ್ಲಿ, ಪ್ರಮಾಣಪತ್ರವಿಲ್ಲದೆ ssl ಅನ್ನು ಅನುಮತಿಸಿ.

SSLVerifyClient ಅಗತ್ಯವಿದೆ => SSLVerifyClient ಐಚ್ಛಿಕ, ಆದರೆ ಇದು ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ನ ಭದ್ರತಾ ಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಅಂತಹ ಸಂಪರ್ಕವನ್ನು ಪ್ರಮಾಣಪತ್ರವಿಲ್ಲದೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನೀವು ಈ ಕೆಳಗಿನ ನಿರ್ದೇಶನದೊಂದಿಗೆ ಪ್ರಾಕ್ಸಿಡ್ ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರಾಕರಿಸಬಹುದು:

RewriteEngine        on
RewriteCond     %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteRule     .? - [F]
ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

ssl ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಲೇಖನದಲ್ಲಿ ಕಾಣಬಹುದು: ಅಪಾಚೆ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ದೃಢೀಕರಣ

ಎರಡೂ ಆಯ್ಕೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲಾಯಿತು, ಅದರ ಬಹುಮುಖತೆ ಮತ್ತು http2 ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಗಾಗಿ "b" ಆಯ್ಕೆಯನ್ನು ಆರಿಸಲಾಗಿದೆ.

ಈ ಊಹೆಯ ಪರಿಶೀಲನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು, ಇದು ಸಂರಚನೆಯೊಂದಿಗೆ ಸಾಕಷ್ಟು ಪ್ರಯೋಗಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು; ಕೆಳಗಿನ ವಿನ್ಯಾಸಗಳನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿದೆ:

if = ಅಗತ್ಯವಿದೆ = ಪುನಃ ಬರೆಯಿರಿ

ಫಲಿತಾಂಶವು ಈ ಕೆಳಗಿನ ಮೂಲ ವಿನ್ಯಾಸವಾಗಿದೆ:

SSLVerifyClient optional
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule     .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

#websocket for safari without cert auth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
...
    #замещаем авторизацию по владельцу сертификата на авторизацию по номеру протокола
    SSLUserName SSl_PROTOCOL
</If>
</If>

ಪ್ರಮಾಣಪತ್ರದ ಮಾಲೀಕರಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದೃಢೀಕರಣವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಆದರೆ ಕಾಣೆಯಾದ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ, ನಾನು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಪ್ರಮಾಣಪತ್ರ ಮಾಲೀಕರನ್ನು ಲಭ್ಯವಿರುವ ವೇರಿಯೇಬಲ್‌ಗಳಲ್ಲಿ ಒಂದಾದ SSl_PROTOCOL (SSL_CLIENT_S_DN_CN ಬದಲಿಗೆ) ರೂಪದಲ್ಲಿ ಸೇರಿಸಬೇಕಾಗಿತ್ತು, ದಸ್ತಾವೇಜನ್ನು ಹೆಚ್ಚಿನ ವಿವರಗಳು:

ಅಪಾಚೆ ಮಾಡ್ಯೂಲ್ mod_ssl

2. ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳಿಗಾಗಿ, ಸಾಮಾನ್ಯ (ವೆಬ್‌ಸಾಕೆಟ್ ಅಲ್ಲದ) ಬ್ರೌಸರ್ ವಿನಂತಿಯ ಸಮಯದಲ್ಲಿ ರಚಿಸಲಾದ ತಾತ್ಕಾಲಿಕ ಸೆಷನ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಅನನ್ಯ, ಸುರಕ್ಷಿತ ಮತ್ತು ರಕ್ಷಿತ ಸಂಪರ್ಕವನ್ನು ಮಾಡಬಹುದು.

ಹಿಂದಿನ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ, ನಿಯಮಿತ (ವೆಬ್ ಅಲ್ಲದ ಸಾಕೆಟ್) ವಿನಂತಿಯ ಸಮಯದಲ್ಲಿ ವೆಬ್ ಸಾಕೆಟ್ ಸಂಪರ್ಕಗಳಿಗಾಗಿ ತಾತ್ಕಾಲಿಕ ಟೋಕನ್‌ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಸಲುವಾಗಿ ನೀವು ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಹೆಚ್ಚುವರಿ ವಿಭಾಗವನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ.

#подготовка передача себе Сookie через пользовательский браузер
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
Header set Set-Cookie "websocket-allowed=true; path=/; Max-Age=100"
</If>
</If>

#проверка Cookie для установления веб-сокет соединения
<source lang="javascript">
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
#check for exists cookie

#get and check
SetEnvIf Cookie "websocket-allowed=(.*)" env-var-name=$1

#or rewrite rule
RewriteCond %{HTTP_COOKIE} !^.*mycookie.*$

#or if
<If "%{HTTP_COOKIE} =~ /(^|; )cookie-names*=s*some-val(;|$)/ >
</If

</If>
</If>

ಪರೀಕ್ಷೆಯು ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸಿದೆ. ಬಳಕೆದಾರರ ಬ್ರೌಸರ್ ಮೂಲಕ ಕುಕೀಗಳನ್ನು ನಿಮಗೆ ವರ್ಗಾಯಿಸಲು ಸಾಧ್ಯವಿದೆ.

3. ಒಂದು ಪ್ರಾಕ್ಸಿ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ತಾತ್ಕಾಲಿಕ ಅವಧಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು (ಅಂತರ್ನಿರ್ಮಿತ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾರ್ಯಗಳು ಮಾತ್ರ).

ನಾವು ಮೊದಲೇ ಕಂಡುಕೊಂಡಂತೆ, ಅಪಾಚೆ ಸಾಕಷ್ಟು ಕೋರ್ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದೆ ಅದು ನಿಮಗೆ ಷರತ್ತುಬದ್ಧ ರಚನೆಗಳನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಬಳಕೆದಾರರ ಬ್ರೌಸರ್‌ನಲ್ಲಿರುವಾಗ ನಮ್ಮ ಮಾಹಿತಿಯನ್ನು ರಕ್ಷಿಸಲು ನಮಗೆ ಸಾಧನಗಳು ಬೇಕಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ನಾವು ಏನನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಏಕೆ ಮತ್ತು ಯಾವ ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಸ್ಥಾಪಿಸುತ್ತೇವೆ:

ನಮಗೆ ಸುಲಭವಾಗಿ ಡಿಕೋಡ್ ಮಾಡಲಾಗದ ಟೋಕನ್ ಅಗತ್ಯವಿದೆ.
ನಮಗೆ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಹಳೆಯದನ್ನು ಪರಿಶೀಲಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಟೋಕನ್ ಅಗತ್ಯವಿದೆ.
ಪ್ರಮಾಣಪತ್ರದ ಮಾಲೀಕರೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಟೋಕನ್ ನಮಗೆ ಅಗತ್ಯವಿದೆ.

ಇದಕ್ಕೆ ಹ್ಯಾಶಿಂಗ್ ಫಂಕ್ಷನ್, ಉಪ್ಪು ಮತ್ತು ಟೋಕನ್ ವಯಸ್ಸಿಗೆ ದಿನಾಂಕದ ಅಗತ್ಯವಿದೆ. ದಸ್ತಾವೇಜನ್ನು ಆಧರಿಸಿ ಅಪಾಚೆ HTTP ಸರ್ವರ್‌ನಲ್ಲಿನ ಅಭಿವ್ಯಕ್ತಿಗಳು ನಾವು sha1 ಮತ್ತು %{TIME} ಬಾಕ್ಸ್‌ನಿಂದ ಎಲ್ಲವನ್ನೂ ಹೊಂದಿದ್ದೇವೆ.

ಫಲಿತಾಂಶವು ಈ ವಿನ್ಯಾಸವಾಗಿತ್ತು:

#нет сертификата, и обращение к websocket
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
    SetEnvIf Cookie "zt-cert-sha1=([^;]+)" zt-cert-sha1=$1
    SetEnvIf Cookie "zt-cert-uid=([^;]+)" zt-cert-uid=$1
    SetEnvIf Cookie "zt-cert-date=([^;]+)" zt-cert-date=$1

#только так можно работать с переменными, полученными в env-ах в этот момент времени, более они нигде не доступны для функции хеширования (по отдельности можно, но не вместе, да и ещё с хешированием)
    <RequireAll>
        Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
        Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
    </RequireAll>
</If>
</If>

#есть сертификат, запрашивается не websocket
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
    SetEnvIf Cookie "zt-cert-sha1=([^;]+)" HAVE_zt-cert-sha1=$1

    SetEnv zt_cert "path=/; HttpOnly;Secure;SameSite=Strict"
#Новые куки ставятся, если старых нет
    Header add Set-Cookie "expr=zt-cert-sha1=%{sha1:salt1%{TIME}salt3%{SSL_CLIENT_S_DN_CN}salt2};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
    Header add Set-Cookie "expr=zt-cert-uid=%{SSL_CLIENT_S_DN_CN};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
    Header add Set-Cookie "expr=zt-cert-date=%{TIME};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
</If>
</If>

ಗುರಿಯನ್ನು ಸಾಧಿಸಲಾಗಿದೆ, ಆದರೆ ಸರ್ವರ್ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಸಮಸ್ಯೆಗಳಿವೆ (ನೀವು ವರ್ಷ ವಯಸ್ಸಿನ ಕುಕಿಯನ್ನು ಬಳಸಬಹುದು), ಅಂದರೆ ಟೋಕನ್‌ಗಳು ಆಂತರಿಕ ಬಳಕೆಗೆ ಸುರಕ್ಷಿತವಾಗಿದ್ದರೂ, ಕೈಗಾರಿಕಾ (ಸಾಮೂಹಿಕ) ಬಳಕೆಗೆ ಅಸುರಕ್ಷಿತವಾಗಿದೆ.

4. ತಾತ್ಕಾಲಿಕ ಸೆಷನ್ ಟೋಕನ್‌ಗಳನ್ನು ಈಗಾಗಲೇ ಸಿದ್ದವಾಗಿರುವ ಅಪಾಚೆ ಮಾಡ್ಯೂಲ್‌ಗಳಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ.

ಹಿಂದಿನ ಪುನರಾವರ್ತನೆಯಿಂದ ಒಂದು ಗಮನಾರ್ಹ ಸಮಸ್ಯೆ ಉಳಿದಿದೆ - ಟೋಕನ್ ವಯಸ್ಸನ್ನು ನಿಯಂತ್ರಿಸಲು ಅಸಮರ್ಥತೆ.

ಪದಗಳ ಪ್ರಕಾರ ಇದನ್ನು ಮಾಡುವ ಸಿದ್ಧ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಾವು ಹುಡುಕುತ್ತಿದ್ದೇವೆ: apache token json two factor auth

ಹೌದು, ರೆಡಿಮೇಡ್ ಮಾಡ್ಯೂಲ್‌ಗಳಿವೆ, ಆದರೆ ಅವೆಲ್ಲವೂ ನಿರ್ದಿಷ್ಟ ಕ್ರಿಯೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿವೆ ಮತ್ತು ಅಧಿವೇಶನವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಕುಕೀಗಳ ರೂಪದಲ್ಲಿ ಕಲಾಕೃತಿಗಳನ್ನು ಹೊಂದಿವೆ. ಅಂದರೆ, ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಅಲ್ಲ.
ನಾವು ಹುಡುಕಲು ಐದು ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದು ಕಾಂಕ್ರೀಟ್ ಫಲಿತಾಂಶವನ್ನು ನೀಡಲಿಲ್ಲ.

5. ತಾರ್ಕಿಕವಾಗಿ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳ ರಚನೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮೂಲಕ ತಾತ್ಕಾಲಿಕ ಅಧಿವೇಶನ ಟೋಕನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.

ರೆಡಿಮೇಡ್ ಮಾಡ್ಯೂಲ್ಗಳು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿವೆ, ಏಕೆಂದರೆ ನಮಗೆ ಕೇವಲ ಒಂದೆರಡು ಕಾರ್ಯಗಳು ಬೇಕಾಗುತ್ತವೆ.

ಹಾಗೆ ಹೇಳುವುದಾದರೆ, ದಿನಾಂಕದೊಂದಿಗಿನ ಸಮಸ್ಯೆಯೆಂದರೆ, ಅಪಾಚೆಯ ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯಗಳು ಭವಿಷ್ಯದಿಂದ ದಿನಾಂಕವನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹಳೆಯದನ್ನು ಪರಿಶೀಲಿಸುವಾಗ ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯಗಳಲ್ಲಿ ಯಾವುದೇ ಗಣಿತದ ಸೇರ್ಪಡೆ/ವ್ಯವಕಲನವಿಲ್ಲ.

ಅಂದರೆ, ನೀವು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ:

(%{env:zt-cert-date} + 30) > %{DATE}

ನೀವು ಎರಡು ಸಂಖ್ಯೆಗಳನ್ನು ಮಾತ್ರ ಹೋಲಿಸಬಹುದು.

ಸಫಾರಿ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಹುಡುಕುತ್ತಿರುವಾಗ, ನಾನು ಆಸಕ್ತಿದಾಯಕ ಲೇಖನವನ್ನು ಕಂಡುಕೊಂಡೆ: ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ ಹೋಮ್ ಅಸಿಸ್ಟೆಂಟ್ ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು (Safari/iOS ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ)
ಇದು Nginx ಗಾಗಿ ಲುವಾದಲ್ಲಿನ ಕೋಡ್‌ನ ಉದಾಹರಣೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಬದಲಾದಂತೆ, ಹ್ಯಾಶಿಂಗ್‌ಗಾಗಿ hmac ಸಾಲ್ಟಿಂಗ್ ವಿಧಾನವನ್ನು ಹೊರತುಪಡಿಸಿ, ನಾವು ಈಗಾಗಲೇ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಆ ಭಾಗದ ತರ್ಕವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ ( ಇದು ಅಪಾಚೆಯಲ್ಲಿ ಕಂಡುಬಂದಿಲ್ಲ).

ಲುವಾ ಸ್ಪಷ್ಟವಾದ ತರ್ಕವನ್ನು ಹೊಂದಿರುವ ಭಾಷೆ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು ಮತ್ತು ಅಪಾಚೆಗೆ ಸರಳವಾದದ್ದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿದೆ:

Nginx ಮತ್ತು Apache ನೊಂದಿಗೆ ವ್ಯತ್ಯಾಸವನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದ ನಂತರ:

ಮತ್ತು ಲುವಾ ಭಾಷಾ ತಯಾರಕರಿಂದ ಲಭ್ಯವಿರುವ ಕಾರ್ಯಗಳು:
22.1 - ದಿನಾಂಕ ಮತ್ತು ಸಮಯ

ಪ್ರಸ್ತುತದೊಂದಿಗೆ ಹೋಲಿಸಲು ಭವಿಷ್ಯದ ದಿನಾಂಕವನ್ನು ಹೊಂದಿಸಲು ಸಣ್ಣ ಲುವಾ ಫೈಲ್‌ನಲ್ಲಿ env ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಹೊಂದಿಸುವ ಮಾರ್ಗವನ್ನು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.

ಸರಳವಾದ ಲುವಾ ಸ್ಕ್ರಿಪ್ಟ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

require 'apache2'

function handler(r)
    local fmt = '%Y%m%d%H%M%S'
    local timeout = 3600 -- 1 hour

    r.notes['zt-cert-timeout'] = timeout
    r.notes['zt-cert-date-next'] = os.date(fmt,os.time()+timeout)
    r.notes['zt-cert-date-halfnext'] = os.date(fmt,os.time()+ (timeout/2))
    r.notes['zt-cert-date-now'] = os.date(fmt,os.time())

    return apache2.OK
end

ಮತ್ತು ಹಳೆಯ ಕುಕೀ (ಟೋಕನ್) ಅವಧಿ ಮುಗಿಯುವ ಮೊದಲು ಅರ್ಧದಷ್ಟು ಸಮಯ ಬಂದಾಗ ಕುಕೀಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಪ್ಟಿಮೈಸೇಶನ್ ಮತ್ತು ಟೋಕನ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದರೊಂದಿಗೆ ಇದು ಒಟ್ಟಾರೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

SSLVerifyClient optional

#LuaScope thread
#generate event variables zt-cert-date-next
LuaHookAccessChecker /usr/local/etc/apache24/sslincludes/websocket_token.lua handler early

#запрещаем без сертификата что-то ещё, кроме webscoket
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule     .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

#websocket for safari without certauth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
    SetEnvIf Cookie "zt-cert=([^,;]+),([^,;]+),[^,;]+,([^,;]+)" zt-cert-sha1=$1 zt-cert-date=$2 zt-cert-uid=$3

    <RequireAll>
        Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
        Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
        Require expr %{env:zt-cert-date} -ge %{env:zt-cert-date-now}
    </RequireAll>
   
    #замещаем авторизацию по владельцу сертификата на авторизацию по номеру протокола
    SSLUserName SSl_PROTOCOL
    SSLOptions -FakeBasicAuth
</If>
</If>

<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
    SetEnvIf Cookie "zt-cert=([^,;]+),[^,;]+,([^,;]+)" HAVE_zt-cert-sha1=$1 HAVE_zt-cert-date-halfnow=$2
    SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1

    Define zt-cert "path=/;Max-Age=%{env:zt-cert-timeout};HttpOnly;Secure;SameSite=Strict"
    Define dates_user "%{env:zt-cert-date-next},%{env:zt-cert-date-halfnext},%{SSL_CLIENT_S_DN_CN}"
    Header set Set-Cookie "expr=zt-cert=%{sha1:salt1%{env:zt-cert-date-next}sal3%{SSL_CLIENT_S_DN_CN}salt2},${dates_user};${zt-cert}" env=!HAVE_zt-cert-sha1-found
</If>
</If>

SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1
работает,

а так работать не будет
SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge  env('zt-cert-date-now') && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1

ಏಕೆಂದರೆ Nginx ನಿಂದ ಈ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ ಪ್ರವೇಶ ಪರಿಶೀಲನೆಯ ನಂತರವೇ LuaHookAccessChecker ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಮೂಲಕ್ಕೆ ಲಿಂಕ್ ಮಾಡಿ ಚಿತ್ರ.

ಇನ್ನೊಂದು ವಿಷಯ.

ಸಾಮಾನ್ಯವಾಗಿ, ಅಪಾಚೆ (ಬಹುಶಃ Nginx) ಸಂರಚನೆಯಲ್ಲಿ ನಿರ್ದೇಶನಗಳನ್ನು ಯಾವ ಕ್ರಮದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಎಂಬುದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕೊನೆಯಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಬಳಕೆದಾರರ ವಿನಂತಿಯ ಕ್ರಮದ ಆಧಾರದ ಮೇಲೆ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ, ಇದು ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಯೋಜನೆಗೆ ಅನುರೂಪವಾಗಿದೆ. ಲುವಾ ಲಿಪಿಗಳು.

ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ:

ಅನುಷ್ಠಾನದ ನಂತರ ಗೋಚರಿಸುವ ಸ್ಥಿತಿ (ಗುರಿ):
ಸೇವೆಗಳ ನಿರ್ವಹಣೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯವು ಮೊಬೈಲ್ ಫೋನ್‌ನಿಂದ IOS ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯಕ್ರಮಗಳಿಲ್ಲದೆ (VPN), ಏಕೀಕೃತ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿದೆ.

ಗುರಿಯನ್ನು ಸಾಧಿಸಲಾಗಿದೆ, ವೆಬ್ ಸಾಕೆಟ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಕ್ಕಿಂತ ಕಡಿಮೆಯಿಲ್ಲದ ಭದ್ರತೆಯ ಮಟ್ಟವನ್ನು ಹೊಂದಿವೆ.

ಮೂಲ: www.habr.com

ZeroTech ನಲ್ಲಿ ನಾವು Apple Safari ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ Отменить ответ