SOCKS für blockierende Nicht-TLS-RabbitMQ-Verbindungen in Spring AMQP

Für eine blockierende Nicht-TLS-AMQP-Verbindung kann die RabbitConnectionFactoryBean von Spring eine SOCKS-fähige Socket-Factory an den RabbitMQ-Java-Client übergeben.

Wenn Commons Net bereits verfügbar ist, konfigurieren Sie die vorhandene Factory-Bean vor der Initialisierung:

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 ist die RabbitConnectionFactoryBean der Anwendung. Behalten Sie ihren Broker-Host, AMQP-Port, Account und die Spring-Konfiguration zur Verbindungsverwaltung bei. Der Broker bleibt das Ziel; die SocketFactory erzeugt die Sockets, die ihn über SOCKS erreichen. Für einen unkritischen Test gegen einen öffentlichen Broker, bei dem öffentliche Vermittler zulässig sind, bietet die SOCKS-Proxy-Liste Kandidaten; gleichen Sie die von der Laufzeit unterstützte SOCKS-Version ab und bestätigen Sie den Zugriff auf den tatsächlichen Broker-Host und -Port.

Die Factory von Commons Net erzeugt mit dem übergebenen Proxy einen nicht verbundenen java.net.Socket. Der blockierende Verbindungscode von RabbitMQ verbindet diesen Socket dann über seinen normalen Verbindungspfad. Das bloße Exportieren von HTTP_PROXY stellt diese AMQP-SocketFactory nicht bereit.

RabbitMQ dokumentiert, dass der SocketFactory-Hook für blockierende E/A gilt. Ein für NIO oder einen anderen Transport konfigurierter Client benötigt den vom jeweiligen Transport unterstützten Hook. Für AMQPS behalten Sie eine geeignete TLS-SocketFactory und die Zielverifizierung bei; der Austausch gegen die obige einfache Factory ist keine vollständige TLS-Konfiguration.