馬太福音 25:29
因為凡有的，還要加給他，叫他有餘；沒有的，連他所有的也要奪過來。
【論語‧為政第二】
子張問十世可知也。子曰：殷因於夏禮，所損益，可知也。周因於殷禮，所損益，可知也。其或繼周者，雖百世可知也。
風雷益 ☴ ☳
益：利有攸往，利涉大川。
彖曰：益，損上益下，民說無疆，自上下下，其道大光。利有攸往，中正有慶。 利涉大川，木道乃行。 益動而巽，日進無疆。 天施地生，其益無方。 凡益之道，與時偕行。
象曰：風雷，益﹔君子以見善則遷，有過則改。
初九：利用為大作，元吉，無咎。
象曰：元吉無咎，下不厚事也。
六二：或益之，十朋之龜弗克違，永貞吉。 王用享于帝，吉。
象曰：或益之，自外來也。
六三：益之用凶事，無咎。 有孚中行，告公用圭。
象曰：益用凶事，固有之也。
六四：中行，告公從。 利用為依遷國。
象曰：告公從，以益志也。
九五：有孚惠心，勿問元吉。 有孚惠我德。
象曰：有孚惠心，勿問之矣。 惠我德，大得志也。
上九：莫益之，或擊之，立心勿恆，凶。
象曰：莫益之，偏辭也。 或擊之，自外來也。
─── 《馬太福音 25:29；》
為著解決
網際協定版本4（英語：Internet Protocol version 4，IPv4），又稱網際網路通訊協定第四版，是網際協定開發過程中的第四個修訂版本，也是此協定第一個被廣泛部署的版本。IPv4是網際網路的核心，也是使用最廣泛的網際協定版本，其後繼版本為IPv6，直到2011年，IANA IPv4位元址完全用盡時，IPv6仍處在部署的初期。
IPv4在IETF於1981年9月發布的 RFC 791 中被描述，此RFC替換了於1980年1月發布的 RFC 760。
IPv4是一種無連接的協定，操作在使用封包交換的鏈路層（如乙太網路）上。此協定會盡最大努力交付封包，意即它不保證任何封包均能送達目的地，也不保證所有封包均按照正確的順序無重複地到達。這些方面是由上層的傳輸協定（如傳輸控制協定）處理的。
位址
IPv4使用32位元（4位元組）位址，因此位址空間中只有4,294,967,296（232）個位址。不過，一些位址是為特殊用途所保留的，如專用網路（約1800萬個位址）和多播位址（約2.7億個位址），這減少了可在網際網路上路由的位址數量。隨著位址不斷被分配給終端使用者，IPv4位址枯竭問題也在隨之產生。基於分類網路、無類別域間路由和網路位址轉換的位址結構重構顯著地減少了位址枯竭的速度。但在2011年2月3日，在最後5個位址塊被分配給5個區域網際網路註冊管理機構之後，IANA的主要位址池已經用盡。
這些限制刺激了仍在開發早期的IPv6的部署，這也是目前唯一的長期解決方案。
『不足』的問題，故而『益』之以
Network address translation (NAT) is a method of remapping one IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device.[1] The technique was originally used as a shortcut to avoid the need to readdress every host when a network was moved. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.
IP masquerading is a technique that hides an entire IP address space, usually consisting of private IP addresses, behind a single IP address in another, usually public address space. The address that has to be hidden is changed into a single (public) IP address as “new” source address of the outgoing IP packet so it appears as originating not from the hidden host but from the routing device itself. Because of the popularity of this technique to conserve IPv4 address space, the term NAT has become virtually synonymous with IP masquerading.
As network address translation modifies the IP address information in packets, it has serious consequences on the quality of Internet connectivity and requires careful attention to the details of its implementation. NAT implementations vary widely in their specific behavior in various addressing cases and their effect on network traffic. The specifics of NAT behavior are not commonly documented by vendors of equipment containing NAT implementations.[2]
怎知卻引發了
Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads between peers. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes.
Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts.[1] Peers are both suppliers and consumers of resources, in contrast to the traditional client-server model in which the consumption and supply of resources is divided. Emerging collaborative P2P systems are going beyond the era of peers doing similar things while sharing resources, and are looking for diverse peers that can bring in unique resources and capabilities to a virtual community thereby empowering it to engage in greater tasks beyond those that can be accomplished by individual peers, yet that are beneficial to all the peers.[2]
While P2P systems had previously been used in many application domains,[3] the architecture was popularized by the file sharing system Napster, originally released in 1999. The concept has inspired new structures and philosophies in many areas of human interaction. In such social contexts, peer-to-peer as a meme refers to the egalitarian social networking that has emerged throughout society, enabled by Internet technologies in general.
『應用』難題！
Bryan Ford
Massachusetts Institute of Technology
baford (at) mit.edu
Pyda Srisuresh
Caymas Systems, Inc.
srisuresh (at) yahoo.com
Dan Kegel
dank (at) kegel.com
J’fais des trous, des petits trous …
toujours des petits trous
– S. Gainsbourg
Network Address Translation (NAT) causes well-known difficulties for peer-to-peer (P2P) communication, since the peers involved may not be reachable at any globally valid IP address. Several NAT traversal techniques are known, but their documentation is slim, and data about their robustness or relative merits is slimmer. This paper documents and analyzes one of the simplest but most robust and practical NAT traversal techniques, commonly known as “hole punching.” Hole punching is moderately well-understood for UDP communication, but we show how it can be reliably used to set up peer-to-peer TCP streams as well. After gathering data on the reliability of this technique on a wide variety of deployed NATs, we find that about 82% of the NATs tested support hole punching for UDP, and about 64% support hole punching for TCP streams. As NAT vendors become increasingly conscious of the needs of important P2P applications such as Voice over IP and online gaming protocols, support for hole punching is likely to increase in the future.
於是乎『打洞技術』方興起耶？
1 Introduction
The combined pressures of tremendous growth and massive security challenges have forced the Internet to evolve in ways that make life difficult for many applications. The Internet’s original uniform address architecture, in which every node has a globally unique IP address and can communicate directly with every other node, has been replaced with a new de facto Internet address architecture, consisting of a global address realm and many private address realms interconnected by Network Address Translators (NAT). In this new address architecture, illustrated in Figure 1, only nodes in the “main,” global address realm can be easily contacted from anywhere in the network, because only they have unique, globally routable IP addresses. Nodes on private networks can connect to other nodes on the same private network, and they can usually open TCP or UDP connections to “well-known” nodes in the global address realm. NATs on the path allocate temporary public endpoints for outgoing connections, and translate the addresses and port numbers in packets comprising those sessions, while generally blocking all incoming traffic unless otherwise specifically configured.
Figure 1: Public and private IP address domains
 |
