mightofcode / android-vpnservice-example Goto Github PK

只拦截tcp udp 53端口流量，即dns流量，并申请本机的127.0.0.1:53或127.0.0.1:5453解析IP，端口最好可定制

private ByteBuffer remoteOutBuffer = ByteBuffer.allocate(8 * 1024);
改为
private ByteBuffer remoteOutBuffer = ByteBuffer.allocate(Short.MAX_VALUE);
具体原因我也不太清楚

另外从外网回写时不知能不能多开线程处理呢?
Thread t = new Thread(new WriteVpnThread(vpnOutput, networkToDeviceQueue));
t.start();

我手里有后台给的密钥，用户名，密码，你这个怎么设置参数

Hi, I really like your VPN service. I am looking to be able to see the actual HTTP request and response. I know this can be done in the main activity, where the request is made, but I want to do it through the VPN service.

As an example, say this was the URL: https://jsonplaceholder.typicode.com/todos/1

I'd like to get from the VPN service that URL as well as its response:

{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

as well as the request and response headers.

Do you know how I might achieve this?

请问项目是如何判断 UDP 连接已经结束并释放资源的？

https://github.com/mightofcode/android-vpnservice/blob/228dd77e8db010c81ea3c5b7b258590be5a78f88/app/src/main/java/com/mocyx/basic_client/bio/BioUdpHandler.java#L199-L202

这里似乎是唯一移除 natsession 的地方。但是触发条件仅是发送失败（UDP 发送失败要么是断网要么是服务器地址错误）。如果正常发送完成并接收完回复，udp 连接会自动释放，但 natsession 似乎没有释放。
而且还有一种情况是服务器地址合法，但是服务器不在线，或者服务器不回复，这种情况下是不会出异常的。如果不设置超时，UDP 客户端会一直阻塞在“等待服务器回复”这个阶段。

This seems to be the only place to remove natsession. But the trigger condition is only sending failure (UDP sending failure is either due to disconnection or wrong server address). If the connection is completed and the client have received reply from
the server, the UDP connection will be auto closed, but the natsession does not seem to be released.
There is also a situation where the server address is correct, but the server is not online, or the server does not reply. In this case, there will be no exception. If the timeout is not set, the UDP client will always be blocked in the "waiting for server reply" stage.

大佬，项目需求在你的工程基础上，在handleAck中对pipe.remoteOutBuffer数据加密了，然后通讯失败，在wireshark抓不到任何包，包括tcp握手包，方便加个联系方式交流下吗

E/QCNEJ: |QCNEJ/CndHalConnector| Failed to parse input for notifyDefaultNetworkChanged: java.lang.IllegalArgumentException: Unknown RatType:17
2020-07-14 12:56:59.464 20633-20814/com.mocyx.basic_client E/BioUdpHandler: error
java.net.ConnectException: Network is unreachable
at sun.nio.ch.Net.connect0(Native Method)
at sun.nio.ch.Net.connect(Net.java:466)
at sun.nio.ch.DatagramChannelImpl.connect(DatagramChannelImpl.java:779)
at com.mocyx.basic_client.bio.BioUdpHandler.run(BioUdpHandler.java:174)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:458)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)
2020-07-14 12:56:59.490 1378-2838/? E/GnssLocationProvider: No APN found to select.
2020-07-14 12:56:59.492 1378-2838/? E/GnssLocationProvider: updateNetworkAvailability failed

其中的源码
this.headerLength = (this.dataOffsetAndReserved & 0xF0) >> 2;
这个dataOffsetAnd... 是一个字节 前4位标识tcp 报文头的长度 后4位是6个标志的前4个标志
与0xF0 就是取出前4位
然后这个>> 右移2 就相当于除4 不应该是左移吗？
我觉得这里有问题，应该是左移 而不是右移，你能解释一下吗

想请教一下，vpnservice开启后，拦截了手机浏览器的流量，我在浏览器上面访问了百度的地址，或者发了一个http的请求。我想问一下，在vpnservice里面获取到的是tcp的包，还是http的包。

我看了一天源码了,大概了解了一些流程,启动vpn后系统会把所有数据报传入app服务,读取原始的字节流然后转换成实体类Packet,并添加到队列中,再启动一个线程不断去读取这个队列的数据报进行处理,然后这里我就看不懂了,大概我能明白是通过分析数据报然后自己实现了tcp协议,TcpPipe是tcp的对象里面包含了tcp的握手状态等信息,然后用了一个Map<String, TcpPipe>保存所有的tcp链接,然后我就懵逼了,这个数据报是怎么发出去的,我能理解的是 系统流量转发到vpn服务 vpn服务转发给真正的目标服务器 目标服务器返回给vpn服务 vpn服务再返回给系统

我注意到这个项目几乎完整实现了 TCP 协议：手动进行握手挥手、用缓存处理 packet 到 socket 的组装（包括处理序号、重复包）。但是好像没有处理残包和粘包，没有校验收到的 TCP 包的有效性。要是把这些都做了，那就真的是完整的 TCP 协议了。
但这样工作量是巨大的。不过有一种取巧的办法——二次 NAT，具体实现也很简单：

1. 在 app 里起一个位于 VPN 内部的 TCP server。
2. 从 tun 收到的 TCP 流量，如果发送者不是前述 TCP server，记录一下 natSessions : Map<来源port,目的IP:目的port>，修改目的为前述 TCP server 的 IP 和 port，写回 tun。（一次 NAT）
3. TCP server 收到一个 socket 连接。根据来源 port 查询 natSessions，得到目的 IP 和 port，建立与目的服务器的 socket 连接。然后将 TCP server 的 input 流重定向到真正服务器的 output 流上，output 流类同理。（二次 NAT）
4. 从 tun 收到的 TCP 流量，如果发送者是前述 TCP server，根据目的 port（原来源客户端 port）查询 natSessions，得到来源 IP 和 port（原目的服务器 IP 和 port），修改数据包来源，写回 tun。
5. 当连接关闭时，natSessions 做相应移除。

这样不用手动处理 TCP 包，不用实现 TCP 协议栈。