WEBVTT 00:00.000 --> 00:14.320 Okay. Hello everyone. Welcome. My name is Taiwan from Taiwan and I'm here to take 00:14.320 --> 00:20.160 for the 4th turn 26 to tell about the stem mesh, which is my side project. I created it. 00:20.160 --> 00:27.240 This is my presentation about the stem mesh, go build in the build build, work out mesh 00:27.320 --> 00:35.400 with us and the self-host infrastructures. So, a quick introduction about me. I am the 00:35.400 --> 00:42.760 cloud and there were social architects for 70 years old and I have several speakers experience 00:42.760 --> 00:51.080 theirs and there's another project called EZIO if you have an interest in about me. We have 00:51.080 --> 00:57.560 the general what is the stem mesh go and what does the mesh go try to solve and also why we 00:57.560 --> 01:03.160 describe the stem implementations in the different platform for example, Linux, PreviousD 01:03.160 --> 01:09.000 and also the how it works with the wire guard canal module directly and the block is 01:09.000 --> 01:15.240 started so that is we doubt any self-hosting service and we can minimize the binary size 01:15.720 --> 01:22.600 for the open-doority or embedded router mobile router or something. We will explain the next 01:22.600 --> 01:32.120 part for the stem mesh go. Before we start, I will expand you already know something basic about 01:32.120 --> 01:41.320 the work out and step-of-firework, different types of the NETE, SIGNAT and EFI, FN, also the 01:41.320 --> 01:50.920 BASAX down ProCo and also the UTP whole-pound concept. Okay so what is the damage go? This is 01:50.920 --> 01:58.680 the key update, this is the weather helper to help those device are behind the fireworks or the 01:58.680 --> 02:04.760 NETE's and we want to try to make the true peer experience directly without any 02:04.760 --> 02:12.920 release over VBN hub or when you think and another we want to report is we don't need any self-host 02:12.920 --> 02:22.360 NETE's if we have when not just a VBN hub, right? So then we do this as a cross-platform and cross-architectures 02:22.360 --> 02:31.080 support in M.D. 64, M.C.T.4 where MAPs were Linux and BST and MegaOS as well and this is inspired by 02:31.080 --> 02:38.040 very long-goed post-dense talk which called WireGopioch Peers thanks to the post-dense and says him. 02:38.760 --> 02:45.080 And this is VBN hub V2 or later's license and you can get the projects under the link with 02:45.080 --> 02:54.360 GENICURACOS. Okay so what we want to try to solve? Let me explain WireGopioch to be still 02:54.360 --> 03:01.640 need the proxy to traffic, to proxy the traffic, to do the stops, temporarily, not currently. 03:02.680 --> 03:08.680 Other solutions sometimes will need still NETE's self-hosting service, for example if you want to 03:08.680 --> 03:14.040 fully control your test scale, you will need to host your test scale server for the coordinator 03:14.040 --> 03:20.920 and central servers. We don't want to fork in, we're embedded WireGopioch because that will be a 03:20.920 --> 03:28.280 mess if WireGopioch is updating or there's something breaking when WireGopioch is 03:28.280 --> 03:34.920 upgrade or something. So we want to try to share the same port. When WireGopioch is in 03:34.920 --> 03:42.440 WireGopioch module, it sends to you and we can direct reuse it. Okay so let me 03:42.520 --> 03:49.880 turns that is WireGopioch peer to approach. You can see there's a proxy there and there will 03:49.880 --> 03:56.680 list them down the property and the proxy and WireGopioch will have layers on this interface 03:56.680 --> 04:04.840 and this apport which you can call port 8. The proxy will need to do the stop first and do the 04:04.840 --> 04:11.320 set information into the information is changed central or something and proxy will need to 04:11.320 --> 04:19.000 config the WireGopioch module to connect to itself. So the proxy team will need to proxy the 04:19.000 --> 04:25.800 traffic and do the stop as well and do lots of things on there. So that means your WireGopioch 04:25.800 --> 04:32.040 instance is not the right connect to your remote peers. This is the basic concept. 04:32.360 --> 04:41.080 Okay so how do we try to solve this? We want to remove the proxy. We want to reuse the 04:41.080 --> 04:48.840 sample as the WireGopioch directly listens to it and so we can connect WireGopioch directly 04:48.840 --> 04:55.480 to the remote peer without any proxy involved. We don't want to have the several hosting 04:55.480 --> 05:00.680 server because if we have for example we have the POPPIP and we can just easy to 05:00.680 --> 05:08.280 head on the VPN hub or turn on a head scale to do the connect servers. We try not to do that 05:08.840 --> 05:15.320 because maybe we don't have and we don't have need to. Okay so so we want to use the 05:15.320 --> 05:22.200 proxy instance to replace the self hosting instance and we don't want to forget and 05:22.200 --> 05:26.760 badger the WireGopioch so we don't want to patch so that means even WireGopioch is update, 05:26.760 --> 05:33.560 WireGopioch is update, everything wants to be fine. Okay so we start about the 05:33.560 --> 05:38.520 our strong implementation details here so we want to reuse the WireGopioch for the 05:38.520 --> 05:45.560 start. So we want to ensure the public information IPN Pro which is debugger from the start 05:45.560 --> 05:55.000 is the same as WireGopioch. I'm sorry. So our approach will be like this. The 05:55.080 --> 06:02.440 Stomach go under there is only to the stop and overthrow the sample as a poor eight and we 06:02.440 --> 06:09.000 will only control the WireGopioch so we will set in on the endpoint there and we don't do any 06:09.640 --> 06:15.400 proxy traffic so everything in the traffic well go through the WireGopioch directly 06:15.400 --> 06:24.040 without our involved. Okay so how to implement less to reuse because you can not 06:24.120 --> 06:29.720 descend to the understandport in the linear spiteful. So we use the growth circuit. So we 06:29.720 --> 06:37.400 will need to use the growth circuit with the BPS to construct the UTPs, Stomach informations. 06:38.920 --> 06:45.400 By myself so I can send out to the Stomach circuit and get received the growth circuit from 06:46.360 --> 06:53.080 Stomach circuit to get the Stomach response and get all public informations and all the things 06:53.160 --> 07:00.520 well go through the list growth circuit to make sure other things all the pages well go through 07:00.520 --> 07:09.880 the WireGopioch directly. So we use the CBBF and let's unlock the linear. 07:09.880 --> 07:15.480 Previously and Mac always had a different approach about this because there are 07:15.480 --> 07:21.800 limitations the growth circuit cannot receive anything. So you can send something out from the 07:21.960 --> 07:27.640 circuit but you can not receive anything from them. So we need to use another things is BBF 07:27.640 --> 07:35.720 device to do the capture to listen on less interface with the filter to make sure we can grab 07:35.720 --> 07:41.800 the Stomach response back to with the Stomach port and all the traffic will go through the 07:41.800 --> 07:49.000 WireGopioch directly without our import. Because we need to monitoring all the interface and 07:49.160 --> 07:54.520 FBS is sometimes we'll have the firework and do the redirect rate with some things. 07:54.520 --> 07:59.880 So we will need to monitor all interface to make sure we will capture the correct 07:59.880 --> 08:05.160 or make sure we can capture all the Stomach response to make sure we get a correct one. 08:09.000 --> 08:14.680 Okay so how wait what why it can work with the remote module? 08:14.680 --> 08:21.080 Direct because we are doing the cyclostom. We didn't patch and these things inside the 08:21.080 --> 08:27.720 record. We don't do that. So we can just use the radar on the OS feature to hijack the 08:27.720 --> 08:33.320 send USB port to do the Stomach response as request and get the response from them or 08:33.320 --> 08:40.280 other place for example the BBF device. We only do the control plane only. So when we get the 08:40.280 --> 08:48.120 Stomach, we get information from the other peers. We will only configure WireGopioch using the 08:48.120 --> 08:55.640 WireGopioch control. We will not produce any traffic. So that means it can because I only use 08:55.640 --> 09:02.440 the WireGopioch control. So that means if the underlay is WireGopioch control, let's open it for me 09:02.520 --> 09:10.440 because I just have a side card controller to control it. Okay so how do we do the peer 09:10.440 --> 09:16.440 info the exchange? Because the Stom is the one way I can only get the information by myself 09:17.240 --> 09:23.720 and need to send out to the remote set another important. So the missing part is we don't have 09:23.880 --> 09:31.160 a change way to do this. Why not just sell posts? A platform to exchange because we 09:32.280 --> 09:38.280 can just put it on my service and other points and grab information from the service. 09:39.000 --> 09:44.920 So that means that you will need the public IP or any public service to host the VPN. If you 09:44.920 --> 09:51.480 have the public IP, why not just work on VPN card or something to do the relay, it is really simple, 09:51.480 --> 09:57.880 land this way, right? So we don't have, so we need to do something without the self-hosted. 10:00.840 --> 10:05.240 Okay so let me introduce the Parkinson's with all the self-hosting service. 10:06.040 --> 10:14.920 We try to rely on the generic backend storage, which is maybe a safe thing, public key value service, 10:14.920 --> 10:22.520 like CloudVertilX, TXT, or something, any things. We need security exchange. So we will 10:22.520 --> 10:29.640 increase by the self-host, which is reuse the workarchy directly. We will have the workarchy 10:29.640 --> 10:36.120 pairs wide, we have the rare key pairs, we have our key pairs. So we can increase by loss key pairs directly. 10:37.640 --> 10:44.680 We can directly connect to any key value storage can be this model. So if land model is 10:44.680 --> 10:52.120 maybe IPFS or something like the CloudVertilXT, because it will be a key and value models, 10:52.120 --> 10:58.040 and we can try to implement the plugin to fit the storage solutions here. 10:59.560 --> 11:05.480 Also let's introduce the key about it. So if we have the local public key and we want to send to 11:05.480 --> 11:11.080 the remote public key about our information, we will have conquered our keys, ways of the 11:11.080 --> 11:16.600 staircase, and do the show on to make sure that no one will get our public key, because the 11:16.600 --> 11:23.640 public key here is identify IDs, so we don't want anyone else, so we use hash to make sure 11:23.640 --> 11:31.160 this is unique, and no one will know that, and convert into the hack stream, because not own the 11:31.160 --> 11:37.400 key value storage can put a non-printable character with some things. 11:38.360 --> 11:45.800 And above the video, we will have a pleasant file, justzons, ways of IPv4 entry, and the IPv6 11:45.800 --> 11:51.240 entries, which means if you would retrieve your public info from the store, you will get 11:51.240 --> 11:58.200 IPv4, and we will do the IPv6 as well, to make sure we can get all of them as green for eye, 11:58.680 --> 12:07.880 and tribes, and hacks, and put this into the storage, and the outside can grab the information 12:07.880 --> 12:12.920 and deep-scrow it to get the remote endpoint information to connect, right? 12:17.640 --> 12:23.240 Okay, so the API will look at this. This is simple key, is a hack stream value, is a hack string, 12:23.240 --> 12:29.720 and we have the plugin that sets that your key and value, and what we want to get from the 12:29.720 --> 12:34.760 other size, or we will plug it, and get information from the other size, right? 12:35.480 --> 12:41.720 If you need, maybe you can visualize the hack stream to the other format to fit your 12:41.720 --> 12:47.640 plug-in system, because sometimes hacks is not too long, or you need to compare it with something, 12:47.640 --> 12:54.200 so it is our APIs, and you can do it inside your plug-in to do another kind of 12:54.200 --> 13:05.640 serializing and results. Okay, so this is an example for the conferred DNS, also we 13:05.640 --> 13:11.640 reuse the DNS. The TX is very rare, as the key value storage, because TXKVL has the key, 13:11.640 --> 13:17.640 which is a domain name, and the value, which is a content of the TXT, we only need to make sure 13:17.640 --> 13:25.080 we have only one entry inside that with LATOMEN, with a LATXT record, so we can do this as 13:25.080 --> 13:33.160 7 is onto the conferred or any other DNS, because the TXCV record is a standard features, right? 13:33.160 --> 13:41.000 So, you can use the other pocket, other locations, or something to set up the 13:41.000 --> 13:47.880 pocket data, to store you as a just make sure your two peers can have the same SS to grab, 13:47.880 --> 13:55.560 like information from the same storage. So, you can still keep up in, so I put the key in the 13:55.560 --> 14:02.360 stop domain interface, and I put the value for the TXT inside our context, so you have the 14:02.680 --> 14:08.840 example picture that is really long name, with really long contests, and DNS only, 14:08.840 --> 14:14.440 and TXTL is also, because I grabbed from the cloud fair API, so I didn't do any DNS 14:14.440 --> 14:20.200 query or something, so that TXTL is not really important, because I will always get the update once. 14:20.440 --> 14:32.680 Okay, okay, and because I tried to do this to, in the embedded system, for example, 14:32.680 --> 14:39.720 do know the it will be creating a draw tool, which is very small, and a miss pass router, 14:39.720 --> 14:45.080 and which way is the wire guard support there, and I tried to install out it, but the 14:46.040 --> 14:52.200 splash is a little bit smaller than I sped, so I need to compress it, where we can 14:52.200 --> 14:57.880 straight the binary size, to make sure we can put it into the maybe mobile router, 14:57.880 --> 15:05.560 LT router, or any industrial grade router to let you want to connect to, you want to direct connect to it. 15:06.280 --> 15:13.320 And the memory footprint is low still, we only use the TXTMPs of the RAM, because the 15:13.480 --> 15:22.440 UPAX compression, if you don't do the UPAX compression, there was much lower than 20 MPs, 15:23.240 --> 15:30.520 and this is good for embedded system, it's simple, it's open WRT, or add router, or anything, 15:33.000 --> 15:40.120 okay, and the next for the damage go, we are testing the four IPv6 support right now, because 15:40.120 --> 15:48.600 nowadays, IPv6 is more use-dege and for the IPv4, but we still need to bypass the stay-for-fire 15:48.600 --> 15:55.960 worst support, we still need to, so we are testing the IPv6 support, and another thing is we are trying to 15:55.960 --> 16:01.720 do a pin module detection right now, we are using a fixed interval for example, five minutes, 16:01.720 --> 16:09.160 we'll do the start again, and query the information of the remote endpoint and set up the local 16:09.240 --> 16:14.920 endpoint for that, and we are trying to do the pin module detection, if the pin fail, 16:14.920 --> 16:21.240 we will try to restart whole process directly, so that means we don't need to work five minutes, 16:21.240 --> 16:27.720 we'll fix intervals, we can do the small reconnaissance, and another way is we can do the 16:27.720 --> 16:36.280 embed hoppids, which means because we can use a Roussakid to send from the workout, dis-enport to another 16:36.280 --> 16:45.960 side to do the hoppids, and we can grab the hoppids to make sure if they're still alive in the 16:45.960 --> 16:55.160 other side, because there will be a little bit kind of the BPF too, I'm sorry, BFD does, I'm sorry, 16:55.160 --> 17:03.240 so if I didn't receive any hoppids, I can assign the other side stat, or the tunnel is disconnection, 17:03.240 --> 17:09.320 so I need to do the hoppids again, to make sure I can reconnect to the other side, so at that 17:09.320 --> 17:16.120 moment we can disable the fixed interval, or we can send the fixed interval to very, very long, 17:16.120 --> 17:21.320 to make sure we can do maybe one hour at a time, and other time we will check if it is 17:21.320 --> 17:28.440 decongation and do the smart reconnaissance, and another thing is we want to test with 17:28.760 --> 17:35.080 satellite networks, which is installing one web or anything, but this is not printing, 17:35.080 --> 17:42.280 and it's taking for us for right now, starting is not useful in Taiwan, so we may have some, 17:42.280 --> 17:49.640 if you are willing to test, I'm happy to give you some guide for testing the StarMeshGo 17:49.640 --> 17:58.040 within the satellite networks, and please quick introduction, we are close-up from Taiwan, 17:58.040 --> 18:02.440 and we are the biggest open source conference in HR Corps, host with the Wubanko, HR, 18:03.160 --> 18:09.480 we will hold events in August to this year with wallwars, speakers, and attendees, 18:09.480 --> 18:17.640 you can scan the QR code with just search open, close-up, okay, if you have any question 18:17.640 --> 18:23.160 discussion and it's that you can open an issue in the GitHub, or can't admit the link in the 18:23.160 --> 18:36.040 rear message to me, okay, thank you. Great talk. Yeah, we do have time for some questions, 18:36.040 --> 18:47.880 so we'll run around with the mic. Thank you for your talk, it was very interesting. 18:48.360 --> 18:55.160 I'm curious about the warning formation you put as hash when you do peer discovery, 18:55.880 --> 19:02.920 using a call-flare for example, or other key value source. Currently, I use the call-flare 19:02.920 --> 19:10.040 directly, and I didn't do any other plugins, but our module can support others. Yeah, but more 19:10.040 --> 19:17.080 curious on what is the information, what is the key value there? Okay, the key value is about this, 19:17.080 --> 19:25.160 so there will be my information to send to the other side, so you will store this inside the 19:25.160 --> 19:31.800 call-flare TSE contents. Yeah, this is the external information, right, that the capture. Yeah, and so 19:31.880 --> 19:39.640 that meant is local is center to the destination, so if you write the results or you have another 19:39.640 --> 19:48.120 remote endpoint to want to send to me, peer is a remote endpoint, here is me, okay, so I can 19:48.120 --> 19:56.040 determine which message I should get because the final one is the destination, so I only need to grab 19:56.040 --> 20:03.960 this, okay, and I don't do the key is changed already, you need to know the analysis of the 20:03.960 --> 20:11.160 public key to make sure I can grab the source and destination to calculate the shot and get from the 20:11.240 --> 20:21.800 call-flare or the progress, is that yeah, thank you. Any other questions? Sure, hands, 20:22.520 --> 20:37.080 okay, one up front, excuse me. Hi, thank you for the talk, I just want to know the just to 20:37.080 --> 20:44.520 that I understand, one of your goals is or is not to do whole punching through not, like this 20:44.520 --> 20:52.520 done mesh go do that, or does it just to share information about IP addresses and ports between 20:52.520 --> 20:59.640 the two peers. So that makes sense. I only want to try to come at these two peers, and all the 20:59.640 --> 21:07.400 pause I will not really care. For example, if you set up your route here and there, and you can 21:08.040 --> 21:14.520 maybe go through the default route to another peer to go to outside to the internet, and we don't 21:14.520 --> 21:19.800 care about that. We only care if we can connect to the two-wire-guard device behind the net, 21:20.680 --> 21:26.840 and because once it's connected, we can consider that it's a cable, so we can do maybe BGP 21:26.920 --> 21:33.800 Dominican route in between two, and we can do anything about that, so you can set up your route 21:33.800 --> 21:39.960 on your demand, or you can do some setting on the Dominican route to learn from the HR other 21:39.960 --> 21:49.080 was on the six. Is that answer your question? Yes. Okay, and here is there, and questions, I think. 21:53.000 --> 22:04.040 Okay, one more. Hi, I wonder, once you have a communication established, could you put 22:05.000 --> 22:14.120 new learning information inside the heartbeaked? Yes, that is possible, but there will be a 22:14.120 --> 22:21.880 future plan, or something, because if you want to put more things inside the Rosarket, that means you 22:21.880 --> 22:29.400 will have more traffic through the traffic, and because of the Rosarket behavior, so the 22:29.560 --> 22:34.760 response will also send to the wire-guard demands. So that means that it's too much information, 22:34.760 --> 22:40.440 they will disperse the wire-guard cannon module to describe the traffic, so that means the 22:40.440 --> 22:46.600 performance a little bit lower if you put too much information there. Thank you. Thank you.