June 25, 20206 yr Hi people. I have a crazy-jank idea that involves network configuration, multiple docker containers, VMs, a "slave server", and a bunch of nonsense. Hence why it's ending up in "General", as it's a compilation of everything, + my love of stupidity sprinkled on it, with lamb sauce. My actual definite plan isn't actually exactly the one I'm going to discuss, but if this "theory" plan works, it would actually fulfill all my knowledge needs for my actual plans (which involve more stuff on top of it all, but not influencing directly the topic). It "CAN" work, mostly, some things I'm not sure about, and what I'm seeking here is some clever or weird input to help me reflect on it all, and find clues before committing to this madness. I know it would be easier if I had a PFsense box, but I don't, and even if I commit to putting one together (which isn't in my budget for now anyway), I could still use and re-purpose the teachings of trying to do this setup for later ( & for other dumb shit I wanna do). Here is the idea: 2 Servers - one running unraid. Let's call it Lime - one running XenCitrix. Let's call it Lemon (yeah, you're entitled to hate me already) On the Lime server, we have a letsencrypt docker running on a separate docker network, with a whateverwebservice, say owncloud, on the same network, calling it proxynet. Theoricaly, using a docker which has a vpn client integrated, like nzbtget-vpn, and setting letsencrypt and owncloud's network from "proxynet" to "None", and adding the extra parameter '--net=container:nzbtget-vpn' would route all their traffic through the vpn tunnel of the vpn container. If using in that case not a public VPN, but a VPS running pritunl, with a fixed IP I can attached a domain to, it would let me hide my true IP while still home-hosting "public" stuff, and basically not have to touch letsencrypt's nor owncloud's configuration, and have my services running behind an hosting company's anti-DDOS solution. Just editing their templates a bit to regain the "WebUI" button and adding their ports to the nzbtget-vpn container should make it all transparently behave like before, but with nice VPN protection. Nice, good start, in theory. Question 1: Since I don't actually have a VPS atm, I can't test right now, but if anyone knows more I depth about it, would letsencrypt still do its job properly with such a wonky network config? In my mind it should, but I'm not sure it will, if anyone tested it or also think it has no reason to not work, or instead reasons to fail, and way, I'ld gladly hear it. Question 2: I know there is an OpenVPN client plugin, but I find it kinda limited (or I missed something), and I'm not sure we can be as selective as that with it. Is this^ possible with the plugin? If it is, will it hold too in the next use cases I'm about to break to you all? Now, down the rabbit hole even more: The 'meaningful' network setup on the physical side would be: -Lime has its normal NIC eth0, an IP on the network, everything's great and dandy. -Lime also have a eth1, which is plugged directly into Lemon's eth1. Static IP set up on both sides, Lemon and Lime can talk directly. The interest I have in XenCitrix is their workspace virtualized desktops and apps (I have people to help run shit remotely on their crappy devices) Question 3: Do I have a way to bind Lime's eth1 to the nzbtget-vpn docker, to route the Lemon's citrix storefront through the VPN tunnel? If yes, how, or please help me find the block of documentation I need to figure it out! And now, going even more stupid: Lemon is a compute-sufficient server, but its IO is lacking. I has a e3-1270 v2, bunch of ram, a garbage-picked GTX745 to leverage to virtual desktops, but it's stuck to sata2, and has really limited PCIe expansion (fully populated) Lime, our unraid box, is my main storage. It has a decent array with disks that each can read at 180-200mBps, no controller bottleneck, and a raid1 SSD cache that performs almost above their specs, at 560mBps reads each, with nice IOPS, on a separate controller from the array. Lime and Lemon can be linked with up to a 2gbps link, thanks to link binding, or might throw in a spare 10gbps SFP+ card on both Lime and Lemon. (Lime is already sharing a 20gbps link with my main workstation for heavy projects) Idealy, Lemon would pull all its virtualization data from Lime's array and cache through a dedicated share. Yes, Lemon's Vdisks would be stored onto Lime, but not just that. Lemon's Citrix Virtualized Desktop, the one using the GPU btw, would need to have in-VM access to said share, because it's 'pulled' and used through symbolic links in the guest OS. (aka: part of the VM windows user folder, along with the working-project folder would actually not be within the Vdisk on the array, but directly on the array). Lime will also have a VM running in this theorical setup, that is to be remotely accessed through parsecs, and be running on nzbtget-vpn's network, with the same symlink "redirection" as the Citrix VM on Lemon) Question 4: VMs in unraid usually see the host's network shares. Lemon will totally see Lime's shares. Is there a way to configure Samba, or do whatever dark magic, to stop a share from showing itself on some network and or NIC, as to not let Lemon's virtualized desktop or the unraid VM see more shares than they need to, but still can access "the one" they need to access. Aka: selective by-network/by-nic samba sharing. I know that's a big quiz of stupidly specific and 'why are you even bothering with that, build a pfsense box or VM already you doofus' would be an accurate remark, but if you will, I would really like to hear what you people could tell in regard of the 4 request-of-input I made. TLDR: this post is hardly summarizable by something else than "I'm stupid, my setup idea is stupid, and my questions are... guess what"
Archived
This topic is now archived and is closed to further replies.