SOCKS לחיבורי RabbitMQ לא-TLS חוסמים ב-Spring AMQP

חברו SocketFactory מודע ל-proxy דרך RabbitConnectionFactoryBean עבור נתיב החיבור AMQP הלא-TLS החוסם.

עבור חיבור AMQP חוסם ולא-TLS, ה-RabbitConnectionFactoryBean של Spring יכול להעביר מפעל sockets מודע ל-SOCKS ללקוח ה-Java של RabbitMQ.

אם Commons Net זמין כבר, הגדירו את ה-factory bean הקיים לפני האתחול:

var socksProxy = new java.net.Proxy(
    java.net.Proxy.Type.SOCKS,
    new java.net.InetSocketAddress("proxy.example", 1080));
rabbitFactoryBean.setSocketFactory(
    new org.apache.commons.net.DefaultSocketFactory(socksProxy));

‏rabbitFactoryBean הוא ה-RabbitConnectionFactoryBean של היישום. שמרו על מארח ה-broker, פורט AMQP, החשבון והגדרת ניהול החיבורים של Spring. ה-broker נשאר היעד; ה-SocketFactory יוצר את ה-sockets שמגיעים אליו דרך SOCKS. לבדיקה לא רגישה מול broker ציבורי שבו מתווכים ציבוריים מותרים, רשימת פרוקסי SOCKS מציעה מועמדים; התאימו לגרסת SOCKS שהסביבה תומכת בה ואשרו גישה למארח ולפורט האמיתיים של ה-broker.

המפעל של Commons Net יוצר java.net.Socket לא מחובר באמצעות ה-Proxy שסופק. לאחר מכן קוד החיבור החוסם של RabbitMQ מחבר את ה-socket הזה בנתיב החיבור הרגיל שלו. ייצוא של HTTP_PROXY בלבד אינו מספק את מפעל ה-sockets הזה של AMQP.

‏RabbitMQ מתעד שה-hook של SocketFactory חל על קלט/פלט חוסם. לקוח שמוגדר ל-NIO או לתעבורה אחרת זקוק ל-hook הנתמך באותה תעבורה. עבור AMQPS, שמרו על מפעל sockets מתאים ל-TLS ועל אימות היעד; החלפתו במפעל הפשוט שלמעלה אינה הגדרת TLS מלאה.

מאמרים קשורים