Port 8080 is an “adhoc” standard for secondary web server non-secure communication, and is presumably not particularly desirable since folks would need to specify the port.
Would it be legit to use my stock SSL based Apache server that listens on Port 443 to just redirect traffic addressed to ipfs.carpenter-farms.us to the gateway running on the IPFS server that is currently listening to port 8080? My mind gets confused when I try and figure out what the associated “Gateway” statement would then be? “Gateway”: “/ip4/0.0.0.0/tcp/443”? or port 8080? If the gateway is advertised publicly I’m guessing port 443 should be used, so that people get directed to my secure web server (which could then redirect internally). If that is the case, the IPFS server would also be listening on port 443, which is fine, since my firewall would prevent anybody other than an internal request from accessing that port. If the gateway is not advertised publicly then any old port would do (with 8080 making some sense).
I’m presuming we really ONLY want to allow secure external public access, beyond the fact that port 80 (as previously mentioned) is in use elsewhere.
Here is simple statement. IPFS does not include any traffic encryption provision out of the box. We have to provide that upfront to the ipfs. IPFS is designed to serve over port 8080. You can’t change that just by doing /ip4/0.0.0.0/tcp/443 (you can re-compile the code to serve over port 443 with extra encryption modules to do so). Yes, port 443 is de-facto standard for ssl traffic. But that has to be done (encrypt/decrypt process) by something locally. Say, openssl or modssl. You can’t just transmit plaintext data over port 443. All the browsers will deny the request for such traffic.
The fact is, data itself must be in encrypted format. Only having port 443 is not enough.
That helps… I was trying to figure out what specified port 8080 - now I know its hardcoded…
Do you have a recommended link to a simply nginx.conf for proxy setup? I found several searching, but they seemed overly complex. Just looking to have SSL over port 8080 (since on my firewall, port 80 and 443 are already in use).
In the meantime, I’ll check out cloudflare - thanks for the suggestion.
No no. Port is not hard coded. You can change the port by using /ip4/0.0.0.0/tcp/443. But I said so for encryption/decryption process, a ssl service
I am not good in coding/computers. But There is very sweet tool for this called Nginx Proxy Manager (link here). It is docker based solution. It has simple webUI to manage all the certificates, hosts, services and ports. You will easily get used to it.
That will be simplest and zero-cost option for you.
Wow… Cloudflare really was easy (and free). Awaiting nameserver changes to take affect now. Hoping this doesn’t break my mail services, but it shouldn’t.
I’d up your statement from “recommend” to “highly (like your crazy not too) recommend” (smile)
I verified all DNS records before I changed name services. Cloudflare got most of it correct, it just missed all TXT records for some reason.
Tested email from me.com (Apple) and gmail - seems to be working fine.
Can you take a look and see if ipfs.carpenter-farms.us now appears to be working via SSL? I can’t test that easily from within my network since I use an internal DNS.
This is strange. I made no changes at my firewall.
UptimeRobot (external monitoring tool) is fine with IPFS, but is claiming its lost access to scprime.carpenter-farms.us.
It took a bit for nslookup to find any of my nodes when using cloudflare as a server, even after I received notification and confirmed with whois, but all is working fine with that now. Hmmm, take that back. nslookup under linux, with cloudflare as the directed server, is showing me (2) ipv4 addresses and (2) ipv6 addresses - as I expect it should to hide my real address, but under windows I get a “no response from server”
Well… making some progress with cloudflare. For my scprime node, setting up a page rule to not cache, and turning https rewrite rules off, made uptimerobot’s port scan start functioning.
Unfortunately, doing the same for ipfs.carpenter-farms.us has not fixed uptimerobot, which means port access is still funked. e.g your cat picture at …/ipfs/… works fine locally, but fails when I try to access it via a VPN enabled web browser (oh, this appears to be an Opera issue - I can’t get it to view locally either on Opera, although it works fine locally on Firefox and Brave. Opera keeps dropping the port and rewriting it as a https request (my port 443 server is responding, not 8080). Weird, got Opera to stop doing the forced https when VPN is off, but it still does it when VPN is enabled. Oh well, there goes my ability to test from the outside world.
I’ll keep plugging away - I have some questions posted to the Cloudflare community page, hopefully they will be able to shed some light.
Should my “announce” be my real static IP “/ip4/216.146.251.8/tcp/4001” or the Cloudflair friendly “/dnsaddr/ipfs.carpenter-farms.us/tcp/4001” (if that is even legal syntax)?
Plz share dns records screenshot you added / auto added in Cloudflare dns setting.
Note one thing here… You must handle different subdomain requests internally by your own. Because all of them are pointing at your ip address which is same for all of them viz. 216.146.251.8
Before Cloudflare, what you were doing, you were using individual ports for different subdomains/apex domain (which is workable but not efficient). But now case is different. Cloudflare only knows your single ip address, at https which is port 443. Not other than this.
Yes, I only have a single static IP - my ISP is stingy with IPV4 addresses. I used Apache’s vhost ability to route different domains to various web service products.
All the vhost things worked prior to switching name services to Cloudflare, but now appear busted. That’s mostly for kevinsthoughts.com, another domain I host - so likely just going to revert that away from Cloudflare and see whats left.
