-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pick different oC server hostname/IP depending on network (inside LAN vs on internet) #203
Comments
I have achieved what you require through an internal DNS server. I run an internal DNS server (bind) which hosts internal domain entries for my domain within the LAN. This way when my laptop connects to the LAN it will get the internal OC server address and when it is roaming outside my LAN it receives the public OC server address. This is my stop gap solution until ownCloud gets Lan sync. Hope it helps. |
Thanx to snowjet - this looks an excellent idea. It would be very effective if this internal DNS-Server could be run on the WAN/LAN gateway router which is 24/7 online anyway. I do have a linux based FritzBox and have looked up the corresponding forums where the recommended solution is to add the required mod using iptable commands. Are there other routers that might have a built-in feature as required? As more cloud based services are used and not all of them are expected to have an optimized WAN/local acccess support, this might be a nice feature for the WAN/LAN gateway devices. |
The internal DNS server method is certainly a good stopgap - however the "right" way to do it within OC would probably be to use the same or similar mechanism that #230 might use. Another possibility would be to have a list of alternative hostnames with priorities. This could even aid in future developments for multi-server cloud support. |
Hello, |
@etiess you don't have to change the dns, you just define a hostname, which happens to be the same as the dyndns host name whatever.whatever.com , so the router will not ask internet provider for the address but provides it itself. |
Thank you, I observed that indeed |
This is a must, speeds on LAN are really slow for what they could be, and that is a pain sometimes |
I configured this scenario last week and the results are very good. Our Owncloud server is hosted on our intranet. For this, you will need two IPs on the Owncloud server (local + internet), some static route rules configured and a local DNS server on the intranet. When our users are on the office, they will use the the intranet to sync. If they are outside, they will use the internet. Everything automatic and transparent for them. Works very well. |
If you do not have DNS domain registered, then this approach (named Split DNS) is not viable, unfortunately. You cannot simply add entry to /etc/hosts and override this setting with your home DNS, as /etc/hosts stuff is resolved first and your DNS setting is ignored. Also, this requires some technical skills from users and this would probably scare them away :) We discussed this matter at bug #2100 and the outcome is that perhaps the best and easiest (easy to implement in owncloud-client) option for now is to provide two IPs - one for server access on LAN, other being a public IP for accessing the server remotely. Fast LAN sync is probably be something else: in Dropbox, this means that clients sync themselves on LAN with minimum server syncing. But this got me thinking - what if client could auto-discover (by broadcasting) that the server (identified by UUID or some other pre-shared secret, perhaps a certificate?) is present on LAN? |
This would be a really useful feature |
👍 That would also adress bad resolution problems with some buggy home routers see owncloud/android#865 |
How does a second host name field not make the GUI more complex? :-) Also, what algorithm do you suggest? First look up the internal name, and if that fails, try the external one? What if the internal resolves by chance because there is another host behind it on another network? Many people will also not have HTTPS configured internally, so that would even open up an attack vector unless we force HTTPS in both cases if the external one is open. I'm not saying it's hard to implement, but it's difficult to get right without compromising security and overall stability. I'll gladly help if someone needs assistance implementing this feature, but I'm afraid it's unfortunately not very high on our to do list. As you can see with other features like SSL Client Certificates or the right click integration for file managers that will be part of 1.8, we're happy to work on patch creation with whoever is willing to step up. Please don't respond with 👍's though, they will not change our main priorities. Volunteering, and be it just by outlining the feature more specifically, would be very much appreciated. That said, those "buggy routers" are not buggy but simply have hair pin NAT disabled for efficiency. Most of them have an option that turns it on. Maybe those who do not feel comfortable writing code could contribute to our documentation? |
Sorry for apparently wrong usage of the thumbs up symbol, it seems to have a reserved usage on github that I did not know about. I didn't want to be impolite, I just meant it seems a good idea to me. May be I can propose some patch or improve documentation, but we first have to agree on what to do, right ? "outlining the feature more specifically" as you said. GUI thing clarification: I proposed keeping using one field, but allowing coma separated values. Not adding an extra field. This way OC could adress the issue some of us encounter without changing anything to the GUI of "lucky" users. Regarding security, specifying http://<ip_adress>/owncloud URLs si currently being allowed by the android app without any warning (I just checked). It works. It is risky. In any case, displaying a warning when SSL is not enabled would make sense. Talking about the doc, is there someting specific you want me to document ? Just give me a pointer and I can give it a try. |
Don't worry about it, you weren't really being rude. The problem wasn't your usage of the thumbs up symbol; the problem was the fact that you're basically adding noise to the issue. (Meaning, comments like "+1", "I'd really like this feature", etc. don't actually help move the issue forward, they just create more email.)
This isn't justification for implementing insecure behavior in the desktop client. It just means that someone should file a bug against the Android client. |
I agree with what others have said about DNS. I don't think it would be smart for owncloud to support this kind of functionality. It is a problem best solved at a lower layer. A long time ago, I disabled my router's dns/dhcp services and run dnsmasq on my home server instead. It resolves "example.com" and "www.example.com" as cnames pointing to "server.example.com" (which resolves to 192.168.1.xxx) Externally, Godaddy resolves "server.example.com" and "www.example.com" as cnames pointing to "example.com" (which resolves to my router's WAN IP). I did this so that file transfers over ssh could go at full speed when at home without me having to do anything special like switching ports or server names. When I setup owncloud years later, it just worked. It also works for FTP and plain old webDAV clients connecting to owncloud. |
Contrary opinion here. DNS is a good stopgap and I do think supporting this kind of functionality is a good idea. But I also don't think the concept here of having network-specific settings is the right way to go. Two things that could satisfy the needs of the OP:
|
Due to the aggressive DNS caching in Android, split-horizon DNS isn't really usable in this situation. I should know; I have an odd setup in which, due to the nature of macvtap, the global IP can't be reached from within the local network, as well as the reverse. So on my wireless network, the public IP address is useless. So I can't even reach my ownCloud server from my phone when it's connected via WLAN. |
Agree with @konaya, client also has overly aggressive DNS caching on OSX. When transitioning from internal LAN to WAN or when on WAN and transitioning to/from VPN the sync client tries to connect with previously cached IP address, even though the DNS name now resolves to a different address. Other apps on OSX, like Contacts and Calendar get the proper IP address immediately when switching networks. Generally takes quitting and restarting ownCoud sync to make it work. Client should either not cache IP address or flush cache when network connection changes. |
We could switch |
@konaya, for what it's worth, I recently learned that Google sets Android phones to always use their DNS servers, regardless of what your DHCP server tells your device to use. If you change this, it may fix your problem. |
I'm late to this discussion but has this already been implemented, if so how? I somehow converted my whole family and few friends to using owncloud hosted on my home server, all is great but we'd like to use the lan's speed when home and wan (internet) speed when out. |
Please run Here you can find more information: |
@michaelstingl So are you flat-out ignoring the fact that several people, including me, have reported that the aggressive DNS caching on Android and OSX effectively neuters that very solution, or are you just in the habit of not reading the comments on tickets before closing them? |
I follow this issue and #5506 for a long time and read it very carefully. But I also don't see this on the roadmap for the next time. If someone would like to contribute, we can open the issue anytime. I don't like the idea of building things because other things are broken. If the root issue is wrong DNS caching, it should be fixed first as @guruz mentioned in #203 (comment) . |
Yeah sure can do that on corporate network without issues when there's no split horizon DNS because .intra vs .extra in the URL is the standard ... |
Objective: enable fast access/sync while being inside local network and automatically use dyndns WAN sync while being abroad
Reference forum thread: viewtopic.php?f=14&t=3114&hilit=local+network
Ubiquitous Computing is one of the drivers for applications like OC. In combination with hosting an own OC server (e.g. on a NAS) one of the typical scenarios is that mobile users of this particular OC server may be inside of the high performance local network or while traveling having access through Internet WAN, which is expected to be somewhat slower.
A) While traveling or being abroad typically DNS/dyndns is used by the clients to access the hosted OC server e.g. on a NAS in the LAN
B) While being at home (inside the local network) it would be desirable to benefit from the faster local access instead of using the external DNS/dyndns IP address, which works (thanx to NAT lookback supported by most routers) but is somewhat slow compared with the supported local speed.
The Feature Request I have in mind is an additional connection priority option to access the local OC server directly from inside LAN if available, as well as to define the DNS/dyndns path to the OC server. So if the OC client is able to use the preferred and fast local path to the OC server it will use this connection instead of the DNS/dyndns one. Although while traveling, the same setup then determines that there is no direct path avail. and thus will use the dyndns connection.
Please let me know in case there are already ways implemented in OC providing this functionality, but keep in mind that mobile devices such as smart phone may have limited configuration possibilities at OS level. This is why I consider this to become a vaild feature request to be covered by the OC Clients instead of the OS level.
BTW: having looked to other cloud sync solutions - this is referred to as "fast LAN sync" feature. Hope this helps.
Looking forward to your comments and suggestions.
Merry Christmas
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: