Я пытаюсь контролировать удаленный jvm с помощью jconsole. Мне нужно провести этот мониторинг через сеть OpenVPN, что может быть частью проблемы. Это конфигурация сети:
Server A Server B Server C
Jconsole JVM
10.171.0.1 <---> 10.170.0.1 <---> 10.170.0.14
Когда все серверы находятся в разных физических сетях, это не работает. когда Server A и Server C находятся в той же физической сети, что и работает. В обоих случаях traceroute описан в конфигурации сети и выглядит примерно так:
traceroute to 10.170.0.14 (10.170.0.14), 64 hops max, 52 byte packets
1 10.170.0.1 (10.170.0.1) 114.440 ms 109.152 ms 109.581 ms
2 10.170.0.14 (10.170.0.14) 234.207 ms 228.535 ms 229.630 ms
Есть идеи, как это решить?
[РЕДАКТИРОВАТЬ]
Все системы - linux.
Удаленные параметры Jmx:
-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Сервер Server B (10.170.0.1) используется как мост и межсетевой экран между двумя сетями. Брандмауэр в 10.170.0.1 как следует:
*filter
:INPUT DROP [1000:900000]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 389 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8086 -j ACCEPT
-A INPUT -p udp -m udp --dport 8086 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 13 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 30 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.171.0.1 -d 10.170.0.0/16 -j ACCEPT
-A FORWARD -s 10.171.0.3 -d 10.170.0.0/16 -j ACCEPT
-A FORWARD -s 10.170.0.0/16 -d 10.171.0.0/16 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
Давно не задавался этот вопрос, но поскольку @mark проявил некоторый интерес, вот как я в конечном итоге решил его. Проблема заключалась в том, что JVM привязывалась к локальному IP-адресу, а не к IP-адресу VPN. Все заработало, добавив:
-Djava.rmi.server.hostname=10.170.0.14
На сервер, за которым я хотел следить.
-Dcom.sun.management.jmxremote.port=1616
-Dcom.sun.management.jmxremote.rmi.port=1618
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
ssh solr@remote-host -L 1616:remote-host:1616 -L 1618:remote-host:1618
jconsole localhost:1616
3 вещи, которые стоит попробовать, если вы еще этого не сделали: 1) полностью избавьтесь от правил брандмауэра на всех машинах, для тестирования (если вы можете это сделать) 2) если 1) не вариант, настройте 3 виртуальные машины, которые имитировать настройку без брандмауэров - при этом я обнаружил аналогичную проблему в моей собственной сети. 3) убедитесь, что у вас есть keepalive в файле конфигурации клиента openvpn - строка вроде: keepalive 10 120
Похожая проблема, с которой я столкнулся, заключалась в том, что сеть моей компании была настроена так, чтобы отбрасывать любые входящие пакеты после x секунд бездействия, поэтому, хотя технически VPN была еще открыта, весь трафик в одном направлении отбрасывался до тех пор, пока некоторый трафик не пришел с другой стороны, тогда это сработало.