¿Cómo puedo exponer el servidor RPC de Geth a conexiones externas?

Quiero configurar una red privada de aplicaciones que pueda conectarse a un único nodo Geth. ¿Qué opciones tengo para exponer el servidor RPC?

Estoy ejecutando esto: geth --rpc --testnet(a veces uso --dev)

¿Cómo puedo lograr lo siguiente:

  • Permitir claves públicas/privadas específicas para acceder al nodo
  • Permitir que cualquier persona acceda al nodo
  • Permitir rango de IP para acceder al nodo

¿Solución posible?

¿Esto solo requeriría ejecutar un proxy inverso con un servidor como Nginx?

Parece la opción geth: --rpccorsdomainpuede ser lo que estoy buscando. Creo que puede especificar --rpccorsdomain "*"cuál permitirá que cualquiera acceda al servidor RPC. Estoy seguro de que también puede usar un proxy inverso para lograr esto. Basé mi información en este repositorio: github.com/Kunstmaan/docker-ethereum
Sí, rpccorsdomain es lo que quieres, considera responder tu propia pregunta.
Tenga en cuenta CORSque los navegadores lo aplican. Es una medida de seguridad para prevenir ataques de secuencias de comandos en sitios cruzados y DDOS al evitar que las masas que usan navegadores simples hagan algo estúpido accidentalmente. Sin embargo, un atacante puede ignorar libremente cualquier solicitud de CORS que el servidor devuelva. No debe utilizarse como medida de seguridad.

Respuestas (4)

Puede crear de manera fácil y segura un túnel SSH a su nodo ETH desde el servidor de aplicaciones. De esta manera, el nodo ETH es engañado haciéndole creer que la conexión es de localhost y puede asegurarse de que solo el titular de una clave privada pueda acceder.

Este es un enlace a las instrucciones sobre cómo configurar la autenticación basada en certificados

Es importante configurar la autenticación de certificados porque, de lo contrario, no podrá automatizar el proceso.

Una vez que haya configurado eso, puede crear un túnel ejecutando un comando como:

ssh -f -N -L 9545:localhost:8545 remoteUser@remotehost.remotedomain.tld

Los números de puerto son diferentes en mi ejemplo, para que el lector pueda diferenciarlos. No hay absolutamente ninguna otra razón para hacerlos diferentes.

Una vez que se haya emitido este comando , se reenviará todo el tráfico a port 9545on , que considerará que se ha originado y estará dirigido alocalhostremotehost.remotedomain.tld:8545localhostlocalhost:8545

De esta manera, puede mantener su nodo ETH detrás de un firewall y no abrirlo al mundo, pero aun así centralizar la funcionalidad.

Para usar esto en producción, deberá resolver el problema de desconectar las sesiones SSH.

Hola señor, sobre la solución, ¿Esta solución solo funcionaría para los usuarios que conocen la contraseña para el usuario remoto@remotehost.remotedomain.tld? (según tengo entendido desde mi nodo externo, tengo que ejecutar el comando ssh y debo saber la contraseña para "remoteUser@remotehost.remotedomain.tld"). ¿Requiere que cualquier usuario tenga acceso al servidor (remotehost.remotedomain.tld) ​​con un nombre de usuario? o debo anunciar públicamente una contraseña para el "usuario remoto"?
¡publicar una contraseña es una mala idea! Pero más concretamente, realmente debería usar la autenticación basada en certificados para NO tener que ingresar la contraseña. Además, este método no está destinado a dar acceso al nodo a los usuarios finales, sino a dar acceso al nodo a los servidores de aplicaciones.
¿Sería buena idea utilizar Docker como servidor de aplicaciones dentro de mi nodo ETH? Entonces, Docker como servidor de aplicaciones puede crear un túnel. @Dra. Gorb.
¿Qué pasa si está en la misma máquina? Significado: GETH se ejecuta en la misma máquina que la aplicación (explorador de bloques). No quiero que el puerto RPC esté disponible para 0.0.0.0 (pero quiero que el usuario final/navegador pueda consultarlo para el explorador de bloques) ¿hay alguna forma de evitar esto? ¿Apoderado? --- Parece que todos los exploradores que veo necesitan el RPC permitido para 0.0.0.0. Esto parece un diseño tonto. ¿Por qué no hacer que la aplicación en sí misma consulte localhost/guarde la información de RPC en una matriz/etc, y luego entregue la información al navegador? De todos modos, ¿hay alguna solución?
puede determinar qué funciones RPC están disponibles para los clientes con el indicador RPC. Y puede ser más restrictivo que 0.0.0.0 y permitirlo solo para 127.0.0.1

advertencia: no lo recomiendo

De forma predeterminada, el nodo solo aceptará conexiones de localhost . Puede cambiar esto para aceptar conexiones de cualquier persona con: --rpcaddr "0.0.0.0".

Tenga en cuenta que cada vez que se desbloquea una clave privada, cualquiera en Internet puede usar esta clave consultando su servidor rpc y enviando transacciones.

Sí, esa es la respuesta obvia. Pero no el que cualquiera debería usar a menos que haya un saldo de 0. Tengo una billetera que se desbloquea de vez en cuando. Sin mencionar que abrir cualquier RPC al mundo es solo una mala idea, independientemente...
¿Cómo manejan esto los nodos públicos de la red principal de Ethereum? ¿Aceptan conexiones por configuración --rpcaddr "0.0.0.0"? @Jeffrey W
--rpc --rpcport "8545" --rpcaddr "127.0.0.1" --rpccorsdomain "*"

--rpccorsdomain "*" permite que cualquier persona se conecte al nodo en --rpcport dado

¡Bienvenido a StackExchange! ¿Puede explicar qué está pasando aquí y qué significan los diferentes elementos? ¿Existe algún peligro potencial al permitir todos ( * )?
¿Por qué esto obtuvo tantos votos negativos? ¿Por qué esta no es una buena solución, alguien puede explicar por favor?
--rpccorsdomain value Comma separated list of domains from which to accept cross origin requests (browser enforced)- Navegador forzado significa que si un usuario realiza una solicitud sin un navegador , geth atenderá la solicitud ignorando el dominio. `
"¿Por qué esto obtuvo tantos votos negativos?" Porque está incompleto/erróneo. CORS es solo una parte. ¿Cómo se conectaría usted (conexiones externas) si se ejecuta solo en 127.0.0.1?
--rpccorsdomain "*"permite que cualquier persona se conecte a su nodo geth a través de rpc. En producción/uso público --rpccorsdomain "remoteUser@remotehost.remotedomain.tld"para vincular la conexión específicamente a su usuario remoto. En la práctica, geth debería estar escuchando únicamente a las conexiones locales.
permitir solicitudes CORS desde * (también conocido como ejecutar un nodo público) requiere cuidado y es una mala idea si tiene claves privadas legibles por ese nodo, incluso si están bloqueadas. Si está ejecutando una empresa de API como Infura y emite claves de API a sus usuarios para limitar la velocidad de sus solicitudes y evitar ataques DoS, entonces permitir el acceso a CORS es algo deseable.

Geth ha cambiado una vez más toda la sintaxis de la línea de comandos... así que este es un ejemplo de una configuración actual para permitir el acceso externo a su nodo (se necesitan medidas de seguridad adicionales dependiendo de su aplicación)

geth --http --http.addr "0.0.0.0" --http.corsdomain "*" --http.port "8545"

Más información aquí https://geth.ethereum.org/docs/rpc/server

¿Cómo puedo exponer el servidor RPC de Geth a conexiones externas?
RespuestasAquíPolítica de privacidad1y, 0v