NAME¶
etherpuppet
—
create a virtual interface from a remote Ethernet
interface
SYNOPSIS¶
etherpuppet |
[ -s
port ]
[-c
target:port ]
[-B ]
[-S ]
[-M
filter ]
[-C ]
[-i
iface ] |
etherpuppet |
[ -m ]
[-s
port ]
[-c
target:port ]
[-I
iface ] |
DESCRIPTION¶
etherpuppet
is a small program that will
create a virtual interface
(TUN/TAP) on one
machine from the ethernet interface of another machine through a TCP
connection. Everything seen by the real interface will be seen by the virtual
one. Everything sent to the virtual interface will be emitted by the real one.
It has been designed because one often has a small machine as his Internet
gateway, and sometimes want to run some big applications that need raw access
to this interface, for sniffing (Ethereal, etc.) or for crafting packets that
do not survive being reassembled, NATed, etc.
When launched with the first syntax,
etherpuppet
is a slave that will send to
its master everything that passes on the given interface. With the second
syntax,
etherpuppet
is the master and will
create the special
TAP device (whose default name
starts with
puppet. In both modes,
etherpuppet
is able to either connect or
listen to its slave/master.
Traffic seen by the real interface is sent through the TCP connection to the
doll interface. Thus, it is important that this connection is not seen by the
real interface (or else, we'll have a cute infinite traffic loop).
The options are as follows:
-s
port
- Listen on the given TCP port.
-c
ip:port
- Connect to the slave/master on the given IP/port.
-i
iface
- Vampirize the given interface name.
-I
ifname
- Choose the name of the virtual interface.
-m
- Master mode.
-B
- Do not use BPF. With this option,
etherpuppet
may see its own
traffic.
-S
- Build BPF with the content of
SSH_CONNECTION environment variable.
-M
src:sp,dst:dp
- Build manually a BPF filter that will exclude
matching traffic in both directions.
-C
- Do not copy real interface parameters to virtual interface.
The source and destination are by default the TCP connection end points. If you
go through SSH tunneling, you can use the
-S
option to use
SSH_CONNECTION environment variable content
instead, so that you will filter out the SSH connection of your current
session and not the connection to the local SSH tunnel end point (which is
pointless). If this still not fit your needs, you can manually specify the
connection end points with
-M
.
If you connect two Etherpuppet instances in master mode, you'll get a TCP tunnel
through virtual interfaces.
If you connect two Etherpuppet instances in slave mode, you may get some kind of
inefficient distributed bridge, but more probably, you'll get a big mess.
AUTHORS¶
The
etherpuppet
program was written by
Philippe Biondi
⟨phil@secdev.org⟩.
This manual page was written by
Vincent
Bernat ⟨bernat@debian.org⟩, for the Debian project (but
may be used by others).