Udp lyukasztás szimmetrikus nat egy kis elmélet és szinte őszinte kísérlet, savepearlharbor

A napi idő, kollégák.

Néhány évvel ezelőtt érdekelt a sabzh. A keresés rengeteg anyagot adott, melynek tanulmányozásakor számos kérdés merült fel, és néhány gyakorlati elméletet próbáltam tesztelni. Kit érdekel - kérdezem.

Azok számára, akik röviden nem foglalkoznak a témával a szimmetrikus NAT-val.

Tekintsünk egy egyszerű rendszert, amelyben

host1, host2 - a felhasználók NAT-ok mögött
A NAT1, NAT2 olyan peremeszközök, amelyek NAT-t biztosítanak

Amikor host1 kezdeményez kimenő kapcsolat (TCP vagy UDP) a realnyy_IP, NAT1 készülék helyettesíti a kimenő IP csomag forrás egy (adott esetben a saját, hanem elfogadja azt az egyszerűség kedvéért és tisztaság), valamint általában helyettesíti PORT_SRC véletlenszerűen PORT_SRC1.

host1 ____ PORT_SRC, PORT_DST -> NAT1 eszköz PORT_SRC1, PORT_DST -> real_IP

Mi van akkor, amikor a feladat a "szétszórni" egy szimmetrikus NAT-t, és lehetővé teszi a gazda számára, hogy közvetlenül kommunikáljon vele?

Az általános esetben az alábbi egyszerű módszerrel rendelkezünk.

host1 -> NAT1 SRC1_random, DST1_with-wish ->

<— DST2_по_желанию, SRC2_случайный NAT2 <— хост2

SRC1_Random - forrás port NAT-helyettesítés után NAT1-vel;
DST1_wanted - a kimenő kapcsolat cél portja, amelyet a host1-tel hoz létre a NAT1-en keresztül, ki lehet választani;
DST2_without - a host2-től NAT2-től NAT1-ig küldött csomag célállomásai közül választhatunk;
SRC2_Random - forrás port NAT helyettesítés után NAT2-vel.

Ha megnézzük közelebbről ezt shemku, a nehézséget, hogy „lebontani” nyilvánvalóak. Annak érdekében, hogy kicseréljék a forgalom zarbotal kell teljesülnie: SRC1_sluchayny = DST2_po_zhelaniyu és DST1_po_zhelaniyu = SRC2_sluchayny.
A Host1 és a host2 eszközök nem tudják vezérelni az SRC1_Random és az SRC2_Random portokat. Általában véletlenszerűek lesznek, plusz a cél IP és a rendeltetési port. Az ezen a témában végzett keresés során talált anyagok tömege figyelmen kívül hagyta ezt az egyszerű tényt, figyelembe véve, hogy egy egyszerű STUN szerver elég ismerni ezeket az ismeretleneket.
Mintha igen. Ha a NAT-ot használjuk, az iptables használatával szervezzük, majd az űrlap konstrukcióit

-t nat -A POSTROUTING -j MASQUERADE
vagy
-t nat -A POSTROUTING -j SNAT -forrás

csak a forrás IP-t cseréli le, a kimenő port ugyanaz marad, mint az ügyfél. Így a feladat nagymértékben leegyszerűsödik, és a közvetítő szerepének leírására szolgáló cikkek tömegét írja le a NAT traversal technológiára.
De ez egy magán és egyszerű eset.

Ugyanezen iptables esetén ezek a konstrukciók helyettesíthetők

-t nat -A POSTROUTING -j MASQUERADE ... -véletlen
vagy
-t nat -A POSTROUTING -j SNAT -forrás ... -véletlen

és a helyzet kevésbé lesz szórakoztató. A kimenő port kiválasztása NAT konverzióval történik véletlenszerűen.

Teljesen, a fenti diagramok közeli megvizsgálása után a következő problémák merülnek fel.

Sem host1 vagy host2 tudatában SRC1_sluchayny és SRC2_sluchayny őket befolyásolni azokat csak közvetetten, például, ez változik a kimenő csomagokat source port vagy elegendő timeout között az adatokat küldő volna, hogy bejegyzéseket NAT-adások NAT-eszközök ideje, hogy elavult, összehajtható .
A Host2-nek többek között meg kell tanulnia a DST1_willing-et (általában a portot előre lehet tárgyalni, de a legrosszabb esetet fogjuk figyelembe venni).

