Comments (14)
As for the routing needed - you need to add routes for ip route add 10.0.0.0/8 dev utun4
(you need the ip
Homebrew cask installed).
from rust-tun.
Had the same issue a couple of months before.
I was unfortunately not able to figure out the cause and had to switch to another library (tunio
), which is having issues assigning addresses to TUN interfaces.
from rust-tun.
I am also confused by this. The tun
in my code is created as
fn main() {
let mut config = tun::Configuration::default();
config.address((10, 0, 0, 1))
.netmask((255, 255, 255, 0))
.up();
let mut dev = tun::create(&config).unwrap();
let mut buf = [0; 4096];
loop {
let amount = dev.read(&mut buf).unwrap();
println!("{:?}", &buf[0 .. amount]);
}
}
Then running the command ifconfig -a
, I can see the created tun
device:
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.1 --> 10.0.0.255 netmask 0xffffff00
The address is exactly the set one. However, when I run ping 10.0.0.2
, I cannot see any prints in my program. What's the wrong here? Is it caused by I didn't set the "route"? What value should I set for the "route" and how do I run ping
to see the reaction?
from rust-tun.
I am also confused by this. The
tun
in my code is created asfn main() { let mut config = tun::Configuration::default(); config.address((10, 0, 0, 1)) .netmask((255, 255, 255, 0)) .up(); let mut dev = tun::create(&config).unwrap(); let mut buf = [0; 4096]; loop { let amount = dev.read(&mut buf).unwrap(); println!("{:?}", &buf[0 .. amount]); } }Then running the command
ifconfig -a
, I can see the createdtun
device:utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.255 netmask 0xffffff00
The address is exactly the set one. However, when I run
ping 10.0.0.2
, I cannot see any prints in my program. What's the wrong here? Is it caused by I didn't set the "route"? What value should I set for the "route" and how do I runping
to see the reaction?
The route on MacOS needs to be set manually, unfortunately.
See my comment above.
from rust-tun.
The route on MacOS needs to be set manually, unfortunately.
Could you please tell me what value I should manually set for the "route"? Should I set the value with 192.168.2.21
, which is my physical address? Or, it can be arbitrary ipv4 address as I want?
from rust-tun.
The route on MacOS needs to be set manually, unfortunately.
Could you please tell me what value I should manually set for the "route"? Should I set the value with
192.168.2.21
, which is my physical address? Or, it can be arbitrary ipv4 address as I want?
For the TUN interface you posted, the appropriate route would probably be:
ip route add 10.0.0.0/24 dev utun3
from rust-tun.
The route on MacOS needs to be set manually, unfortunately.
Could you please tell me what value I should manually set for the "route"? Should I set the value with
192.168.2.21
, which is my physical address? Or, it can be arbitrary ipv4 address as I want?For the TUN interface you posted, the appropriate route would probably be:
ip route add 10.0.0.0/24 dev utun3
Thanks, It works for me. What does the route mean here? Why should I set it as 10.0.0.0/24
and then it will work? If I set it as 192.168.10.0
, will it work?
from rust-tun.
The route on MacOS needs to be set manually, unfortunately.
Could you please tell me what value I should manually set for the "route"? Should I set the value with
192.168.2.21
, which is my physical address? Or, it can be arbitrary ipv4 address as I want?For the TUN interface you posted, the appropriate route would probably be:
ip route add 10.0.0.0/24 dev utun3
Thanks, It works for me. What does the route mean here? Why should I set it as
10.0.0.0/24
and then it will work? If I set it as192.168.10.0
, will it work?
It depends on what traffic you want to send over the tunnel.
If you want to route traffic to devices with IP addresses in a 192.168.10.0/24
subnet, you will need to set the routes appropriately, eg. 192.168.10.0/24 dev utun3
.
from rust-tun.
If you want to route traffic to devices with IP addresses in a 192.168.10.0/24 subnet, you will need to set the routes appropriately, eg. 192.168.10.0/24 dev utun3.
Thanks. IIUC, this means, all access to 192.168.10.x
will be processed by untun3
, right?
from rust-tun.
If you want to route traffic to devices with IP addresses in a 192.168.10.0/24 subnet, you will need to set the routes appropriately, eg. 192.168.10.0/24 dev utun3.
Thanks. IIUC, this means, all access to
192.168.10.x
will be processed byuntun3
, right?
Yes.
from rust-tun.
@M0dEx Hi, I still have an issue with the routing, If I set the routing to 10.0.0.0/24
via
ip route add 10.0.0.0/24 dev utun3
Then, with the ICMP packet
source ip: 10.0.0.1, dest ip: 10.0.0.2
which is produced by ping 10.0.0.2
and this request is delivered to my program via utun3, then I write the echo-reply
packet with source ip: 10.0.0.2, dest ip: 10.0.0.1
to utun3
, and the ping command
successfully receives the response. In this whole progress, I have a doubt: Why was my response packet not re-delivered to my "tun" program again, which would cause the infinite loop, IIUC?
My prior understanding is that if I set the route with 10.0.0.0/24
to my utun3, then all associated packets with 10.0.0.x
would be delivered to my utun3
program, with this understanding, the response packet with source ip 10.0.0.2
and destination ip 10.0.0.1
are exactly relevant, however, this packed written by my utun3 program didn't re-delivered to my program, I just wonder why? Any answers would be appreciated.
from rust-tun.
@M0dEx Hi, I still have an issue with the routing, If I set the routing to
10.0.0.0/24
viaip route add 10.0.0.0/24 dev utun3
Then, with the ICMP packet
source ip: 10.0.0.1, dest ip: 10.0.0.2
which is produced by
ping 10.0.0.2
and this request is delivered to my program via utun3, then I write theecho-reply
packet withsource ip: 10.0.0.2, dest ip: 10.0.0.1
toutun3
, and theping command
successfully receives the response. In this whole progress, I have a doubt: Why was my response packet not re-delivered to my "tun" program again, which would cause the infinite loop, IIUC?My prior understanding is that if I set the route with
10.0.0.0/24
to my utun3, then all associated packets with10.0.0.x
would be delivered to myutun3
program, with this understanding, the response packet with source ip10.0.0.2
and destination ip10.0.0.1
are exactly relevant, however, this packed written by my utun3 program didn't re-delivered to my program, I just wonder why? Any answers would be appreciated.
This is because the utun3
interface itself has the IP 10.0.0.1
. This means that when a packet is received, on that interface, with that IP, it gets sent to whatever application is associated with the socket specified by the destination IP (and port, if applicable). In your case, this application was the ping
command, so the responses with destination IP 10.0.0.1
got "routed" to it.
from rust-tun.
Thanks, that means, I don't need to worry about a packet written by the utun3
program "reflux" into the utun3
program again if the destination IP of the packet is the address of the utun3
devices, In my example it's 10.0.0.1
, right?
So, it seems to be the interpretation of the example of the simpletun. The client ran on machine A
with the tun device configured with:
6.6.6.1/24
and its real physical address of eth0
is 192.168.1.10
. On machine B
, which is the tun server, whose tun device has the configuration:
6.6.6.2/24
the physical address of B
is 192.168.1.15
. Then on machine A
, running the command ping 10.0.0.2
, the produced packet will be processed by the "tun program" of A
, it sends the packet via TCP to machine B
(192.168.1.10 -> 192.168.1.15
), then B
reads the packet from TCP socket, the acquired packet(from the network) will be directly written into the tun device of B
, then B
reads the associated result from tun
and deliver the result via TCP to A
.
In this whole process, note the emphasized part, the packet with source ip: 10.0.0.1, destination ip: 10.0.0.2
is directly written into the tun of B
, IIUC, the reason why this packet didn't reflux into tun program of B
again is because of the destination IP in this packet is that of the tun
of B
, right? Then this packet will be delivered to an appropriate program that can resolve this packet, then the produced packet from that program will have source ip: 10.0.0.2, destination ip: 10.0.0.1
, and in this packet, the destination IP is 10.0.0.1
, which is not the address of tun on B
(that is 10.0.0.2
), hence this packet will be delivered to tun program
of B
, so, this is the reason why tun program
of B
can read the resulting packet(ICMP reply) from tun
device, right?
from rust-tun.
This is because the utun3 interface itself has the IP 10.0.0.1. This means that when a packet is received, on that interface, with that IP, it gets sent to whatever application is associated with the socket specified by the destination IP (and port, if applicable).
I'm not sure whether I 100% understand your answers. With the default code in https://github.com/meh/rust-tun/blob/master/examples/ping-tun.rs, and set the route for utun3
in my machine
ip route add 10.0.0.0/24 dev utun3
When I run the command ping 10.0.0.1
, this produced packet is still routed to the utun3
program, The packet has src IP: 10.0.0.1, dest IP: 10.0.0.1
, as interpreted in your answer, this packet should just not be processed by my utun program
since the destination IP of the packet is the address of the tun device. Or, you just mean when writing packet
to the utun device
via the utun program
, the packet with a destination IP that is the same as that of the address of utun devices won't be re-read by utun program
itself again.
from rust-tun.
Related Issues (20)
- 4 bytes header on macos HOT 3
- Support iOS and Android HOT 3
- Allow shared Read and Write for Device
- Windows support HOT 15
- request tokio 1.x supported HOT 10
- Receiving packets even when I shouldn't be HOT 3
- ios15 HOT 2
- Socket operation on non-socket HOT 1
- macos HOT 1
- Framed send fails with "Socket operation on non-socket" HOT 3
- Drop Fd crash in Android 11 HOT 1
- Nothing happening on macOS HOT 2
- Use library with default gateway
- Where is the tun tap frame? HOT 1
- Build error on windows HOT 1
- GRO/GSO on Linux HOT 1
- macOS tun ip cannot be listened by the application
- The synchronous `write` does not work HOT 1
- when change ip addr to new ip addr, but subnet broadcast address no change, in macos m1 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-tun.