[Ovmsdev] Request For Comments - Wireguard VPN
Ludovic LANGE
ll-ovmsdev at lange.nom.fr
Wed Apr 26 14:26:04 HKT 2023
Hi Mark,
I'm going to add the missing parts for the main tunnel (new config items
to a) auto-start + b) to register as a default route if wanted).
For the "manual" commands I'll experiment with these. I like the idea of
having a quick remote access for troubleshooting purposes.
Regarding wolf*, yes, I do think that would be the best idea - to have
these as submodules.
I intend to "relocate" those modules as subfolders of the component in
my patches:
components/wolfssh
├── CMakeLists.txt
├── README.md
├── component.mk
└── wolfssh
├── ChangeLog.md
├── LICENSING
├── Makefile.am
├── README
├── ....
...
This way, we can manage our "glue" code ( CMakeLists.txt and
component.mk ) without interfering with the external component. I
believe that it keeps a proper separation between "our code" and
"upstream code", making it easy to upstream patches and/or to rebase to
a newer release.
Especially given that some of these external components now have their
own CMakeLists.txt - not easily re-usable for our build structure.
If you're OK with that, you can either:
* take this opportunity to add the submodule at the target place -
only dealing with relocating component.mk (you can take inspiration
from my tree : wolfssh
<https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssh>
(component.mk andREADME.md) and wolfssl
<https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssl>
(component.mk andREADME.md and port/ directory that you need to move
- careful, in my tree the user_settings.h is already patched, you
don't want that for the moment.))
* just replace as-is, and I'll do the relocation with a PR.
* Or if you want I can also handle the (b) and (c) parts of your
proposal myself with a PR
Let me know.
Regards,
Le 26/04/2023 à 04:10, Mark Webb-Johnson a écrit :
> I reviewed your config, and see the issue. Quite a lot of parameters
> to set.
>
> Perhaps it is sufficient to have just:
>
> 1. One single wireguard tunnel in configuration, with an associated
> auto setting to automatically start it.
> 2. A wireguiard command to bring up/down other tunnels, manually
> specified on the command line.
>
>
> That way, if the user really needs more than one tunnel (or custom
> tunnels such as I suggest), he can use command shell scripts, or
> remote commands to bring them up/down.
>
> Regarding wolfssh and other similar external components, I think that
> they can/should be split off and run as submodules sourced from a
> GitHub.com/openvehicles repository. We’ve already done that for
> mongoose, zlib, and libzip. Would you like me to create empty
> repositories for those, and then you can submit the PRs to (a) add the
> existing code to the new repository, (b) remove the code from
> Open-Vehicle-Monitoring-System-3, and (c) add the submodule to
> Open-Vehicle-Monitoring-System-3? I think candidates for this approach
> include:
>
> 1. wolfssh
> 2. wolfssl
>
>
> Regards, Mark
>
>> On 25 Apr 2023, at 3:28 PM, Ludovic LANGE <ll-ovmsdev at lange.nom.fr>
>> wrote:
>>
>> Hello Mark,
>>
>> Thanks for the comments. I'll see how we can manage tunnels from the
>> cli, should be doable.
>>
>> Regarding the PR, here is one PR with only WireGuard support :
>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/1 -
>> it's just for review, as it is from my fork to itself.
>>
>> For the WolfSSH / WolfSSL, I have some pending PRs on master, and I
>> create new ones as soon as the previous ones are merged, as to not
>> increase too much the burden on the reviewers.
>> They are here :
>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse
>>
>> (wolfssl will be a new one, not created yet, I'm waiting for the
>> feedback on the wolfssh one - is a new submodule acceptable or not,
>> or is it better to have a subtree, or a copy, ....)
>>
>> Regards,
>>
>> Le 25/04/2023 à 02:49, Mark Webb-Johnson a écrit :
>>> Really glad to see this, and thanks for working on it.
>>>
>>> I do think it would be useful to have many wireguard circuits
>>> configurable.
>>>
>>> For my own use case, I would like to be able to bring up a wireguard
>>> circuit purely from the command line (with no configuration set).
>>> This is because I am frequently called in to help with
>>> setup/configuration/diagnostic issues remotely, and having a full
>>> VPN would be extremely useful for that. If I could just send a
>>> single command to start the vpn back to me, then ssh into the module
>>> (or get can bus data over tcp/ip, etc), it would help tremendously.
>>>
>>> Regarding the PR, can we split this into (a) for wolfssh/wolfssl as
>>> a module, and (b) for wireguard support. At the moment, it is quite
>>> hard to review with both in the same PR.
>>>
>>> Regards, Mark.
>>>
>>>> On 24 Apr 2023, at 5:35 PM, Ludovic LANGE <ll-ovmsdev at lange.nom.fr>
>>>> wrote:
>>>>
>>>> Dear list,
>>>>
>>>> A few months ago I created
>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752
>>>> to explore WireGuard VPN support ; which leaded me to add ESP-IDFv5
>>>> support to OVMS.
>>>>
>>>> Now that this ESP-IDFv5 support is added (in my branch, and it is
>>>> in the progress of getting included in master - with the help and
>>>> the testing of everybody here), I've resumed my exploration of
>>>> adding support for WireGuard VPN to OVMS.
>>>>
>>>> It's now ready for comments, you can now check:
>>>>
>>>> * a new branch here
>>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard
>>>> * a DRAFT PR here
>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882
>>>>
>>>> if you want to explore and test this VPN support for OVMS.
>>>>
>>>>
>>>> My own use case for this feature is :
>>>>
>>>> * Security : I would like my module to be unreachable from the
>>>> public Internet. This is a first step.
>>>> * Practicality : I can reach my module with a single IP address /
>>>> name that is part of my private network. SSH, Web, SCP, ... all
>>>> work as if my module is local to my servers
>>>> * Roaming : The idea is to have a single point of contact even if
>>>> the module changes network, changes IP address, etc...
>>>>
>>>> Part of this feature set is already available with a combination of
>>>> the OVMS Server (v2, v3) and the Hologram.io services, but I wanted
>>>> to be independent of the mobile connexion provider, and also file
>>>> transfer is important for my use case (SCP or other), as I'm often
>>>> wanting to sync the content of the SD card over the network.
>>>>
>>>>
>>>> If you can have a look and give feedback (either here, or on the
>>>> PR), especially on:
>>>>
>>>> * The documentation : is it enough ? properly organized ? should
>>>> it be split ? etc...
>>>> * The command set
>>>> * The configuration items : what's missing ? is the naming OK ?
>>>> * Other features (should I introduced events ? metrics ?)
>>>>
>>>> Also if you have any feature request, please share.
>>>>
>>>> Limitations:
>>>>
>>>> * Currently limited to 1 tunnel, but should work with multiple -
>>>> it's just a question of arranging the configuration to support
>>>> multiple instances
>>>> * Roaming not tested yet (will report)
>>>> * Compatibility with mobile network not tested yet (will need
>>>> help on this)
>>>> * I'm not really happy with the way I set the configuration
>>>> items. I'd like to "hide" (write-only) the important bits
>>>> (private key, shared key), but fear that it would clutter the
>>>> config namespace - especially if I introduce multiple tunnels.
>>>> Maybe one solution would be to have a rich configuration per
>>>> tunnel (like a JSON / YAML), which would be a nightmare to edit
>>>> by hand and would need support in the web interface.
>>>> * Tunnel always active as soon as the configuration is correct.
>>>> May be will need to add an enabled/disabled flag to the
>>>> configuration, and/or an auto-start flag.
>>>>
>>>> Current status:
>>>>
>>>> * Builds on GitHub actions (if you can to test, pre-compiled
>>>> firmwares are available here for example:
>>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/4784405668
>>>> - just download a Zip file (v5.0 or v5.0.1), and flash with a
>>>> command-line like esptool.py --chip esp32 --port /dev/xxxx
>>>> --baud 921600 write_flash --compress --flash_mode "dio"
>>>> --flash_freq "40m" --flash_size detect 0x10000 ovms3.bin )
>>>> * Works on My Machine (tunnel is UP, SSH is working OK, HTTP is
>>>> working OK, performances look OK. Ping time (ICMP) is
>>>> comparable with or without tunnel)
>>>>
>>>>
>>>> Thanks for your comments.
>>>>
>>>> Regards,
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230426/119b3d01/attachment-0001.htm>
More information about the OvmsDev
mailing list