search

syncloud / platform

Run popular services on your device with one click
https://syncloud.org
GNU General Public License v3.0
400 stars 40 forks source link

Hint about limits by IP versions incompatibility #408

Closed klmhsb42 closed 1 year ago

klmhsb42 commented 5 years ago

It would be nice to

cyberb commented 5 years ago

DNS has two types of adress records, A for ipv4 and AAAA for ipv6. You can have both, that is what we try to do in Syncloud DNS and you can do in your custom DNS.

In single stack network library queries corresponding record and try to access using the same ip version.

Dual stack queries both records and if you have both it will try according to library/OS preference. If you have one record then it is even easier.

Obviously browser in a single stack ipv6 in case AAAA is not available cannot redirect to a "wrong ip version" page as device does not have ipv6 and browser cannot access device's ipv4.

cyberb commented 5 years ago

If you mean redirect to.a page on syncloud.it, then this is possible, but I thought browsers can tell that themselves.

klmhsb42 commented 5 years ago

Yes, I meant redirect to a page on syncloud.it and you are right, the browser tells you. But it says only that there is no connection and that you have to contact the owner (which is actually the person itself) of the website. It doesn't tell you why there is no access and what you have to do to fix it. I think any hint for help makes the customer more satisfied.

klmhsb42 commented 5 years ago

notworking

Looks like this, which isn't helping.

cyberb commented 5 years ago

Yes, the problem is you will have to check the url on server side before allowing browser to go to it. Kind of what Google does to all the links you are opening on google.com.

klmhsb42 commented 4 years ago

Yes, you are right. Another related question: Could you offer a HTTPS 4to6 tunnel? For which the user

https://feste-ip.net/ offers port mapping and HTTPS proxy for ~13GBP per year, so I don’t know what a fair price would be for you You would have to decide if it's enough to buy one activation for all devices in one accout (which is the easiest to implement) or for each device. Also, I cannot use feste-ip.net now, because I would have to map every subdomain (for each app). Also, I don’t want to involve another company in my data. My ISP Vodafone would only offer IPv4 as business contract for about ~43GBP per month for lowest speed, which is a lot. Many Germans have DSlite with IPv6 only which is a really limiting thing. I think, if you would offer this option, I could convince more people to use their own server. The EU has presented IPv6 in 2003 https://ec.europa.eu/digital-single-market/en/news/european-commission-presents-ipv6-new-internet-protocol but I guess we have to wait till 2040. So, it would be worth to offer this.

klmhsb42 commented 4 years ago

You could use 6tunnel https://github.com/wojtekka/6tunnel

klmhsb42 commented 4 years ago

492

klmhsb42 commented 4 years ago

Yes, the problem is you will have to check the url on server side before allowing browser to go to it. Kind of what Google does to all the links you are opening on google.com.

Yes, it's probably not a good idea. You can just make a hint under "network" in the device UI, if the device is connected by IPv6, that you are not able to connect from everywhere. So that the users are not asking, what's wrong even with a correct device setup...

klmhsb42 commented 4 years ago

331

thomasschaeferm commented 4 years ago

I think a step in the right direction would be, to add some hints for the user about the limitations of IPv4 (shared addresses CGN, DS-lite) and the limitations of IPv6 (Availability). At moment it is only possible to switch between private and public IPv4 addresses in DNS. I miss the ability to switch off IPv4 in DNS. Reason: in combination of ds-lite (syncloud box) and external access via IPv6 - IPv4 in DNS is disturbing.

klmhsb42 commented 4 years ago

505

thomasschaeferm commented 4 years ago

I described some typical access methods with IPv4...IPv6. https://gist.github.com/thomasschaeferm/06b4ed2d450867fbbda2aea4a7f0cfd0 Together with my experience - what can by accessed remotely and what is usually blocked. Conclusion: Checks for Port 80/443 should be done via IPv4 and IPv6. In case of the IPv4 test succeeds - the A-record should published with the public IPv4-address. In case of the IPv6 test succeeds - the AAAA-record should be published with the IPv6-address. In case of both tests succeed - both records should be published. In case of the IPv6 test succeeds and the IPv4 test fails, only AAAA should be published. Also the A-record for the private IPv4 address should be withdrawn it that situation. In case of the IPv4 test succeeds and the IPv6 test fails, only A should be published. In case both tests fail - the user should be informed, that port forwarding for IPv4 or firewall settings for IPv6 may incorrect. If that doesn't help - the syncloud project may consider to provide relays services (also known as portmapper, reverse tunnel). The last one needs more infrastructure at the syncloud projects site and has a lot of disadvantages: longer ways through the network, not all apps are supported

klmhsb42 commented 4 years ago

Besides the tests at the platform, I would also offer some tests (at syncloud.org) before buying a device, like in the screenshot. It would just need some auto-test scripts, which I don't know... Screenshot

cyberb commented 4 years ago

Conclusion: Checks for Port 80/443 should be done via IPv4 and IPv6.

You are right currently incoming port checks are done only on IPv4 assuming that IPv6 does not have this whole external access mode (port mapping, NAT). Client: https://github.com/syncloud/platform/blob/master/src/syncloud_platform/insider/port_drill.py#L58

A/AAAA dns records are created independently if corresponding networks are available on the client. Client: https://github.com/syncloud/platform/blob/master/src/syncloud_platform/insider/redirect_service.py#L89 Server: https://github.com/syncloud/redirect/blob/master/redirect/dns.py#L62

@thomasschaeferm Apart from let's do all possible combinations correct, can you tell give an example of a real problem you are having right now because of the current setup?

This is issue is getting too broad so I am not sure what exactly we need to fix here.

klmhsb42 commented 4 years ago

This is issue is getting too broad so I am not sure what exactly we need to fix here.

Forget my comment here. #510

thomasschaeferm commented 4 years ago

IPv6 access needs to be checked. Despite there's no NAT, there are firewalls. They have to be opened or when impossible - IPv6 access should not be considered - no AAAA-records. The other thing in the current setup that's killing me: in case of no public IPv4 address, there should not be an a-record published, otherwise "happy eyeballs" makes the users gracy. (In my case ovpn does some failing connection attempts)

cyberb commented 4 years ago

IPv6 access needs to be checked. Despite there's no NAT, there are firewalls. They have to be opened or when impossible - IPv6 access should not be considered - no AAAA-records.

Ok this can be done: https://github.com/syncloud/platform/issues/511

The other thing in the current setup that's killing me: in case of no public IPv4 address, there should not be an a-record published, otherwise "happy eyeballs" makes the users gracy. (In my case ovpn does some failing connection attempts)

What happenes if you disable external access, do you get A record still but with local IP?

cyberb commented 1 year ago

Yoo many requests in one issue many of which are implemented, if not open a specific issue.