[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3477 [Torouter]: A plan to understand specific features for the "Feature complete alpha-test prototype"
#3477: A plan to understand specific features for the "Feature complete alpha-test
prototype"
-------------------------+--------------------------------------------------
Reporter: ioerror | Owner: ioerror
Type: task | Status: closed
Priority: normal | Milestone:
Component: Torouter | Version:
Resolution: fixed | Keywords:
Parent: | Points:
Actualpoints: |
-------------------------+--------------------------------------------------
Changes (by ioerror):
* status: new => closed
* resolution: => fixed
Comment:
We have three main network interfaces. The {{{eth0}}} device will only
support dhcp ethernet networks. Manual network configuration is not
supported at this time but users are welcome to ssh into the device to
attempt to configure it at their own risk.
The {{{eth0}}} network interface is assumed to be the internet connection
for the Torouter until further notice.
The {{{eth1}}} network interface is assumed to be a gateway that provides
dhcp service for any devices connected to {{{eth1}}} - this allows the
Torouter to be used as a NAT assuming that {{{eth0}}} is connected to the
internet. In addition, this is where the web UI (not yet written,
{{{sshd}}}, {{{dhcpd}}}, and a normal DNS cache for configuration would
bind to the {{{eth1}}} network. This prevents configuration of the bridge
without authorization by connecting to the address advertised by Tor. It
also allows for using the Torouter as a NAT device. Developers will likely
change this for their own setup but users need to know they can configure
the Torouter by connecting to the second ethernet port and configuration
will be provided if they are familiar with using ssh to connect to a
Debian machine.
Tor will run as a service configured as a bridge. The bridge will be
capped and configured with a torrc that is mentioned in
[[wiki:/doc/TorDreamPlug]]. It will bind to {{{eth0}}} only.
This means that by default Torouter will only bind to a single TCP port on
eth0 and eth1 will have a full network like any other NAT device that is
NAT'ed via the eth0 device.
The wireless network will be configured to transparently route Tor but it
will be left in the down state. This means that a user can bring up the
wifi with a configuration command. If the user brings up the interface and
anyone joins the network, the network should provide a splash page to
ensure that any user of the transparent network gives informed consent
before actually sending packets out of the network. It should also be
possible to set specific devices that are forever remembered or even to
configure the network to never pop up a splash page. Once this splash page
is implemented, we will turn on the wifi network by default.
The device will automatically keep time synced with {{{openntpd}}} and it
will be configured to only keep very minimal logs.
The device will have a firewall with {{{ufw}}} as the policy manager. It
will drop all packets on eth0 that are not related to the Tor bridge
operation. It will respond to icmp and all services offered on eth1. The
firewall policy for the wireless network interface is more complex and
will be handled when we enable it by default - more discussion is
required.
This will ship with the Tor 0.2.3.x branch to attempt to use the NAT-PMP
and UPNP support ala {{{tor-fw-helper}}}.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3477#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs