pwnat - The only tool/technique to punch holes through fir

项目说明

pwnat -

pwnat, by Samy Kamkar, is a 工具 that allows any 客户端
behind a NAT to communicate with a ser a
separate NAT with no port forwarding and no DMZ
setup on any routers in order to directly communicate
with each other.

There is no middle man, no proxy, no third party, no UPnP
required, no spoofing, no DNS tricks. The 服务端 does
not need to know the 客户端's IP address before connecting.

More importantly, the 客户端 can then connect to any
host or port on any remote host or to a fixed host and
port decided by the server.

Simply put, this is a proxy 服务端 that works behind a NAT,
even when the 客户端 is also behind a NAT.

> You can read the paper published in IEEE and presented at
the IEEE P2P'10 Conference here

EXAMPLE

Server side allowing anyone to proxy:

客户端 wanting to connect to google.com:80:

Then, browse to to visit google!

FAQ

* Ok, so does this really work?

> Yes. Try it!

* I'm confused. This can't work.

> You should be, and it does work.

* But it can't. My NAT blocks incoming packets and so will the other.
I know. But how?!

> Great question! I thought you'd never ask.
Look below at HOW DOES IT WORK?

* Does this use DNS for anything?

> No.

* Do I need to setup port forwarding or a DMZ on either end?

> No.

* Is there some sort of proxy or 3rd party that tunnels information between
the two NATs?

> No. The connection is direct, 客户端 to 服务端.

* Will this work behind my corporate NAT and firewall?

> This will work behind many NATs and firewalls, but not all.

* What uses does this have?

> This will allow you to tunnel any service that you want to run (http,
ssh, quake 服务端, IRC, ftp, etc.) through your NAT, or proxy into
other remote servers.

* What if one or both ends aren't behind a NAT?

> E will work just as well. You can use pwnat to tunnel TCP
payload over UDP if you wish; no NATs are necessary.

* Does the 服务端 have to specify the 客户端 host?

> No! The ser't know the 客户端 IP address until the 客户端
attempts to connect, penetrating the NAT using this unique method.

HOW DOES IT WORK?

My method of penetrating NATs is two-fold which I will describe below.

In order for the full tunnel to be established, the 客户端 side needs to
know the public IP address of the 服务端, and the ser to learn
the public IP address of the client.

However, in a true 客户端-ser, the ser't know the 客户端 IP
until the 客户端 connects, and NATs will normally drop unknown incoming packets.
In pwnat, the 服务端 also does not need to know the 客户端 IP address.

Here is how the pwnat ser the IP address of the client:
I get around this by having the 客户端 "pretend" to be a random hop on
the Internet. I'm essentially using the same technology a traceroute uses
to detect hops on the Internet, but I'm doing the reverse in order to
penetrate the NAT.

Specifically, when the ser up, it begins sending fixed ICMP echo
request packets to the fixed address 3.3.3.3. We expect that these packets
won't be returned.

Now, 3.3.3.3 is *not* a host we have any access to, nor will we end up spoofing
it. Instead, when a 客户端 wants to connect, the 客户端 (which knows the 服务端
IP address) sends an ICMP Time Exceeded packet to the 服务端. The ICMP packet
includes the "original" fixed packet that the 服务端 was sending to 3.3.3.3.

Why? Well, we're pretending to be a hop on the Internet, politely telling the
服务端 that its original "ICMP echo request" packet couldn't be delivered.
Your NAT, being the gapingly open device it is, is nice enough to notice that
the packet *inside* the ICMP time exceeded packet matches the packet the 服务端
sent out. It then forwards the ICMP time exceeded back to the ser
the NAT, *including* the full IP header from the 客户端, thus allowing the
服务端 to know what the 客户端 IP address is!

服务端 (1.2.3.4): ICMP Echo Request -> 3.3.3.3
...
服务端 (1.2.3.4): ICMP Echo Request -> 3.3.3.3
...
服务端 (1.2.3.4): ICMP Echo Request -> 3.3.3.3
...
客户端 (6.7.8.9): ICMP Time Exceeded (includes ICMP Echo Request to 3.3.3.3) -> 1.2.3.4
服务端's NAT: Sees 服务端's Echo Request in 客户端's Time Exceeded packet,
sends entire packet to ser it matches 服务端's outgoing packet

Don't believe me? Just traceroute any host behind your NAT. You'll notice
incoming packets coming in from random IP addresses your router knows
nothing about. Your router knows to send those back to you, rather than another
客户端 on your 网络, based off of the data inside the ICMP time exceeded packet.

Now, the 服务端 has only learned the 客户端 IP address. We still have no
method to send any additional data. For the full communication, we use the
same method used in my previous software, chownat, to penetrate both NATs.

Example of a 客户端 behind a NAT talking to a machine NOT behind a NAT:
Machine A -> NAT A -> net -> quake 服务端

Machine A sends a UDP packet to quake 服务端, opening a "session".
NAT A sees this and says:
"If any UDP packets come back soon with the same host and port info,
I'm routing it to machine A."
Quake ser UDP packets back, hits NAT A, and NAT A seeing the right
hosts and ports, sends it to machine A. Machine A and quake 服务端 are now
able to communicate without any problem.

Now here is how pwnat works now that 客户端 and 服务端 know each others IP.
Goal is: Machine A (ssh 客户端) -> NAT A -> net -> NAT B -> Machine B (ssh 服务端)

When you start up the pwnat 服务端 on machine B, it slowly fires off
UDP packets to machine A. Of course, NAT A is not expecting these so it
drops every one of them. Machine B does not stop.

Once you begin the pwnat 客户端 on machine A, it begins sending UDP
packets to machine B. Note: pwnat defaults source and destination
ports to 2222. Any unpri user can set UDP 源码 and destination ports.
Normally the UDP packets that machine A is sending to NAT B would get dropped.
However, since machine B is sending similar packets OUT, NAT B assumes
these are responses and lets them back in. Once machine B sees these packets,
it sends handshake packets back to machine A. These packets will not get
dropped by NAT A because of the same reason: NAT A sees packets going out, and
the packets coming back to the NAT look like responses to the ones going out.

Finally, both sides are fully communicating over UDP, allowing protocols that
run over TCP to tunnel through.
Note: There is a keep-ali on the pwnat server and client that
always keeps the UDP "session" active. The packets it sends have a 0 byte
payload and are only sent when the 客户端 is not sending data out. Otherwise,
the fastest it will possibly send the keep-ali is one packet every 5
seconds. If any other type of data is tra through the tunnel, no
keep-ali will be transmitted.

by Samy Kamkar

> pwnat is based off of udptunnel by Daniel Meekins here

项目信息

开发语言：C

Star 数：3931

技术要点

该项目属于黑客技术方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕The only 工具/technique to punch holes through firewalls/NATs where multiple clients & 服务端 can be behind separate NATs without any 3rd party in. Pwnat is a newly de technique, exploiting a property of NAT translation tables, with no 3rd party, port forwarding, DMZ, DNS, router admin requirements, STUN/TURN/UPnP/ICE, or spoofing.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。