A közvetítő igényének hosszú magyarázataival nem foglalkozom, azonnal bemutatom az összes csereprogram résztvevõinek cselekvõ hozzávetõleges algoritmusait.

1. Szigorúan szükséges egy olyan közvetítő, amellyel a host1 és a host2 teljes körű kapcsolatot létesítenek a szabad kétirányú forgalomkal. Az ilyen ellenőrzési ülések kezdeményezői a NAT hostjai. A közvetítő a fehér IP-címről információt szolgáltat a végső hostok között.

2. Tegyük fel, hogy a host1 lesz a célkapcsolat / kliens kezdeményezője, és a host2 számára a kapcsolat bejövő lesz, vagyis kiszolgálóként fog működni.

4. host1 a vezérlő kapcsolat tájékoztatja a közvetítő a kiválasztott DST1_po_zhelaniyu és továbbra is küld csomagokat az azonos paraméterekkel (forrás port, cél port), hogy állandó sugárzott NAT1, hogy nem fogja megváltoztatni SRC1_sluchayny. A késleltetés oszlopok között, kísérleti úton meghatározható, mert egy triviális feladat nem az, hogy festeni, és nem szerepel a szövegben.

6. A közvetítő beszámol a vezérlőcsatornáról a host2 SRC1_random számára.

Amint látja, az általános esetben a szimmetrikus NAT lebontása nem olyan egyszerű és gyors feladat. Néhány implementációnál (emlékezzen az iptables-re), lényegesen leegyszerűsíthető, és garantált sikeres eljárássá válhat, de az általános esetben sem.
Melyek a leírt algoritmus legszűkebb helyei?

1. Az 5. pontban szereplő meghamisítás szükségessége. A közvetítőnek olyan módon kell hozzáférnie a hálózathoz, amely lehetővé tenné a szolgáltató problémáinak megoldása nélkül.

(3) A (7) bekezdésben foglalt intézkedések határozatlan ideig hosszúak lehetnek. Csak ez a pillanat okozta a kíváncsiságomat és a vágyamat.

5 csomag másodpercenként. A NAT2 router ugyanakkor kevéssé terhelt az idegenek (a felhasználók hallani) a forgalom.
Az első "lebontás" körülbelül 8 órával történt a kísérlet kezdete után. Aztán történt még néhány darab, mert az egész farmot az éjszakára dolgozták. A későbbiekben többször is gyorsabban megtörtént, akkor fantáziálhat az "idegen" forgalom hatásairól.

Ez volt a "bontás". A következtetés szelektív, amely csak "boldog" csomagokat tartalmaz, a szükséges véletlen egybeeséssel.

A kimeneti sznorkeresztő a "forgalmas" forgalmi gyűjtemény pontjában, amelyben az (forgalom) látható a NAT után az AR-750 útválasztó külső interfészén

02: 19: 05.060809 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, hossza 0
05: 07: 00.178149 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, hossza 0
06: 28: 35.355623 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, hossza 0
07: 16: 29.764069 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, hossza 0
11: 28: 06.899109 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, hossza 0

Következtetés szippantás a hoste1, ahol a „bevágás” a minta (az idő nem szinkronizált, így a kismértékű eltérés az időbélyegek nyomtatott hosta2 forgalmi billenő).

02: 18: 20.480468 IPxx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, hossza 0
05: 06: 15.496093 IP xx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, hossza 0
06: 27: 50.464843 IPxx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, hossza 0
07: 15: 44.839843 IP xx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, hossza 0
11: 27: 21.589843 IPxx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, hossza 0

Volt egy dump eredmény közvetlenül a gazdagépen2, amelyben látszott, hogy a változatlan NAT1-et támogató csomagok a 4-es ponttól kezdve a host2-ig terjednek, de elvetettem.

Ez nem teljesen őszinte kísérlet. De kimutatta, hogy még a viszonylag alacsony mintavételi gyakoriság mellett a 7. pontban a kívánt eredmény viszonylag ésszerű idő alatt érhető el. Még agresszívabb keresésben is érzékenyebbé válhat. Természetesen az "ipari" alkalmazás nem húzza, de ... de lehetséges. A leírt algoritmus és kísérlet gondoskodik a gyorsítás-optimalizálás témájáról - egy több menetes megközelítés és hasonlók.