Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Running js-ipfs behind a proxy #1865

Closed
JGAntunes opened this issue Feb 6, 2019 · 5 comments
Closed

Running js-ipfs behind a proxy #1865

JGAntunes opened this issue Feb 6, 2019 · 5 comments
Labels
kind/support A question or request for support

Comments

@JGAntunes
Copy link
Member

Hey there! 👋

tl;dr; Is there a way for a node to "advertise" one swarm address without binding to it?

I've been looking into running some tests with multiple IPFS nodes running behind a TCP proxy. I'm using a bootstrap discovery method with 3 initial nodes deployed followed by another set of them. The config I'm using is something like this:

{
    "Addresses": {
        "Swarm": [
            "/ip4/127.0.0.1/tcp/4002"
        ],
        "API": "/ip4/172.17.0.5/tcp/5002",
(...)

And the TCP proxy running at port 8002 forwarding traffic to the ipfs swarm address.

I came to find however that given the peer doesn't know its own address, other peers end up with peer lists like this (notice the two peers with a 127.0.0.1 address):

kubectl exec -it node-3-ipfs-testbed-bddb7b794-rftkz --container=js-ipfs -- jsipfs swarm peers
/ip4/127.0.0.1/tcp/4002/ipfs/QmSFkkfUZU3zZX3uEXm8FxJMpMGnU1qejRQUiy6UzyDJWk
/ip4/127.0.0.1/tcp/4002/ipfs/QmfQUpk41XPjQ7AehCSbRi7CCRB8LERB1pNxQFHMk9JiUY
/dns4/node-2-ipfs-testbed/tcp/8002/ipfs/QmcTaFLT2vziRVSN8nnd3HRhZxXbo8MG1ghRc65qHCkZ8v
/dns4/node-1-ipfs-testbed/tcp/8002/ipfs/QmaZfXvwHvNk3nrJyrgPWDi1LK6bPDPr5JSXXWV88Hykts

If I try to use the proxy address in the swarm config it will fail because the node tries to bind to it. So I guess what I need is some way for the peer to list an address without binding to it, is this possible? I was looking around in libp2p for something that would allow this behaviour but to no luck 😞 do any of you know a way around this?

@JGAntunes JGAntunes added the kind/support A question or request for support label Feb 6, 2019
@alanshaw
Copy link
Member

alanshaw commented Feb 6, 2019

Ha, great question. Can we use a circuit address for this @jacobheun / @vasco-santos ?

@alanshaw alanshaw added the status/ready Ready to be worked label Feb 6, 2019
@JGAntunes
Copy link
Member Author

Meanwhile kept searching and found this - https://github.com/multiformats/js-multiaddr/blob/master/src/index.js#L182 - I wonder if this is a case were address encapsulation would be useful? 🤔

@jacobheun
Copy link
Contributor

This is where libp2p/js-libp2p#202 would be very useful. It would provide the ability to set the listen/announce/no announce addresses without messing with the addresses after startup.

@JGAntunes encapsulation/decapsulation is likely the best workaround without adding the config changes to libp2p, which would be the best option.

The encapsulation workaround will require some post processing on the peerInfo multiaddrs after libp2p has started. We currently do something similar on boot for the transport listeners in libp2p-switch, https://github.com/libp2p/js-libp2p-switch/blob/v0.41.5/src/transport.js#L171. You could do the replace with the encapsulated address, which would be your proxy address /dns4/node-2-ipfs-testbed/tcp/8002 and the ipfs address of the node /ipfs/Qm. This should also allow you to prevent advertising the local address. An issue you might hit here is advertising addresses before you've updated them.

@JGAntunes
Copy link
Member Author

JGAntunes commented Feb 6, 2019

@jacobheun yes that would be perfect! Thanks for pointing that out 👍 I don't have much free time on my hands but maybe I can help out with that (moving this discussion to the issue).

Meanwhile I'll probably take your advice with the second approach so that I can get quickly unblocked. Thanks again for all the pointers 🙏

@JGAntunes
Copy link
Member Author

And I think it's ok to close this 👍 thank you @jacobheun and @alanshaw.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/support A question or request for support
Projects
None yet
Development

No branches or pull requests

3 participants