Jibu la STUN hufichua nini wakati VPN inafanya kazi kwenye kipanga njia
Anwani ya handaki ya kipanga njia si anwani ya ndani ya kivinjari. Fuata jinsi kila ombi linavyopitishwa na kutafsiriwa kabla ya kusoma kile kinachoripotiwa na kiakisi.
Wakati handaki likiwa kwenye kipanga njia, mashine inayoendesha kivinjari haina kiolesura cha handaki hata kidogo. Muulize mashine hiyo kuhusu anwani zake za ndani na utapata anwani ya kibinafsi ya LAN na mzunguko, hakuna kinachofanana na anwani ya VPN. Hata hivyo, seva ya STUN upande wa pili bado inaweza kuripoti kitu cha maana kuhusu njia, na inachoripoti kinategemea kabisa jinsi ombi hilo mahususi lilivyopitishwa na kutafsiriwa.
Hii ndiyo sehemu inayostahili kupunguza mwendo. „Kivinjari hakimiliki anwani ya VPN“ hujibu swali kuhusu violesura, wakati anwani iliyoakisiwa ni jibu kuhusu njia kupitia tafsiri. Kuchanganya vyote viwili hutoa hitimisho la uhakika kuhusu ufichuzi ambalo ushahidi haukiunga mkono.
Vifaa viwili, seti mbili za violesura
Katika mpangilio unaotegemea kipanga njia, handaki huishia kwenye kipanga njia na mteja wa LAN hutuma trafiki ya kawaida kwenye lango lake chaguo-msingi. Orodha ya violesura vya mteja hubaki fupi: anwani moja ya kibinafsi, labda ya pili kwa mtandao mwingine, na mzunguko. Hatari si kwamba moja yao kwa bahati ni anwani ya handaki; hatari ni kwamba ombi linatoka kwa njia ambayo hukuchagua.
Muulize mteja njia gani lengo fulani litachukua badala ya kuuliza ni violesura vipi vilivyopo. Jibu hutaja lango na anwani ya chanzo ambayo kerneli ingetumia, na hilo tayari ni maelezo zaidi kuliko orodha yoyote ya anwani.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsSafu za nyaraka ni malengo mazuri ya majaribio kwa sababu hazitaturiwi kamwe kuwa huduma halisi. Linganisha kile mteja anasema na kile kipanga njia kinasema, na chukua kutokubaliana kokote kama ushahidi kwamba upitishaji wa sera, sheria ya handaki iliyogawanywa au njia ya pili chaguo-msingi inafanya kitu usichokizingatia.
Jibu la Binding linaruhusiwa kusema nini
RFC 8489 hufafanua ombi na jibu la Binding, ambapo seva huripoti anwani ya usafirishaji chanzo iliyoiona kwa ombi hilo. Ni tamko kuhusu tano moja kwa wakati mmoja, si sensa ya violesura vya mteja. Kwa hiyo kila kitu cha kuvutia hutokea kati ya mteja na sehemu ya uchunguzi.
Pengo hilo huzibwa na upitishaji na tafsiri. Kipanga njia kinachofanya NAT ya chanzo kwenye trafiki inayotoka hubadilisha chanzo cha kibinafsi cha mteja na anwani yake mwenyewe kwenye kiolesura kinachotoka. Ikiwa kiolesura hicho ni handaki, kiakisi huona anwani ya handaki. Ikiwa pakiti ilitengwa na handaki, kiakisi huona kile tafsiri ya WAN ilizalisha. Mteja yuleyule, kiakisi yuleyule, jibu tofauti.
Kesi tatu zinazofanana na hazifanani
Tofauti yenye manufaa si ya umma dhidi ya ya kibinafsi, bali ni sehemu ipi ya utekelezaji iliyoshughulikia pakiti. Fanyia kazi kesi hizo huku majedwali ya kipanga njia yakiwa wazi, kwa sababu kivinjari kimoja kinaweza kuzalisha zote tatu kulingana na sheria uliyosahau kuandika.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Ni kesi ya pili pekee inayovunja sharti kwamba trafiki fulani haitoki moja kwa moja kamwe, na ni ya kwanza na ya tatu pekee zinazofichua kitambulisho cha upande wa handaki. Hakuna safu yoyote kati ya tatu iliyo dai kuhusu tabia ya mtoa huduma mahususi: ikiwa kiakisi cha kibinafsi kinafikiwa inategemea upitishaji, anwani za IP zilizoruhusiwa za upande mwingine na sera ya firewall katika miisho yote.
Kuwa na akaunti kwa mtoa huduma yuleyule hakuimarishi lolote la haya. Inafaa pia kukumbuka kwamba ombi lililopitishwa linaweza kuhifadhi chanzo cha LAN cha mteja ikiwa hakuna kinachotafsiri, kwa hiyo uwanja wa chanzo lazima ufuatiliwe badala ya kudhaniwa kutoka kwa mchoro wa topolojia.
Kukusanya si kuchagua
WebRTC hukusanya anwani za wagombea kujaribiwa, na mgombea anayetokea kwenye orodha ya uchunguzi huenda hakubeba midia kamwe. Kusoma orodha kama „hivi ndivyo upande mwingine ulivyojifunza“ hukuzidisha ushahidi. Jozi iliyochaguliwa ndiyo iliyobeba kikao kwa kweli, na iko katika uwanja mwingine.
Kikagua toka la HTTPS hujibu swali lingine: anwani ya chanzo ambayo seva ya wavuti iliona kwa ombi hilo. Ni ukaguzi mtambuka wenye manufaa kwa sababu hutumia itifaki tofauti na mara nyingi lengo tofauti kuliko kiakisi cha UDP, na kutokubaliana kati ya hizo mbili kwa kawaida huonyesha sheria ya upitishaji badala ya hitilafu.
Amua sera, kisha soma jibu
Andika nia kabla ya kujaribu: trafiki ipi lazima itumie handaki, ipi inaweza kutoka moja kwa moja, familia zipi za anwani ziko ndani ya wigo, na nini kifanyike wakati handaki limezimwa. Bila msingi huo kila uchunguzi ni wenye utata, kwa sababu huwezi kutenganisha uvujaji na njia uliyoiruhusu kwa makusudi.
Kisha uliza swali moja kwa wakati mmoja. Njia ipi lengo hili huchukua. Anwani ipi kiakisi hiki huripoti. Jozi ipi ya wagombea kikao kilichagua. Weka majibu kando ya sera na uyawekee tarehe, kwa sababu sasisho la firmware linaweza kubadilisha tabia chaguo-msingi kwa namna inayobatilisha kimya hitimisho la mwaka jana.
Kipanga njia bado ni sehemu thabiti ya utekelezaji, kwa sababu huona trafiki ambayo mteja hawezi kuikwepa bila kujipanga upya. Si ahadi kwamba kila uwanja katika kila itifaki ya programu haufichui chochote, na si mbadala wa kuandika njia ulizochagua kuruhusu.