Era timpul zilei, colegi.
Cu ceva timp în urmă, el a devenit interesat de sabzh. Căutarea a dat o mulțime de materiale, în studiul căruia au apărut o serie de întrebări și am vrut să testez câteva puncte teoretice în practică. Cui este interesant - întreb.
Pentru cei care nu sunt în subiectul scurt despre ceea ce este simetric NAT.
Luați în considerare o schemă simplă în care
host1, host2 - gazde utilizator în spatele NATs
NAT1, NAT2 sunt dispozitive de margine care oferă NAT
Când host1 inițiază o conexiune la ieșire (TCP sau UDP) la un realnyy_IP, dispozitiv NAT1 înlocuiește ieșire sursa de pachete IP la un (opțional, pe cont propriu, dar va accepta din motive de simplitate și claritate), precum și înlocuiește, în general, PORT_SRC la PORT_SRC1 aleatoare.
host1 ____ PORT_SRC, PORT_DST -> dispozitiv NAT1 PORT_SRC1, PORT_DST -> real_IP
Ce avem când sarcina este de a "rupe" un NAT simetric și de a permite gazdei să comunice direct cu acesta?
În cazul general, avem următoarea schemă simplă.
host1 -> NAT1 SRC1_random, DST1_with-wish ->
<— DST2_по_желанию, SRC2_случайный NAT2 <— хост2
Portul sursă SRC1_Random după înlocuirea NAT cu NAT1;
DST1_wanted - portul de destinație pentru conexiunea de ieșire care este stabilit cu host1 prin NAT1, poate fi selectat de noi;
DST2_without - portul de destinație pentru pachetul trimis de la host2 prin NAT2 la NAT1, poate fi selectat de noi;
Portul sursă SRC2_Random după înlocuirea NAT cu NAT2.
Dacă te uiți atent la acest shemku, dificultatea de a „sparge în jos“ sunt evidente. Pentru a face schimb de zarbotal de trafic trebuie să fie îndeplinite: SRC1_sluchayny = DST2_po_zhelaniyu și DST1_po_zhelaniyu = SRC2_sluchayny.
Host1 și host2 nu pot controla porturile SRC1_Random și SRC2_Random. În general, acestea vor fi cu adevărat aleatoare, plus depinde de destinația IP și portul de destinație. Masa materialelor găsite prin căutarea pe acest subiect a ignorat acest fapt simplu, având în vedere că un simplu server STUN este suficient pentru a cunoaște aceste necunoscute.
Ca și cum da. Dacă luăm NAT, organizăm folosind, să spunem iptables, apoi construcțiile formularului
-t nat -A POSTROUTIE -j MASQUERADE
sau
-t nat -A POSTROUTING -j SNAT-sursă
va înlocui numai sursa IP, portul de ieșire va rămâne același cu clientul. Astfel, sarcina este mult simplificată și masa articolelor care descriu rolul mediatorului pentru această tehnologie de traversare NAT începe să fie bătută până la capăt.
Dar acesta este un caz privat și simplu.
Pentru aceleași iptables, aceste construcții pot fi înlocuite cu
-t nat -A POSTROUTIE -j MASQUERADE ... -normal
sau
-t nat -A POSTROUTIE -j SNAT -pentru sursa ... -normal
iar situația va deveni mai puțin distractivă. Portul de ieșire începe să fie selectat la conversia NAT la întâmplare.
În totalitate, după o privire atentă la schemele de mai sus, avem următoarele probleme.
Nici host1 sau host2 nu cunosc SRC1_sluchayny și SRC2_sluchayny pentru a le influența ei pot doar în mod indirect, de exemplu, schimbarea pachetelor de ieșire portul sursă sau un timeout suficient între trimiterea datelor pe care ar avea intrări pentru NAT-transmisiunile pe NAT-dispozitive au timp să devină depășite și să se plieze .
Host2 ar trebui, printre altele, să învețe DST1_willing (în general, portul poate fi pre-negociat, dar vom considera cel mai rău caz).
Dacă nu intrăm în explicații lungi ale nevoii mediatorului, voi expune imediat un algoritm aproximativ al acțiunilor tuturor participanților la schimb.
1. Este strict necesar un intermediar cu care host1 și host2 stabilesc conexiuni complete de control cu trafic liber în ambele sensuri. Inițiatorii unor astfel de sesiuni de control sunt gazde pentru NAT. Mediatorul distribuie informații despre IP-ul lor alb printre gazdele finale.
2. Să presupunem că host1 va fi inițiatorul conexiunii / clientului țintă, iar pentru host2 conexiunea va fi recepționată, adică va acționa ca un server.
4. host1 pe conexiunea de control informează intermediarul de DST1_po_zhelaniyu selectat și continuă să trimită pachete cu aceiași parametri (portul sursa, portul de destinație), pentru a menține o emisiune constantă pe NAT1, care nu s-ar schimba SRC1_sluchayny. Întârzierea dintre posturile poate fi determinată experimental, din cauza unei sarcini banal nu este să-l vopsea, și să nu fie incluse în text.
6. Rapoartele mediatorului de pe canalul de control către host2 SRC1_random.
După cum puteți vedea, în cazul general, defalcarea parametrilor NAT simetrici nu este o sarcină simplă și rapidă. Pe unele implementări (amintesc iptables), poate fi substanțial simplificată și devine o procedură cu succes garantat, dar, din nou, nu în cazul general.
Care sunt locurile cele mai "înguste" ale algoritmului descris?
1. Nevoia de falsificare în clauza 5. Mediatorul trebuie să aibă o astfel de modalitate de acces la rețea, ceea ce i-ar permite să facă fără a avea probleme de la furnizor.
3. Acțiunile de la punctul 7 pot fi pe termen lung. Doar acest moment mi-a provocat curiozitatea și dorința de a încerca.
5 pachete pe secundă. Router-ul NAT2 a fost, în același timp, ușor împovărat de străini (utilizatorii l-ar auzi) de trafic.
Prima "defalcare" sa produs la aproximativ 8 ore după începerea experimentului. Apoi s-au mai întâmplat câteva piese, pentru că toată această fermă a fost lăsată să lucreze pentru noapte. Ulterior a început să se întâmple mai repede de câteva ori, atunci puteți imagina despre impactul traficului "străin".
Așa a arătat "defalcarea". Concluzia este selectivă, care include numai pachetele "fericite" cu coincidența necesară.
Ieșirea se realizează într-un punct de "șiretlic" de colectare a traficului, în care (traficul) este vizibil după NAT pe interfața externă a routerului AR-750
02: 19: 05.060809 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, lungime 0
05: 07: 00.178149 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, lungimea 0
06: 28: 35.355623 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, lungimea 0
07:16: 29.764069 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, lungimea 0
11: 28: 06.899109 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, lungimea 0
Concluzie sniffer pe hoste1, în care „crestătura“ proba (timpul nu este sincronizat, prin urmare ușoara diferența a ștampilelor de timp imprimate haldei de trafic hosta2).
02: 18: 20.480468 IPxx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, lungime 0
05: 06: 15.496093 IP xx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, lungimea 0
06: 27: 50.464843 IPxx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, lungimea 0
07: 15: 44.839843 IP xx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, lungime 0
11: 27: 21.589843 IPxx.xx.xx.xx.21393> 10.140.80.130.2429: UDP, lungime 0
A existat, de asemenea, un rezultat al dump-ului direct pe gazdă2, în care se vedea că pachetele care susțineu transmisia neschimbată NAT1 de la punctul 4 la host2 au început să ajungă, dar l-am însămânțat.
Acesta nu este un experiment cu totul onest. Dar el a arătat că, chiar și cu o frecvență de eșantionare relativ mică în punctul 7, rezultatul dorit poate fi atins într-un timp relativ rezonabil. Poate deveni și mai sensibil într-o căutare mai agresivă. Desigur, aplicația "industrială" nu trage, dar ... Dar este posibil. Algoritmul și experimentul descrise oferă gândire optimă pe tema optimizării accelerației - o abordare multi-filetată și altele asemănătoare.
Trimiteți-le prietenilor: