[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