NixOS Networking | 902 Members | |
| Declaratively manage your switching, routing, wireless, tunneling and more. | 263 Servers |
| Sender | Message | Time |
|---|---|---|
| 29 May 2021 | ||
hmm, it doesn't seem to work in bash either, even though umask in both fish and bash confirms it's been set to 0077 after umask 077 | 19:16:54 | |
| ahh, I think it was because I had already created the file with different permissions and tried to overwrite without removing. works after removing | 19:18:00 | |
| I think some shells (all?) truncate the file if it already exists prior to writing. | 19:18:59 | |
| yeah, but the truncated empty file will still exist with preexisting perms | 19:22:18 | |
| I usually have this in every shell config:
I never want to truncate files silently if they already exist. | 19:24:36 | |
| Cool part about truncate is that applications don't lose the inode nor the fd of they had it open. | 19:28:34 | |
| how costly is it on a laptop's battery to leave a wg link up when you're not really using it? | 19:38:16 | |
| almost entirely free | 19:39:12 | |
| it is an idle interface that doesn't have any idle chatter | 19:39:20 | |
| If you don't send data the interface does nothing. That is one of the design principles behind wireguard. | 19:39:46 | |
| I wonder though, if you send packets but the interface can't relay them, how long does it keep them around? | 19:40:57 | |
| cool. I'm using this to remotely access some resources on my home network, is there a way to automatically disable it on my home network? I guess that's what a mesh vpn is for but nebula couldn't handle the cgnat I'm behind | 19:41:16 | |
In reply to @hpfr:matrix.orgYou could share the ip space, route through your vpn to your home network subnet. | 19:42:07 | |
| When you join the network, packets should pick the route without the extra hop. | 19:42:33 | |
| I think that's what I'm doing | 19:42:40 | |
| Roos: IIRC it depends on the handshake state. If there was a handshake already it just sends it out. | 19:42:48 | |
| Otherwise it tries to do the 0-rtt handshake first which is IIRC 2 packets (including 1 for the payload) | 19:43:10 | |
| if by share the IP space you mean putting my home network subnet in wg's allowedIPs | 19:43:07 | |
| A trivial solution to that problem is: Have a high path metric for the VPN route. It will not use that unless you have that same subnet locally in another network. | 19:49:56 | |
In reply to @andi:kack.itYes, but if connection was lost? (e.g. Plug was pulled) | 19:43:35 | |
In reply to @hpfr:matrix.orgYes. | 19:43:59 | |
In reply to @roosemberth:orbstheorem.chI'm asking because when you roam, no packets are lost. | 19:44:30 | |
| So there must be a buffer somewhere. | 19:44:38 | |
In reply to @roosemberth:orbstheorem.chhow do the packets "know" about both routes? I would have thought putting a range in wg's allowedIPs sort of claims them | 19:55:35 | |
In reply to @roosemberth:orbstheorem.chIt will just reconnect again with the next packet. | 19:57:57 | |
| First matching route is used | 19:57:21 | |
| Packets are authenticated via their keys and not their source addresses. If you send packets 50/50 from different source addresses that works just fine. You can expect to receive packets from the other side on both as well.. | 19:58:47 | |
| I'm not sure the path metric is used by Linux though | 19:57:50 | |
| But you can have multiple routing tables which will be sequentially scanned and matched, just like normal routes. | 19:58:43 | |
| 20:00:03 | ||