GNU parallele mehrere Sshlogin-Knoten hinter NAT

GNU parallele mehrere Sshlogin-Knoten hinter NAT

Ist es möglich, mit GNU parallel mehrere Remote-Knoten hinter einem NAT zu haben?

Angenommen, ein Teil eines parallelen GNU-Clusters existiert relativ zum Masterknoten hinter einem NAT (das möglicherweise nur über eine einzelne IPv4-Adresse über einen ISP zugänglich ist, der nur IPv4 verwendet). Das heißt, es gibt mehr als einen PC-Knoten mit seiner eigenen Subnetz-IP-Adresse, der in einem anderen Subnetz als dem existiert, in dem sich der Masterknoten befindet.

Gibt es eine Möglichkeit, dass GNU-parallel die Arbeit über NAT an alle diese Knoten verteilt?

Nach einigen Recherchen und Überlegungen zu diesem Thema, einschließlich eines Blicks auf dieseetwas verwandte Frage

Die einzige Möglichkeit, die mir einfällt, wäre, für jeden Knoten manuell einen anderen Port zu definieren. Dazu verwenden Sie das Flag -p, das imHandbuchund fügen Sie dann für jeden Knoten:Port manuell eine Portweiterleitungsregel im NAT hinzu

Gibt es in GNU-Parallel einen „Trick“, mit dem Jobs an einen Knoten hinter dem NAT übergeben und von dort an andere Knoten in seinem Subnetz verteilt werden können?

Oder vielleicht gibt es eine Methode, mit der Slave-Knoten eine Nachricht über einen https-POST mit einem Cron-Job übermitteln und irgendwie eine etablierte Verbindung über einen öffentlichen Port herstellen und aufrechterhalten können? Ähnlich wie man öffentliche Schlüssel erhält, wie indiese Frage(diese Idee geht definitiv über mein Verständnis von TCP/IPTABLES hinaus, daher ist mir bewusst, dass sie auf den ersten Blick möglicherweise grundsätzliche Fehler enthält)

Eine Lösung, die ausschließlich innerhalb des Masterknotens und der Slaveknoten implementiert werden könnte, wäre einer Lösung vorzuziehen, bei der NAT-Einträge erforderlich wären.

Antwort1

Es gibt mehrere Lösungen.

Die Worker stehen hinter NAT. Kein Zugriff auf einen Jump-Host. Kein Zugriff auf die Firewall.

Dazu benötigen Sie eine Art VPN, das die Firewall umgehen kann. Hierfür kann ein versteckter TOR-Dienst für Port 22 auf den Workern verwendet werden. Wenn alle Worker TOR-fähig sind:

parallel --ssh 'torsocks ssh' -S zij4uclus7xhwlhz.onion,isj4uclus7xhwlhz.onion,lzw4uclus7xhwlhz.onion echo ::: 1

Wenn nur einige davon vorhanden sind:

parallel -S 'torsocks ssh zij4uclus7xhwlhz.onion,torsocks ssh isj4uclus7xhwlhz.onion,torsocks ssh lzw4uclus7xhwlhz.onion' echo ::: 1

Die Worker stehen hinter NAT. Kein Zugriff auf einen Jump-Host. Zugriff auf die Firewall.

Wenn Sie Ports weiterleiten können, sodass Port 2001 Port 22 auf Host 1 ist, Port 2002 Port 22 auf Host 2 ist, 2003 Host 3 ist ... dann können Sie -p verwenden:

parallel -S 'ssh -p 2001 firewall,ssh -p 2002 firewall,ssh -p 2003 firewall' echo ::: 1

Sie können dies einfügen in .ssh/config:

Host host1.v
  Port 2001
Host host2.v
  Port 2002
Host host3.v
  Port 2003

Host *.v
  Hostname firewall

Und dann verwenden Sie einfach host[1-3].v als normale Hosts:

parallel -S host1.v,host2.v,host3.v echo ::: 1

Die Worker stehen hinter NAT. Zugriff auf einen Jump-Host.

Wenn Sie Zugriff auf einen Jump-Host haben, von dem aus Sie die Worker erreichen können, wäre folgendes naheliegend:

parallel --ssh 'ssh jumphost ssh' -S host1 echo ::: DOES NOT WORK

Aber diesesfunktioniert nichtweil der Befehl von ssh zweimal dequotiert wird, während GNU Parallel nur erwartet, dass die Anführungszeichen einmal entfernt werden.

Verwenden Sie stattdessen .ssh/configerneut:

Host host1 host2 host3
  ProxyCommand ssh jump.host.domain nc -w 1 %h 22

Dafür muss nc(netcat) auf dem Jumphost installiert sein.

verwandte Informationen