The Internet’s new de facto address architecture is suitable for client/server communication in the typical case when the client is on a private network and the server is in the global address realm. The architecture makes it difficult for two nodes on different private networks to contact each other directly, however, which is often important to the “peer-to-peer” communication protocols used in applications such as teleconferencing and online gaming. We clearly need a way to make such protocols function smoothly in the presence of NAT.
One of the most effective methods of establishing peer-to-peer communication between hosts on different private networks is known as “hole punching.” This technique is widely used already in UDP-based applications, but essentially the same technique also works for TCP. Contrary to what its name may suggest, hole punching does not compromise the security of a private network. Instead, hole punching enables applications to function within the the default security policy of most NATs, effectively signaling to NATs on the path that peer-to-peer communication sessions are “solicited” and thus should be accepted. This paper documents hole punching for both UDP and TCP, and details the crucial aspects of both application and NAT behavior that make hole punching work.
Unfortunately, no traversal technique works with all existing NATs, because NAT behavior is not standardized. This paper presents some experimental results evaluating hole punching support in current NATs. Our data is derived from results submitted by users throughout the Internet by running our “NAT Check” tool over a wide variety of NATs by different vendors. While the data points were gathered from a “self-selecting” user community and may not be representative of the true distribution of NAT implementations deployed on the Internet, the results are nevertheless generally encouraging.
While evaluating basic hole punching, we also point out variations that can make hole punching work on a wider variety of existing NATs at the cost of greater complexity. Our primary focus, however, is on developing the simplest hole punching technique that works cleanly and robustly in the presence of “well-behaved” NATs in any reasonable network topology. We deliberately avoid excessively clever tricks that may increase compatibility with some existing “broken” NATs in the short term, but which only work some of the time and may cause additional unpredictability and network brittleness in the long term.
Although the larger address space of IPv6 [3] may eventually reduce the need for NAT, in the short term IPv6 is increasing the demand for NAT, because NAT itself provides the easiest way to achieve interoperability between IPv4 and IPv6 address domains [24]. Further, the anonymity and inaccessibility of hosts on private networks has widely perceived security and privacy benefits. Firewalls are unlikely to go away even when there are enough IP addresses: IPv6 firewalls will still commonly block unsolicited incoming traffic by default, making hole punching useful even to IPv6 applications.
The rest of this paper is organized as follows. Section 2 introduces basic terminology and NAT traversal concepts. Section 3 details hole punching for UDP, and Section 4 introduces hole punching for TCP. Section 5 summarizes important properties a NAT must have in order to enable hole punching. Section 6presents our experimental results on hole punching support in popular NATs, Section 7 discusses related work, and Section 8 concludes.
『派生』愛好者或可讀一讀
Python实现NAT穿透+STUN+TURN+P2P聊天 | Python P2P chat
PyPunchP2P
THIS PROJECT IS FOR STUDYING AND VERIFICATION, DON’T USE IT IN PRODUCTION.
Python p2p chat client/server with built-in NAT traversal (UDP hole punching).
I’ve written an article about the detailed implementation (in Chinese).
Based on
koenbollen’s gist
pystun
Peer-to-Peer Communication Across Network Address Translators
Python edition: py2.6+ but no Python 3 support
Platform: Linux/Windows
Usage
Suppose you run server.py on a VPS with ip 1.2.3.4, listening on port 5678
client.py 1.2.3.4 5678 100
The number 100 is used to match clients, you can choose any number you like but only clients with the same number will be linked by server. If two clients get linked, two people can chat by typing in terminal, and once you hit <ENTER> your partner will see your message in his terminal.
Encoding is a known issue since I didn’t pay much effort on making this tool perfect, but as long as you type English it will be fine.
短短的『原始碼』，嘗試深入了解也◎
※ 參考︰
server A 5.168.168.6 ─── OpenWrt 路由器 5.168.168.20 ─── client B 5.168.128.250
【server A】
root@kali-pi:~/test/PyPunchP2P# ./server.py 5678
listening on *:5678 (udp)
connection from 5.168.168.6:56672
pool=100, nat_type=Symmetric NAT, ok sent to client
request received for pool: 100
connection from 5.168.168.20:39029
pool=100, nat_type=Symmetric NAT, ok sent to client
request received for pool: 100
linked 100
Hurray! symmetric chat link established.
msg successfully forwarded to ('5.168.168.6', 56672)
hello
msg successfully forwarded to ('5.168.168.6', 56672)
world
【client A】
root@kali-pi:~/test/PyPunchP2P# ./client.py 5.168.168.6 100
(<open file '<stderr>', mode 'w' at 0x76ce80d0>, 'usage: ./client.py <host> <port> <pool>')
root@kali-pi:~/test/PyPunchP2P# ./client.py 5.168.168.6 5678 100
('NAT Type:', 'Symmetric NAT')
('External IP:', '36.231.56.34')
('External Port:', 1026)
(<open file '<stdout>', mode 'w' at 0x76cc5078>, "request sent, waiting for partner in pool '100'...")
(('5.168.168.20', 39029), 3)
(<open file '<stdout>', mode 'w' at 0x76cc5078>, 'connected to 5.168.168.20:39029, its NAT type is Symmetric NAT')
Symmetric chat mode
hello
world
【client B】
root@kali:~/test/PyPunchP2P# ./client.py 5.168.168.6 5678 100
('NAT Type:', 'Symmetric NAT')
('External IP:', '36.231.56.34')
('External Port:', 1027)
(<open file '<stdout>', mode 'w' at 0x76d50078>, "request sent, waiting for partner in pool '100'...")
(('5.168.168.6', 56672), 3)
(<open file '<stdout>', mode 'w' at 0x76d50078>, 'connected to 5.168.168.6:56672, its NAT type is Symmetric NAT')
Symmetric chat mode
hello
world
The idea behind Blue Pill is simple: your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin Blue Pill hypervisor. This all happens on-the-fly (i.e. without restarting the system) and there is no performance penalty and all the devices, like graphics card, are fully accessible to the operating system, which is now executing inside virtual machine. This is all possible thanks to the latest virtualization technology from AMD called SVM/Pacifica.
nat-traverse 40000:natgw-of-right:40001
Example 