La pregunta es bastante simple, solo tengo una idea básica de RPC pero ninguna de IPC.
AFAIK, si me conecto al nodo ethereum a través de ipc, mi geth debería estar ejecutándose en la misma máquina. y si me conecto a través de RPC, mi geth podría ejecutarse en cualquier máquina remota. ¿Hay algo más que deba saber?
Además, si habilito RPC sobre geth, ¿significa esto que cualquiera puede conectarse a mi nodo o hay alguna forma en que puedo restringir algunas IP específicas que pueden conectarse a mi nodo? ¿Se --rpc addr
puede ayudar de alguna manera?
Las comunicaciones entre procesos o IPC generalmente funcionan en sus computadoras locales. En el espacio Ethereum, IPC normalmente implica la geth
creación de una tubería IPC (que está representada por el archivo $HOME/.ethereum/geth.ipc
) en el sistema de archivos local de su computadora.
Otros procesos en la misma computadora pueden usar el archivo IPC para crear comunicaciones bidireccionales con geth
.
RPC o llamadas de procedimiento remoto generalmente funcionan en diferentes computadoras. En el espacio Ethereum, RPC normalmente se refiere al punto final de RPC localhost:8545
o 127.0.0.1:8545
o 192.168.1.123:8545
.
Si usa localhost:8545
o 127.0.0.1:8545
para su punto final de RPC, otros procesos SOLO en la computadora local pueden comunicarse a través de este punto final de RPC, ya localhost
que 127.0.0.1
solo se puede acceder a ellos desde la computadora local.
Si usa una dirección IP no local como 192.168.1.123
, cualquier otra computadora en su red puede acceder a este punto final RPC.
Si su conexión a Internet reenvía el tráfico desde su dirección IP de Internet a la dirección IP de su computadora, 192.168.1.123
entonces cualquier computadora desde Internet puede acceder a su terminal RPC conectándose a {su dirección IP de Internet}:8545.
Como se documenta en ¿Cómo reducir las posibilidades de que su billetera Ethereum sea pirateada? , el usuario Patrick reenvió el tráfico de su dirección IP de Internet para el puerto 8545 a la dirección IP no local de su computadora (por ejemplo, 192.168.1.123 en lugar de 127.0.0.1). Cuando Patrick desbloqueó su cuenta para transferir algunos fondos, un atacante de Internet pudo ejecutar geth
comandos JSON-RPC para robar los éteres de Patrick.
Entonces, si habilita RPC over geth
, habilítelo usando --rpcaddr 127.0.0.1
si solo desea acceder a él desde su computadora local. Si lo habilita utilizando la dirección IP de su red (p. ej., 192.168.1.123), todas las computadoras de su red podrán acceder al geth
extremo RPC de . Si luego tiene su módem de Internet reenviando el tráfico para el puerto 8545 desde Internet al 192.168.1.123:8545 de su computadora, cualquier persona desde Internet podrá acceder al geth
extremo RPC de .
Por lo tanto, no especifique el --rpcaddr
parámetro y se establecerá de manera predeterminada en 127.0.0.1, al que solo se puede acceder desde su computadora local, y si desea acceder a RPC desde otras computadoras en su red local, asegúrese de que su conexión a Internet no reenvíe Internet. tráfico a su geth
máquina.
La mejor manera de verificar si su máquina local está escuchando comunicaciones fuera del espacio de su computadora local es realizar lo siguiente:
Iota:backup user$ netstat -an | grep LISTEN
tcp4 0 0 127.0.0.1.8545 *.* LISTEN
tcp46 0 0 *.30303 *.* LISTEN
tcp4 0 0 127.0.0.1.8181 *.* LISTEN
tcp4 0 0 127.0.0.1.6379 *.* LISTEN
En la tabla anterior, puede ver que los puertos 8545 (geth), 8181 (mi servidor web local) y 6379 (base de datos Redis NoSQL) solo son accesibles desde mi máquina local. Sin embargo, se puede acceder al puerto 30303 desde fuera de mi máquina local. Como mi enrutador ADSL reenvía el tráfico desde el puerto 30303 a mi computadora local, el mundo puede acceder a mi computadora local a través del puerto 30303.
IPC y RPC no son necesariamente lo mismo en términos de accesibilidad. Si tiene una conexión IPC accesible, los programas en su computadora local pueden tener acceso al programa que escucha en el archivo IPC. Pero su navegador web no tendrá acceso a este archivo ya que los navegadores web generalmente no se conectan a través de IPC.
Si tiene una conexión RPC accesible desde su máquina local, su navegador web que se ejecuta localmente en su máquina tendrá acceso a su conexión RPC. El parámetro --rpccorsdomain
está destinado a restringir el acceso desde su navegador web desde dominios distintos a los que especificó, pero cualquier programa (malicioso) que se ejecute en su computadora puede simplemente ignorar esta solicitud (es solo una solicitud educada y no una restricción) y acceder a su RPC puerto de todos modos.
--rpcaddr localhost
, entonces practicamente no hay diferencia entre IPC y RPC en este caso? bcoz en ambos casos, solo los procesos en mi máquina local pueden comunicarse con geth, por lo que ipc y rpc parecen ser iguales en este caso.--rpcaddr 127.0.0.1
, entonces exponer personal sobre rpc tampoco será vulnerable porque solo el proceso en mi máquina puede conectarse a geth. ¿O hay algún otro escenario que pasé por alto?--rpcaddr 127.0.0.1
y su computadora se ha visto comprometida, cualquier programa que se ejecute en su computadora puede acceder a este punto final. Pero esto es lo mismo sobre IPC. Entonces, si su computadora ha sido comprometida, IPC le dará el mismo acceso que RPC 127.0.0.1 y ambos serán vulnerables. Desafortunadamente, la seguridad es difícil.geth attach
alguna forma de IPC?geth.ipc
que no es un archivo permanente sino un socket y no existe como archivo. Al menos no en mi sistema de archivos macOS. He buscado en todas partes /T/geth.ipc
, /chaindata/geth.ipc
etc., incluidos los archivos invisibles y no existe. Actualmente estoy ejecutando geth. ¿Alguien puede confirmar que este archivo en realidad no reside en el sistema de archivos?geth.exe attach ipc:\\.\pipe\geth.ipc
No sé qué es $HOME/.ethereum/geth.ipc
en realidad, probablemente esté en bash, en Linux (¿por qué almacenar datos públicos de blockchain en el directorio /home/user/ de alguien? stackoverflow.com /questions/1510104/… ) o tal vez se puede definir en otro lugar?
Igor Nemo