[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Whonix Hidden Service Hosting Initiative -> KVM development

I don’t think so. You helped sorting out lots of items from https://www.whonix.org/wiki/Dev/KVM, wrote big parts of https://www.whonix.org/wiki/KVM and moved forward KVM support.

I guess to play well with AppArmor, we should recommend to place images in /var/lib/libvirt/images/ or otherwise mention this possibility in instructions?

First we should compare our kvm/libvirt installations. It’s possible that our results are different because of that. I will publish my installation steps soon. Also there is a huge difference in our targets - I made headless builds on logical volumes only, so no qcow, no raw image files.

Second I see a problem in


It doesn’t make sense to create a virtual isolated whonix network 10.0.0.x but should be 192.168.0.0 (this is what I did when I got whonix running)

Third we have to be extremly careful when selecting the virtual nics and networks. Like mentioned before, changes here cause serious trouble with apparmor and ip tables. I am looking for more details as I even succeeded to mess up the entire sandbox server.

what happens here?? same install as yesterday but now it throws
ERROR in ./build-steps.d/1200_create-debian-packages detected!

Setting up kpartx (0.4.9+git0.4dfdaf2b-7~deb7u2) …

  • ‘[’ ‘’ = true ‘]’
  • rm --force /etc/apt/sources.list.d/whonix_temp.list
  • apt-get --no-download --list-cleanup update
    Reading package lists…
  • ‘[’ 1 = 1 ‘]’
  • true ‘INFO: Skip running update-guestfs-appliance, because BARE_METAL is set to 1, ok.’
  • disable_apt_cache
  • trap error_handler_general ERR INT TERM
  • unset http_proxy
  • cat /usr/sbin/policy-rc.d
    cat: /usr/sbin/policy-rc.d: No such file or directory
  • true
  • ‘[’ ‘’ = true ‘]’
  • service haveged status
    haveged is running.
  • grep device-mapper /proc/devices
  • true
  • modprobe dm_mod
  • grep device-mapper /proc/devices
    253 device-mapper
  • cat /proc/devices
    Character devices:
    1 mem
    4 /dev/vc/0
    4 tty
    4 ttyS
    5 /dev/tty
    5 /dev/console
    5 /dev/ptmx
    7 vcs
    10 misc
    13 input
    21 sg
    29 fb
    116 alsa
    128 ptm
    136 pts
    180 usb
    189 usb_device
    252 hidraw
    253 bsg
    254 rtc

Block devices:
2 fd
259 blkext
7 loop
11 sr
253 device-mapper
254 virtblk

  • ‘[’ ‘’ = true ‘]’
  • ‘[’ ‘’ = true ‘]’
  • benchmark_time_end
    ++ date +%s
  • benchmark_time_end=1401909209
  • benchmark_took_seconds=1031
    ++ convertsecs 1031
    ++ (( h=1031/3600 ))
    ++ (( m=(1031%3600)/60 ))
    ++ (( s=1031%60 ))
    ++ printf ‘%02d:%02d:%02d\n’ 0 17 11
    ++ true
  • benchmark_took_time=00:17:11
  • true
  • true 'INFO: End of: ./build-steps.d/1100_prepare-build-machine No error detected. (benchmark: 00:17:11)'
    run-parts: executing ./build-steps.d/1200_create-debian-packages
  • true 'Currently running script: ./build-steps.d/1200_create-debian-packages '
    +++ dirname ./build-steps.d/1200_create-debian-packages
    ++ cd ./build-steps.d
    ++ pwd
  • MYDIR=/home/user/Whonix/build-steps.d
  • cd /home/user/Whonix/build-steps.d
  • cd …
  • cd help-steps
  • WHONIX_BUILD_PARSED=1
  • VMNAME=internalrun
  • source pre
    ++ set +x
  • source variables
    ++ set +x
    INFO: Setting… export UWT_DEV_PASSTHROUGH="1"
    whonix_build_whonix_version_new: 8.1
    whonix_build_new_changelog_version: 2:8.1-debpackage1
  • cd /home/user/Whonix/help-steps
  • cd …
  • true 'INFO: Currently running script: ./build-steps.d/1200_create-debian-packages ’
  • create-debian-packages
  • trap error_handler_general ERR INT TERM
  • signing_key
  • trap error_handler_general ERR INT TERM
  • ‘[’ 1 = 1 ‘]’
  • true './build-steps.d/1200_create-debian-packages INFO: Using auto local signing key method… ’
  • ‘[’ ‘!’ -f /home/user/whonix_binary/gpg-local-signing-key/done ‘]’
  • true './build-steps.d/1200_create-debian-packages INFO: We do not yet have a local OpenPGP signing key for our local APT repository. Creating one… ’
  • sudo -E -u user mkdir --parents /home/user/whonix_binary/gpg-local-signing-key
  • sudo -E -u user chmod 700 /home/user/whonix_binary/gpg-local-signing-key
  • echo ‘
    Key-Type: RSA
    Key-Length: 4096
    Subkey-Type: RSA
    Subkey-Length: 4096
    Name-Real: Whonix auto generated local APT signing key
    Name-Email: whonix@local-signing.key
    Expire-Date: 0
    Preferences: SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
  • sudo -E -u user gpg --no-options --no-emit-version --no-comments --display-charset utf-8 --keyserver hkp://qdigse2yzvuglcix.onion --personal-digest-preferences SHA512 --cert-digest-algo SHA512 --default-preference-list ‘SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed’ --keyserver-options no-honor-keyserver-url --fixed-list-mode --keyid-format 0xlong --use-agent --list-options show-uid-validity --sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g --no-default-keyring --homedir /home/user/whonix_binary/gpg-local-signing-key --batch --gen-key
    gpg: keyring /home/user/whonix_binary/gpg-local-signing-key/secring.gpg' created gpg: keyring/home/user/whonix_binary/gpg-local-signing-key/pubring.gpg’ created
    …+++++
    …+++++
    …+++++
    …+++++
    gpg: /home/user/whonix_binary/gpg-local-signing-key/trustdb.gpg: trustdb created
    gpg: key 0xC579875A2FF8DA79 marked as ultimately trusted
  • sudo -E -u user touch /home/user/whonix_binary/gpg-local-signing-key/done
  • true './build-steps.d/1200_create-debian-packages INFO: Created local OpenPGP signing key for our local APT repository. ’
  • ‘[’ ‘!’ -d /home/user/whonix_binary/gpg-local-signing-key ‘]’
  • true ‘INFO: WHONIX_LOCAL_SIGNING_KEY_FOLDER: /home/user/whonix_binary/gpg-local-signing-key exists, ok.’
  • sudo -E -u user gpg --no-options --no-default-keyring --homedir /home/user/whonix_binary/gpg-local-signing-key --keyid-format 0xlong --fingerprint --list-secret-keys
    gpg: checking the trustdb
    gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
    gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
    /home/user/whonix_binary/gpg-local-signing-key/secring.gpg

sec 4096R/0xC579875A2FF8DA79 2014-06-04
Key fingerprint = B1C7 4FDF 8108 FC95 0E3F 8144 C579 875A 2FF8 DA79
uid Whonix auto generated local APT signing key whonix@local-signing.key
ssb 4096R/0x6110949406EF8E88 2014-06-04

  • check_changelog_version
  • trap error_handler_general ERR INT TERM
  • true
  • cleanup_old_packages
  • trap error_handler_general ERR INT TERM
  • true './build-steps.d/1200_create-debian-packages INFO: Going to update local APT repository… ’
  • sleep 3
  • cd /home/user/Whonix/help-steps
  • cd …
  • true './build-steps.d/1200_create-debian-packages INFO: Cleaning old packages… ’
  • /home/user/Whonix/help-steps/cleanup-files
  • true 'Currently running script: /home/user/Whonix/help-steps/cleanup-files '
    +++ dirname /home/user/Whonix/help-steps/cleanup-files
    ++ cd /home/user/Whonix/help-steps
    ++ pwd
  • MYDIR=/home/user/Whonix/help-steps
  • cd /home/user/Whonix/help-steps
  • cd …
  • cd help-steps
  • WHONIX_BUILD_PARSED=1
  • ROOT_CHECK=0
  • VMNAME=internalrun
  • source pre
    ++ set +x
  • source variables
    ++ set +x
    INFO: Setting… export UWT_DEV_PASSTHROUGH="1"
    whonix_build_whonix_version_new: 8.1
    whonix_build_new_changelog_version: 2:8.1-debpackage1
  • true 'INFO: Currently running script: /home/user/Whonix/help-steps/cleanup-files ’
  • cleanup_files
  • trap error_handler_general ERR INT TERM
  • set +x
    rm --force /home/user/Whonix/…/whonix-shared-packages-dependencies*.deb
    rm --force /home/user/Whonix/…/whonix-shared-packages-recommended*.deb
    rm --force /home/user/Whonix/…/whonix-shared-files*.deb
    rm --force /home/user/Whonix/…/whonix-gateway-packages-dependencies*.deb
    rm --force /home/user/Whonix/…/whonix-gateway-packages-recommended*.deb
    rm --force /home/user/Whonix/…/whonix-gateway-files*.deb
    rm --force /home/user/Whonix/…/whonix-workstation-packages-dependencies*.deb
    rm --force /home/user/Whonix/…/whonix-workstation-packages-recommended*.deb
    rm --force /home/user/Whonix/…/whonix-workstation-files*.deb
    rm --force /home/user/Whonix/…/whonix-shared-desktop*.deb
    rm --force /home/user/Whonix/…/whonix-shared-desktop-kde*.deb
    rm --force /home/user/Whonix/…/whonix-shared-kde-accessibility*.deb
    rm --force /home/user/Whonix/…/whonix-workstation-default-applications*.deb
    rm --force /home/user/Whonix/…/whonix-workstation-extra-applications*.deb
    rm --force /home/user/Whonix/…/whonix-workstation-langpack-common*.deb
    rm --force /home/user/Whonix/…/whonix-shared-desktop-langpack-kde*.deb
    rm --force /home/user/Whonix/…/whonix*.dsc
    rm --force /home/user/Whonix/…/whonix*.changes
    rm --force /home/user/Whonix/…/whonix*.tar.*
    rm --force /home/user/Whonix/…/whonix*.build
  • fakeroot /home/user/Whonix/debian/rules clean
    dh_testdir
    dh_testroot
    dh_clean
    rm --force /home/user/Whonix/debian/.init
    rm --force /home/user/Whonix/debian/
    .bash-completion
    rm --force --recursive /home/user/Whonix/debian/tmp-man
  • rm --force /home/user/Whonix/debian/changelog
  • benchmark_time_end
    ++ date +%s
  • benchmark_time_end=1401909234
  • benchmark_took_seconds=2
    ++ convertsecs 2
    ++ (( h=2/3600 ))
    ++ (( m=(2%3600)/60 ))
    ++ (( s=2%60 ))
    ++ printf ‘%02d:%02d:%02d\n’ 0 0 2
    ++ true
  • benchmark_took_time=00:00:02
  • true
  • true ‘INFO: End of: /home/user/Whonix/help-steps/cleanup-files No error detected. (benchmark: 00:00:02)’
  • true './build-steps.d/1200_create-debian-packages INFO: Cleaned old packages. ’
  • check_for_uncommited_changes
  • trap error_handler_general ERR INT TERM
    ++ git status --porcelain
  • ‘[’ -n ‘?? patrick.asc’ ‘]’
  • true './build-steps.d/1200_create-debian-packages ERROR: Git reports uncommitted changes! ’
  • true './build-steps.d/1200_create-debian-packages INFO: Running “git status” for your convenience. ’
  • git status

Not currently on any branch.

Untracked files:

(use “git add …” to include in what will be committed)

patrick.asc

nothing added to commit but untracked files present (use “git add” to track)

  • true './build-steps.d/1200_create-debian-packages INFO: Running git “clean --dry-run -d --force --force” for your convenience. ’
  • git clean --dry-run -d --force --force
    Would remove patrick.asc
  • true ‘./build-steps.d/1200_create-debian-packages You most likely like to revert debian/changelog to run:
    git checkout – debian/changelog
    /home/user/Whonix/help-steps/cleanup-files
    or if you know what you are doing:
    git clean --dry-run -d --force --force
    git reset --hard’
  • error ‘Uncommitted changes! See above!’
    ./build-steps.d/1200_create-debian-packages: line 142: error: command not found
    ++ error_handler_general
    ++ error_handler_shared
    ++ last_exit_code=127
    ++ last_bash_command=‘error “Uncommitted changes! See above!”’
    ++ ‘[’ test -o xtrace = 0 ‘]’
    ++ set +x
    ERROR in ./build-steps.d/1200_create-debian-packages detected!
    Please have a look above “error_handler_general”, note the command that failed, its output and last_exit_code.
  • Please enter c and press enter to continue. (Recommended against!)
  • Please press enter to cleanup and exit.

As

[code]+ true './build-steps.d/1200_create-debian-packages ERROR: Git reports uncommitted changes! ’

  • true './build-steps.d/1200_create-debian-packages INFO: Running “git status” for your convenience. ’
  • git status

Not currently on any branch.

Untracked files:

(use “git add …” to include in what will be committed)

patrick.asc

nothing added to commit but untracked files present (use “git add” to track)

  • true './build-steps.d/1200_create-debian-packages INFO: Running git “clean --dry-run -d --force --force” for your convenience. ’
  • git clean --dry-run -d --force --force
    Would remove patrick.asc
  • true ‘./build-steps.d/1200_create-debian-packages You most likely like to revert debian/changelog to run:
    git checkout – debian/changelog
    /home/user/Whonix/help-steps/cleanup-files
    or if you know what you are doing:
    git clean --dry-run -d --force --force
    git reset --hard’
  • error ‘Uncommitted changes! See above!’
    [/code]

indicates, you most likely have an extra file “patrick.asc” in your source root folder ~/Whonix.

Delete the file or move it somewhere lese and the issue should be gone.

[quote=“zweeble, post:23, topic:165”]Second I see a problem in


It doesn’t make sense to create a virtual isolated whonix network 10.0.0.x but should be 192.168.0.0 (this is what I did when I got whonix running)[/quote]
Sounds good. Those instructions are in unfinished / in progress. Feel free to make edits.

That’s right, I downloaded the asc file manually, because when proceeding as in https://www.whonix.org/wiki/Dev/Build_Documentation/Physical_Isolation/8#Get_the_Signing_Key the key import gave me an error that ./whonix_shared/usr/share/whonix/keys/whonix-keys.d/patrick.asc does not exist. By accident I put into the Whonix dir :wink:
If I ignore that then git complains about the missing asc…
Funny though that yesterday this wasn’t a problem

Zweeble, I think for this to be a proper experiment you need to run everything as close to my configuration as possible, such as qcow2 images, so we can figure out if this is a problem that is distro dependent, iptables dependent or whatever else.

For my 8.2 vms I created a second network with a subnet range of 192.168.200.0/24 while my first network was a 10.0.0.0/24 one. But in both instances since I have DHCP turned off for these netowrks, the workstaton and inward facing nic of the gateway have an IP of 192.168.0.0/24 address. So in this situation, I don’t think the subnet range I chose for the internal network when setting it up, has any bearing or effect on this bug.

[quote=“zweeble, post:27, topic:165”]That’s right, I downloaded the asc file manually, because when proceeding as in https://www.whonix.org/wiki/Dev/Build_Documentation/Physical_Isolation/8#Get_the_Signing_Key the key import gave me an error that ./whonix_shared/usr/share/whonix/keys/whonix-keys.d/patrick.asc does not exist. By accident I put into the Whonix dir :wink:
If I ignore that then git complains about the missing asc…
Funny though that yesterday this wasn’t a problem[/quote]
My mistake. Fixed build documentation thanks to zweeble on irc.

HulaHoop,

This is how I made a 8.1, Terminal-Only Build, NoDefaultApps Build.
It works like a charm, tested with 1 gateway and 4 workstations in one isolated subnet.

My host server is on a physical local network 192.168.10.0/24
Before it was on 192.168.0.0/24, imo the reason I had so much trouble.
A script that allows to modify the gateway network eth1 would be the best solution.

In order to keep things as simple as possible, I use virt-manager.
The default virtual network I leave untouched.

First I created (both without dhcp)
whonix_NAT network 192.168.100.0/28 for the gateway eth0
and
whonix_ISO network 192.168.0.0/28 for the gateway eth1 and workstation eth0

For the wheezy install I used only one whonix_NAT nic as rtl8139 and set it to
address 192.168.100.2
netmask 255.255.255.240
gateway 192.168.100.1
broadcast 192.168.100.15
network 192.168.100.0

Then I cloned this vm and proceeded with the whonix physical build instructions (again: Terminal-Only Build, NoDefaultApps Build), stopped at 4.18 Run Build Script and cloned this vm again. Now I have a whonix81_buildready vm and a gateway81-1 vm

For the gateway81-1 vm build I added the eth1 to whonix_ISO network as 192.168.0.10,
run the build, then set the network settings again (static), disable the kvm virtualization parameter in whonixcheck, run the upgrades and finally whonixcheck tells me all is green :slight_smile:

Then cloned the whonix81_buildready vm again to workstation81-1, same procedure like the gateway, but with only eth0, still on whonix_NAT network. After the build I removed the eth0 and replaced it with a new eth0 on whonix_ISO network - do not just change the vm’s nic settings, that ends in trouble. Also I rebooted the host after I made modifications on existing virtual networks in order to avoid problems with apparmor/libvirt. Sounds funny but it’s aknown issue at libvirt.

I admit that source modifications are way above my head. I can’t imagine that we should expect every KVM user to know this level of info to get their copy working. That would make this version completely impractical for almost everyone. What suggestions or fixes do you suggest for streamlining this process?

So now, what do the security tests show? Is there a leak with or without transporxy shutdown? How about after the iptables fix that was mentioned before?

No worries :wink:
The whonix-KVM build script has to install kvm, libvirt and vmbuilder (and some more, I have to check) so the script can setup the vms and the 2 virtual networks - that’s all. The user then starts the vms with the Virtual Machine Manager GUI (=virt-manager), this is easy.

The biggest effort in this kvm version is a script the checks the local lan network, because this might be in many or even most cases 192.168.0.0 The way the virtual switch works doesn’t allow a second 192.168.0.0 network, so the isolated whonix network has to be moved somewhere else 192.168.x.0
For the workstation this shouldn’t be an issue, but for the gateway eth1 it certainly is.

whonix gateway 8.2 (headless) build on kvm - no errors, whonixcheck all green - good job, Patrick! :slight_smile:

Due to popular request in various places by various people…

Proposal for Whonix 9.

Gateway eth1.

auto eth1
iface eth1 inet static
       address 11.150.150.150
       netmask 255.255.192.0

Workstation eth0.

auto eth0
iface eth0 inet static
       address 11.150.150.151
       netmask 255.255.192.0
       gateway 11.150.150.150

I am currently testing these. This should less likely cause conflicts with physical networks, routers, kvm…

What do you think?

Why would vmbuilder be required?

Why not use the downloadable .qcow2 images?

[quote=“zweeble, post:32, topic:165”]The biggest effort in this kvm version is a script the checks the local lan network, because this might be in many or even most cases 192.168.0.0 The way the virtual switch works doesn’t allow a second 192.168.0.0 network, so the isolated whonix network has to be moved somewhere else 192.168.x.0
For the workstation this shouldn’t be an issue, but for the gateway eth1 it certainly is.[/quote]
My suggestion in my previous post should solve that all without need for such a script that checks host local lan network?

Still, the KVM script could still check if the host uses IPs 11.150.150.150, 11.150.150.151 [and more?], and if so, warn about it. (Just an unlikely corner case, but why not.)

Why would vmbuilder be required?

Why not use the downloadable .qcow2 images?


You are right, my mistake I think always about myself^^
The subject of qcow, img or lv depends on every users individual decission, but qcow will fit in most cases.

auto eth0 iface eth0 inet static address 11.150.150.151 netmask 255.255.192.0 gateway 11.150.150.150
The proposed new config for the isolated network really is a corner case, doesn’t this belong to a classless domain routing network? I have no clue how lan components will react on that, neither can I tell about advantages/disadvantages.

A network warning script would be nice, at least it would tell the user why his install won’t work and so he doesn’t stay in the dark.

A gateway eth1 network script (better: ethx[:y], ie eth2 or aliased eth1:0) would have a very different scope. Let’s say I am hosting more than one hidden service and I want to have more isolated networks for other hidden services - actually there is no way to do this, except manually changing all ethx related files? What else would be effected by these changes?
Sure this gateway ethx network script doesn’t make sense during build.

Thinking big. Whonix in cooperate networks. Whonix for ISPs etc. I wouldn't want to add unnecessary limitations while we're at it so we don't have to discuss & change this again.
With that ethx script there wouldn't be any discussions or changes anymore.
  • add new isolated virtual network
  • start the new gateway vm, edit eth0 if necessary
  • edit the script with the new ethx config (btw adding broadcast for none /24 networks makes sense!)
  • run it
  • change the new workstations’ eth0 manually
    done :slight_smile:

I am curious what you think about that…
(maybe we should change the topic to Whonix Hidden Service Hosting Initiative^^)

Due to popular request in various places by various people...

Proposal for Whonix 9.

Gateway eth1.

Code: [Select]

auto eth1
iface eth1 inet static
address 11.150.150.150
netmask 255.255.192.0

Workstation eth0.

Code: [Select]

auto eth0
iface eth0 inet static
address 11.150.150.151
netmask 255.255.192.0
gateway 11.150.150.150

+1 That would be a good idea.

I think the Fin Ack test instructions are problematic I will explain later., but I don’t think there is a leak, we were looking for the wrong things.

In my previous post about what IP’s one would have to change (https://www.whonix.org/forum/index.php/topic,328.msg2218.html#msg2218) (now edited/correcte), I forgot mentioning:
https://github.com/Whonix/Whonix/blob/8.2/whonix_gateway/usr/bin/whonix_firewall#L100
NON_TOR_WHONIXG=“192.168.1.0/24 192.168.0.0/24 127.0.0.0/8”

In Whonix 8 that can only be changed by editing /usr/bin/whonix_firewall. In Whonix 9, the variable will be renamed to NON_TOR_GATEWAY and can be configured in /etc/whonix_firewall.d.

doesn't this belong to a classless domain routing network?
Unfortunately not.

In a test isolated vbox network.

auto eth0
iface eth0 inet static
       address 192.168.0.10
       netmask 255.255.255.0
       ## or
       #netmask 255.255.192.0

unfortunately could not connect to

auto eth0
iface eth0 inet static
       address 11.150.150.151
       netmask 255.255.192.0

Which is a real shame. Because it will break Whonix 8 Workstation’s that try to connect to a Whonix 9 Gateway. A breaking change. So next Whonix version, users are probably best off first updating their Workstations, then live with them having no connectivity, then updating the Gateway, and then everything should go to normal.

If you have any suggestions for classless network configs, by all means, please make them.

I have no clue how lan components will react on that, neither can I tell about advantages/disadvantages.
By the way, Qubes OS uses something similar. https://www.whonix.org/wiki/Dev/Qubes_OS#IPs There should be no issues, except no one on google said, they're using that configuration. So conflicts should be very rare to non-existent.
A network warning script would be nice, at least it would tell the user why his install won't work and so he doesn't stay in the dark.
I guess that will be no problem, minor easy feature.
A gateway eth1 network script (better: ethx[:y], ie eth2 or aliased eth1:0) would have a very different scope. Let's say I am hosting more than one hidden service and I want to have more isolated networks for other hidden services - actually there is no way to do this, except manually changing all ethx related files? What else would be effected by these changes?
It's a nice idea, but I am not sure how difficult that would be.

I guess you’re equally hosed, if you are a plain Debian/Ubuntu/Fedora/etc. Linux user? What solutions you have there besides? Maybe we don’t have to reinvent the wheel.

I guess due to limitations of ifupdown, network manager has been developed. Unfortunately, CLI support last time I checked wasn’t fully ready.

Now if I attempt to /etc/network/interfaces writer, I fear it could quickly become as complex as network manager.

Sure this gateway ethx network script doesn't make sense during build.
If there is a --default switch or so, it would be okay.
With that ethx script there wouldn't be any discussions or changes anymore.
Why not?
- add new isolated virtual network
Sounds more like a task for kvm script rather than /etc/network/interfaces writer script.
- start the new gateway vm, edit eth0 if necessary
From outside? From the host? That sounds rather difficult. Automated starting and controlling of VMs is non-trivial. Mounting the image and editing it is simpler. Still, complex (various user supplied file names) and difficult as whonix build script.
- edit the script with the new ethx config
This might be reasonable easy to write it for the first time. Later, when users made changes such as extra comments or settings, editing it again by script gets more difficult. We might have to edit in future. For both, foreseeable (https://github.com/Whonix/Whonix/issues/136) and unforeseeable reasons.
(btw adding broadcast for none /24 networks makes sense!)
Why?
I am curious what you think about that...
I guess this /etc/network/interfaces writer script is a separate topic. Finding an appropriate IP range the preliminary and primary problem.

Sorry, I didn’t express myself clear enough. Not the script should make these steps (omg) but the user or better said, the network admin (thinking big^^). The script itself is only a part of it, and to be honest this script should be something you should ask money for because it offers the key difference for a pro user.

Let me build a scenario:
Hidden Hosting ltd wants, ie for security reasons, to separate various services they are hosting using several different isolated virtual networks. So the admin creates these networks, clones the needed workstations in it and changes their eth0 according to their virtual network. Now what to do with the gateway eth1?? The admin edits your new ethx script (sets the data for his new isolated virtual network) and then starts the script, that does nothing else then making the necessary changes for eth1 on the existing gateway.
The cherry on the cake would be if the script could also configure eth2 or eth3 in case that one gateway has to serve more isolated virtual networks.

In that case there is no more discussion or whatever about what network to use. Imo getting out of 192.168.x.x to 172.16+.x.x as a standard would be enough - if it’s not, still your new script can be used.

If you want to use a classless domain routing network you must not forget that you have to use also classless routing protocols - that’s the trouble I mentioned before as I don’t know at all, who or what supports these protocols. I personally try not to make things more complicated as they are and so stick to what I know for sure^^

And adding broadcast for none /24 networks really makes sense, as some boxes consider ie a 255.255.255.240 still a /24 instead of a /28 - please don’t ask me WHY they do ;))

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]