-
Notifications
You must be signed in to change notification settings - Fork 78
new page: Networks access management #401
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
base: main
Are you sure you want to change the base?
Conversation
c192efa to
2542578
Compare
|
decided to include the original diagram sources so it's easier to adjust later on |
8b6c052 to
ecba07f
Compare
c06528f to
a2d8513
Compare
a2d8513 to
98d6696
Compare
92ebdf0 to
8a58d5c
Compare
8a58d5c to
b6b8235
Compare
|
Related: netbirdio/netbird#4606 However I'd like to bring up the question whether the current behavior even makes sense if you need a whole page dedicated to explaining it. It just took me an hour to debug that the input chain isn't populated because to me it was obvious that granting access to a subnet would also include the routing peer itself. |
@Blackclaws I understand the frustration (was there myself at least twice), but it's not as much about preserving the current behavior (it is what you get uniformly across all of the operating systems by default) as need to implement workarounds as fully fledged (and probably quite time-consuming) cross-platform feature that we don't have the manpower to properly design and implement in foreseeable future. |
Understood. Maybe adding a heads up to the networks page when you add resources that explains that routing peers by definition are not included in the scope whatever it may be, would alleviate that problem :) I get that you need to be picky about what to implement and don't have unlimited resources. If this is something that gets implemented down the line that would be great however. |
that's a good idea, thanks |
Uh oh!
There was an error while loading. Please reload this page.