通過 web3 從 AWS 託管伺服器連接到遠端 Geth 客戶端需要修復

有一個普遍的問題影響著大多數嘗試使用遠端 Geth 實例初始化 AWS 託管伺服器的人。如果有文件來解決修復或至少是一種解決方法，那就太好了。

作為展示，我在使用 web3 從我的 AWS Express 伺服器連接到我的 ec2 託管的 Geth 節點時遇到問題。我認為一個關鍵的突破點是安全組設置。我在啟動時對 geth 選項給予了寬鬆的權限geth --rpc --rpcapi eth,web3,personal --fast --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*" --testnet。這應該沒問題，假設只有我的伺服器 IP 在 Geth 分配的安全組中被列入白名單。我使用來自本地電腦上 Express 伺服器的 web3 請求從我的 Geth 客戶端測試契約部署沒有問題（我的本地 IP 也被列入白名單）。

現在，假設連接到 Geth 的問題來自啟動時的 AWS Express 伺服器或來自 Geth 實例安全規則，這裡有一個潛在的安全問題列表，我有希望能解決這些問題。

特別是關於 Geth 客戶端的入口規則：

1. 使用 Express 伺服器的公共 IP 和埠 8545 的 TCP 是否足以連接？
2. 來自所有 IP 的埠 30303 上的 UDP 和 TCP 是否是必要的要求？（其他埠，如 30304/30301？論壇中關於舊埠的一些混淆。）
3. 是否需要打開 ICMP？（我懷疑 ping 是建立初始連接所必需的，但我不知道。）
4. Geth 啟動時是否需要 NAT 選項？
5. 此外，出口規則是完全開放的。

關於 AWS 託管的 Node/Express 伺服器：

1. 實例（或負載均衡器）是否必須允許來自 Geth 客戶端的消息？（以防萬一，我已將它們包含在我的規則中。）
2. 許多使用者在伺服器啟動時看到的錯誤以這些程式碼行開頭：

錯誤日誌-

{Error: EROFS: read-only file system, open '.node-xmlhttprequest-sync-1'
at Error (native)
at Object.fs.openSync (fs.js:641:18)
at Object.fs.writeFileSync (fs.js:1347:33)
at send (/var/task/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:477:10)
at HttpProvider.send (/var/task/node_modules/web3/lib/web3/httpprovider.js:91:13)
...
...}

也許某些權限需要在作業系統中進行修改。

這是我的標準 web3 配置：

var Web3 = require('web3');
var web3 = undefined;
var fs = require('fs');

if (typeof web3 !== 'undefined') {
 web3 = new Web3(web3.currentProvider);
} else {
 // set the provider you want from Web3.providers
 web3 = new Web3(new Web3.providers.HttpProvider("http://xx.xxx.xx.xxx:8545")); //Geth node
}

exports.accounts = web3.eth.accounts;

exports.myContract = web3.eth.contract(JSON.parse(fs.readFileSync('./compiled_contracts/myContract.abi', 'utf8')));
exports.myContractCompiled = "0x" + fs.readFileSync('./compiled_contracts/myContract.bin');

exports.web3 = web3;

我希望有人有一些清晰的見解可以在這里分享。

1. 使用 Express 伺服器的公共 IP 和埠 8545 的 TCP 是否足以連接？

是的，它不需要打開任何其他埠

2. 來自所有 IP 的埠 30303 上的 UDP 和 TCP 是否是必要的要求？（其他埠，如 30304/30301？論壇中關於舊埠的一些混淆。）

是的，據我所知，這些埠已不再使用。

3. 是否需要打開 ICMP？（我懷疑 ping 是建立初始連接所必需的，但我不知道。）

不，在這種情況下，握手被認為是埠 8545 上的 JSON-RPC

4. Geth 啟動時是否需要 NAT 選項？

沒有，我有一個伺服器正在執行，雖然不在 AWS 中，而且我沒有設置任何 NAT 選項來使其工作。

據我了解您的問題，它似乎與 AWS 和文件系統預設權限有關。

我從一個遭受同樣錯誤的人那裡發現了這個問題。他通過將工作目錄更改為節點腳本的開頭來整理它，/tmp如下所示：

process.chdir('/tmp'); 

https://nodejs.org/api/process.html#process_process_chdir_directory

引用自：https://ethereum.stackexchange.com/questions/44256