kstyagi/nest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: enhance networking capabilities with improved egress handling and automatic host sharing rules

Browse Source
This commit is contained in:
kstyagi
2026-09-23 06:23:49 +05:30
parent 534a78f2a9
commit ed9c5306af
3 changed files with 110 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
USAGE.md
+36 -7
View File
@@ -29,6 +29,12 @@ Bridge: uvm0
Guest pool: 10.42.0.2 through 10.42.0.254
```
Guest IPv4 internet access shares the host's connection automatically. Host
offline means guest internet is offline; reconnecting the host restores guest
egress. UVM installs sharing rules even when booting offline, and follows the
host's current routes when uplinks change. The private network remains usable
without internet. Applications may need to reconnect after a network interruption.
The default locations on the host are under `/var/lib/uvm`. Stop/start and
restart reuse the private disk; delete removes it. UVM is a local CLI, not an
autostart service or a daemon that continuously repairs VM or firewall state.
@@ -1134,7 +1140,10 @@ Firecracker logs may include guest/application secrets; redact them before shari
## 15. Networking Troubleshooting
The existing `iptables` egress MASQUERADE and forwarding rules are unchanged.
UVM enables IPv4 forwarding and installs `uvm-egress`-commented iptables
MASQUERADE and forward/return rules. These match the private subnet and bridge
without fixing an uplink, so guest traffic follows the host's current routes.
Scoped forwarding exceptions are inserted ahead of existing host-chain rules.
Private port filtering is a separate native nftables `bridge` policy, not
DNAT. It must be installed and read back before the TAP is active. The bridge
must have STP disabled and each TAP must have bridge-slave `group_fwd_mask`
@@ -1162,11 +1171,30 @@ sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD
```
After upgrading UVM, apply the sharing rules to an already-running VM with:
```sh
sudo ./uvm.py start web
```
`start` on a running VM refreshes its private policy and shared host networking
without a reboot. Use the updated CLI checkout, or restart the API server to
load the updated code before using its start endpoint. Subsequent host
disconnects, reconnects, and route changes require no UVM command.
Check DNS and HTTPS from the guest:
```sh
sudo ./uvm.py ssh web -- getent ahostsv4 example.com
sudo ./uvm.py ssh web -- curl -4 --connect-timeout 5 --max-time 15 -I https://example.com
```
Common issues:
| Symptom | First checks |
|---|---|
| Guest cannot reach the internet | Bridge is up, TAP is up, host has default route, NAT and FORWARD rules exist. |
| Guest cannot reach the internet | Confirm the host can reach the same destination, bridge/TAP are up, and `uvm-egress` NAT/FORWARD rules exist; use `start VM` to refresh sharing. |
| IP connectivity works but DNS fails | Check guest `/etc/resolv.conf` and DNS reachability. The Ubuntu template uses `1.1.1.1` and `8.8.8.8`; host loopback resolvers such as `127.0.0.53` are not reachable as guest loopback addresses. |
| Requested guest IP is rejected | Confirm it is inside the configured subnet and not used, gateway, network, or broadcast. |
| Create says TAP already exists | Inspect the interface; do not delete it unless you know it is stale UVM state. |
| Existing bridge is rejected | Verify it is a software Linux bridge with STP disabled. |
@@ -1187,7 +1215,7 @@ Keep these constraints in mind when deciding whether UVM fits a scenario:
- No quotas or cgroup CPU, memory, I/O, or process limits are applied.
- Fractional CPU requests are advisory only.
- No autostart, background lifecycle/firewall reconciliation, or guest-coordinated stop.
- No UDP/IPv6 service policies, public connectivity setup, host-port mapping,
- No UDP/IPv6 service policies, public inbound connectivity setup, host-port mapping,
DNS publication, guest reverse proxy/TLS setup, DHCP, load balancing,
snapshots, multi-network tenancy, or multi-host scheduling.
- The API uses one shared bearer token, not individual users, roles, or tenants.
@@ -1220,7 +1248,7 @@ python3 -B -m unittest discover -s tests -v
The opt-in packet test runs **only in disposable isolated user/network
namespaces**, which may require privileges. It needs `unshare`, `ip`,
`bridge`, `nft`, `conntrack`, and `sysctl`:
`bridge`, `nft`, `iptables`, `conntrack`, and `sysctl`:
```sh
UVM_FIREWALL_INTEGRATION=1 python3 -B -m unittest discover -s tests/integration -v
@@ -1228,9 +1256,10 @@ UVM_FIREWALL_INTEGRATION=1 python3 -B -m unittest discover -s tests/integration
Namespace creation was denied in this workspace (`Operation not permitted`),
so the packet test skipped. That is a permission limitation, not real-packet
or real-host validation. The harness uses veths as TAP stand-ins and routed
egress without NAT; it does not boot Firecracker or validate the host's real
TAP/NAT setup. Run actual VM/SSH/egress checks on an isolated Linux host before
or real-host validation. The harness uses veths as TAP stand-ins and simulated
upstreams to check NAT, offline startup, reconnects and uplink changes. It does
not boot Firecracker or validate the host's real TAP setup. Run actual
VM/SSH/egress checks on an isolated Linux host before
relying on the deployment.
## 19. Get Help