Qubes/gsoc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Scometic fixes

Browse Source
This commit is contained in:
Giulio 2021-06-25 16:12:35 +02:00
parent c4616aa5db
commit 5fe03406b0
1 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Readme.md
View File

@ -4,7 +4,7 @@
Forwarding ports to Qubes VM is currently possible only though a multi step, error prone, manual process that also requires writing custom configuration in order to be persistent between reboots. Things as simple as starting a webserver or netcat for LAN file sharing canbe eventually a troublesome and time-wasting process[1][2]. Furthermore, applications thatrely on NAT traversal protocols such as those for audio and video communications do not workin direct P2P mode with STUN and always use TURN instead[3]. Forwarding ports to Qubes VM is currently possible only though a multi step, error prone, manual process that also requires writing custom configuration in order to be persistent between reboots. Things as simple as starting a webserver or netcat for LAN file sharing canbe eventually a troublesome and time-wasting process[1][2]. Furthermore, applications thatrely on NAT traversal protocols such as those for audio and video communications do not workin direct P2P mode with STUN and always use TURN instead[3].
### Project Goals ### Project Goals
Implement a GUI for automatic and persistent, eventually with a predefined timespan (ie: untilreboot), port forwarding. The idea is to split horizontally the "Firewall Rules" tab in the"Qubes Settings" window and add another area below it. It is aloready possible to forward TCPstreams, however there is no GUI nor a clear dashboard and furthermore its versatility islimited.Additionally, discuss and verify the possibility to implement a secure NAT traversal systemand GUI. A basic proposal could be a checkbox to enable NAT traversal requests. When thecheckbox is selected, the FirwallVM will redirect NAT traversal requests to a local pythondaemon or a dedicated VM that will negotiate the NAT traversal and configure the networkaccordingly. In this case, prompt the user in Dom0 about the NAT traversal request. Of coursethe qvm-* set of tools must e able to achieve the same tasks via CLI. Implement a GUI for automatic and persistent, eventually with a predefined timespan (ie: untilreboot), port forwarding. The idea is to split horizontally the "Firewall Rules" tab in the"Qubes Settings" window and add another area below it. It is aloready possible to forward TCP streams, however there is no GUI nor a clear dashboard and furthermore its versatility is limited. In addition, discuss and verify the possibility to implement a secure NAT traversal systemand GUI. A basic proposal could be a checkbox to enable NAT traversal requests. When thecheckbox is selected, the FirwallVM will redirect NAT traversal requests to a local pythondaemon or a dedicated VM that will negotiate the NAT traversal and configure the networkaccordingly. In this case, prompt the user in Dom0 about the NAT traversal request. Of coursethe qvm-* set of tools must e able to achieve the same tasks via CLI.
### Implementation ### Implementation
First develop and document the part related to manual port forwarding since it is both a more frequent use case and is less complicated. Depending on the problems encountered, evaluate the feasibility of secure NAT traversal. First develop and document the part related to manual port forwarding since it is both a more frequent use case and is less complicated. Depending on the problems encountered, evaluate the feasibility of secure NAT traversal.
@ -131,10 +131,10 @@ Of course `expire=` and `comment=` are optional fields.
### Proposal chart ### Proposal chart
The main distinction between internal and external port forwarding is: The main distinction between internal and external port forwarding is:
* _Internal_ resolves only <appvm>'s <ntvm> * _Internal_ resolves only <appvm>'s <ntvm>
* _External_ recursively resolves all upstream networking vm and sets forwarding rules on all of them * _External_ recursively resolves all upstream networking vm and sets forwarding rules on all of them
This should cover multiple scenarios: This should cover multiple scenarios:
* _Standard external forwarding_ when <appvm> service needs to be exposed on a physical interface * _Standard external forwarding_ when <appvm> service needs to be exposed on a physical interface
* _Standard internal forwarding_ when <appvm> service needs to be exposed to other <appvm2/3/4> connected to the same <netvm> * _Standard internal forwarding_ when <appvm> service needs to be exposed to other <appvm2/3/4> connected to the same <netvm>
@ -145,7 +145,7 @@ It is important to note that in the last case, it is just a standard case of int
![Implementation](https://git.lsd.cat/Qubes/gsoc/raw/master/assets/implementation.png) ![Implementation](https://git.lsd.cat/Qubes/gsoc/raw/master/assets/implementation.png)
### Implementation roadmap ### Implementation Roadmap
1. ✔️ In `core-admin-client/qubesadmin/firewall.py` firewall.py > The code 1. ✔️ In `core-admin-client/qubesadmin/firewall.py` firewall.py > The code
needs to support the new options for the rule (action=forward needs to support the new options for the rule (action=forward
@ -202,7 +202,11 @@ iptables -w -I INPUT 5 -d <appvm_ip> -p tcp --dport <target_port> -m conntrack -
## Extra ## Extra
### Useful Commands ### Useful Commands
```
#
```
```
### Dev Environment ### Dev Environment
Currently developing on VMWare Workstation on Windows due to issues in virtualizing on linux on my home hardware. Currently developing on VMWare Workstation on Windows due to issues in virtualizing on linux on my home hardware.
QubesOS is virtualized behind NAT and can reach Windows Host via SSH. QubesOS is virtualized behind NAT and can reach Windows Host via SSH.