Posts made by adam.ierymenko

@JaredBusch I see. At some point it might be worth looking into that DNSAgent program, since that might do what is needed. Or maybe we could develop/fork something like that to provide the kind of split brain DNS that Pertino apparently does/did.

@JaredBusch I used teh Google a little and found this open source project:

https://github.com/stackia/DNSAgent

Never used it but it looks promising. This could be installed on a client machine and then you could configure it to route DNS queries to different servers by regex of the DNS name.

Looks source only so you'd need to build. Has a .sln file.

@JaredBusch What's wrong with using the AD servers for all DNS? Other than reliability?

Note that ZT does not depend on DNS, so ZT will work if DNS is not up.

@JaredBusch Just checking in on this. So the final issue is: you folks want to consult the AD DNS server(s) only for names within AD, but want to consult the host's default regular DNS servers for the Internet. Is that correct?

@dafyre In the shorter term a more detailed HOWTO would probably be best. We can gear it to Debian since the Pi is Debian and makes a great bridge device, but you could also use a Debian VM or regular machine.

@dafyre I'll take a look, but in my experience bridging is always confusing to set up when you have any boundary between how things like IPs are allocated. One of the things on our to-do list is to ship a preconfigured Raspberry Pi config or image that does bridging easily.

@Dashrender That's not true. If a ZT device is on the same local network, then it will just have two ports that go to the same network. It would be like putting two NICs in the device and running two cables to the same switch. Confusing, but nothing "wrong" with that.

ZT emulates a smart Ethernet switch. Think of it the way you would think of a switch. An "active bridge" is a port set to permit bridging to another switch (some smart switches let you control that) while a regular ZeroTier endpoint is a port that only goes to a single device.

If you're thinking of it any differently you're over-thinking it. Pertino adds a whole ton of complexity by operating at L3 and none of that applies here. VPNs also add a lot of complexity by fragmenting the network with tunnels and such, and that's also irrelevant. Just imagine a switch with invisible wires going to it.

@scottalanmiller If you try AD feel free to update this thread and/or https://www.zerotier.com/community/topic/22/the-big-zerotier-active-directory-lan-virtualization-thread-retitled/2 -- would be helpful

@scottalanmiller You could also bridge it to a physical network if you have old boxes, printers, fax machines, etc. A Raspberry Pi makes a great bridge for $30.

@Dashrender Yeah, if we go full product on this we will want some kind of "migration assistant" and/or detailed HOWTO that doesn't suck.

We've got hardware to build a test lab, and are going to work on this pretty soon as well.

@JaredBusch Curious about the comment on "we don't want full mesh." Why? Is it just something you don't need or do you actively not want it?

Check out Gogs:

https://gogs.io

It's a single process Git server written in Go. We use it. Infinitely easier to deal with than GitLab, though it lacks some features.

We might be able to attend. Smaller conferences like this with knowledgeable audiences are usually more valuable than mega-events with tens of thousands of people.

@scottalanmiller We are also working on our enterprise offerings. See https://www.zerotier.com/product-ss.shtml -- we haven't made a big announcement quite yet but we are working with a few customers in the IoT and device space and this is also applicable to large enterprise SDN. We will offer live real-time monitoring of network quality of service and proactive investigation of problems as a service, and one of our engineers has a machine learning background so we are planning to leverage advanced quantitative analytics and deep learning against circuit test data eventually. We're also looking forward to pitting deep learning against harder scenarios in NAT traversal in the near-mid future.

Pricing on that page is still being refined. We might add something more fine grained in the future. Existing model is actually geared more toward IoT device vendors.

@scottalanmiller We hope to be the last wave. Please let us know about any issues you find and consider visiting https://www.zerotier.com/community/ and starting a thread about specific use cases you are investigating.

@FATeknollogee For us though, ZT always tends to focus on the future. We don't work too hard to support things that are too legacy, at least right now, because we are a very lean little startup. If we had more resources we might if there were a demonstrated market.

@Dashrender The cloud is the devil. Problem is that local servers are also the devil.

@wrx7m We've considered looking into this but (a) we don't use AD or Windows much at all, and (b) default gateway, while planned, is complex for us and is currently behind a few other more IoT/P2P focused efforts.

Default gateway is hard for ZT because it's p2p. Normal tunnel VPNs can do default gateway by simply excepting traffic from their upstream endpoint, but ZT has to except all its traffic to N random endpoints that are constantly changing. There are ways to do this by binding in the right way to the right interface, etc., but it involves OS-specific hacking and some refactoring. Can be done but hasn't been done yet.

As far as AD goes, our impression for a while has been that everything's moving to Microsoft's cloud AD service. As a result we find heroics to support legacy AD to be of debatable utility. It's something we plan to investigate once we have a bit more resources (which is hopefully soon) but for now the largest amount of paying customer attention we've received is from people who want P2P network overlays for IoT and distributed systems applications. Those don't care about either of these features but they do care a lot about reliability, monitoring, uptime, etc.

@dafyre Maybe proxy arp is actually in the way.

@dafyre It shouldn't really have to proxy arp in theory. The arps should cross the bridge and "just work." I could see proxy arp making things more reliable though.