Kwa nini jibu la UDP la OpenVPN linatoka kwenye anwani isiyo sahihi

Mteja wa OpenVPN anapiga anwani moja, seva inajibu kutoka nyingine, na handaki haipanda kamwe. Kumbukumbu ya seva inaonyesha pakiti inapofika na nakala inaonyesha jibu linatoka, kwa hiyo hitilafu inawekwa kwa mteja. Kwenye mwenyeji mwenye violongo vingi, au anwani nyingi kwenye kiolongo kimoja, pande mbili hazikubaliani tu kuhusu ni anwani ipi inatumika. Jibu ni halali katika tabaka la IP, lakini wateja wengi hutupa datagram ambayo chanzo chake si anwani waliyowasiliana nayo.

Mteja anaona nini chanzo kinapobadilika

Kitongozi cha UDP ambacho hakifungamanishwa na anwani maalum ya ndani hakina chanzo kisichobadilika, kwa hiyo kerneli huchagua kimoja wakati wa kutuma. Uchaguzi huo unatoka kwenye utafutaji wa njia kuelekea anwani ya mteja, na chanzo kinakuwa anwani ya kiolongo ambacho utafutaji huchagua. Kwenye mashine yenye kiolongo kimoja uchaguzi hauonekani; kwenye mwenyeji mwenye anwani ya usimamizi, anwani ya umma na anwani ya pili kwenye kadi moja ya mtandao, hutegemea vipimo vya njia na sera. Uelekezaji wa njia unaotegemea sera hufanya kutokubaliana kuwezekana zaidi badala ya kidogo, kwa sababu kanuni inaweza kuchagua kiungo cha juu ambacho mteja hakuwahi kufikia. Njia ya chaguo-msingi iliyojifunza kutoka kwa mtoa huduma mmoja pamoja na kanuni ya chanzo inayoelekeza kwa mwingine inatosha kuizalisha.

Wateja wanaochuja majibu, na ufuatiliaji wa miunganisho unaotarajia sehemu nne kamili na chanzo, wataitupa jibu bila ujumbe wenye manufaa. Kisha handaki linamalizika kana kwamba hakuna kilichofika, na ndiyo sababu hii inachukuliwa kwa makosa kama tatizo la ukuta wa moto upande wa mteja. Nakala iliyopigwa kwenye seva pekee inathibitisha hitilafu badala ya kuieleza, kwa sababu jibu kweli linatoka. Linganisha chanzo cha jibu na anwani ambayo mteja alipiga kabla ya kubadilisha kitu kingine chochote.

Chaguo la multihome hufanya nini hasa

Agizo hili huandikwa kama multihome katika faili ya usanidi na kama --multihome kwenye mstari wa amri, na hulifanya seva ya UDP ijibu kutoka anwani ambayo pakiti ya mteja ilifika. Kerneli huwasilisha anwani ya awali ya mwisho kama data ya ziada wakati wa kupokea, na OpenVPN hutumia thamani hiyo kama chanzo cha jibu. Hivyo seva inayosikiliza kwenye anwani ya jumla, local 0.0.0.0 kwa IPv4 au kifanani chake cha IPv6, hujiendesha kana kwamba kila mteja amefikia msikilizaji maalum. Wateja waliokuja kupitia anwani ya umma hupata majibu kutoka anwani ya umma, na wateja walio kwenye anwani ya ndani huyapata kutoka hiyo. Hakuna kingine kwenye njia ya pakiti kinachosogea: njia, kanuni za kichujio na usanidi wa handaki hubaki kama zilivyokuwa.

Sifa hii ya mwisho ndiyo inayofanya chaguo kuwa salama kuongeza kwenye seva inayofanya kazi kwa namna nyingine, na pia ndiyo sababu haiwezi kurekebisha kichujio kinachoruhusu anwani moja tu. Pakiti bado inapaswa kukubaliwa kwenye njia inayopita, kwa hiyo marekebisho ya chanzo hubadilisha asili ya jibu na si zaidi. Ni kwa UDP pekee pia: msikilizaji wa TCP hauna tatizo hili kwa namna hiyo hiyo, kwa sababu muunganisho hutambuliwa na sehemu nne na si kwa anwani ya chanzo ya jibu.

Ni lini anwani ya ndani isiyobadilika ni chaguo-msingi lisilo sahihi

Kabla ya kufikia chaguo, angalia kama seva inafunga anwani moja maalum ya ndani, kwa sababu msikilizaji aliyefungwa hujibu kila mara kutoka anwani hiyo. Hii ni sahihi kwa usambazaji wa kiolongo kimoja na si sahihi mara tu wateja wanapotumia anwani zaidi ya moja kwa njia halali. Ikiwa ufungaji ulikuwa wa makusudi, amua kama seva inapaswa kukubali trafiki kwenye anwani za ziada. Kuondoa ufungaji huongeza mfiduo, kwa hiyo violongo na mitandao ya chanzo inayoruhusiwa lazima itekelezwe na huduma na kichujio, sio kwa anwani ya ufungaji pekee.

Marejeo ya OpenVPN huzuia chaguo kwa seva za UDP, hubainisha usindikaji wa ziada kwenye njia ya pakiti, na hurekodi ni majukwaa gani yanaiunga mkono. Thibitisha hilo kwenye toleo lililosakinishwa kabla ya kupanga kwa msingi wake. Pale ambapo haliungwi mkono, mbadala ni kufunga anwani maalum au kurekebisha njia ya kurudi, na zote mbili ni mabadiliko membamba zaidi kuliko yanavyoonekana kwa mtazamo wa kwanza. Kusikiliza kwa anwani ya jumla pia kuna athari zaidi ya majibu: seva iliyo kwenye anwani zote inafikiwa kutoka kila mtandao ambao mwenyeji umeunganishwa nao, na huenda hicho si mfiduo ambao mtu alikusudia.

Thibitisha chanzo cha jibu kutoka nje

Jaribu kutoka nje ya seva, na rekodi anwani kamili na usafirishaji ambao mteja alitumia kabla ya kunasa kitu chochote. Vipimo vitatu vilivyo hapa chini hujibu maswali matatu tofauti, na mpangilio ni muhimu.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Nakala inaonyesha anwani ya chanzo kwenye jibu, na hii ndiyo hoja ambayo makala yote inategemea. Orodha ya vitongozi inaonyesha kile seva ilifunga kweli, kwa sababu msikilizaji wa jumla na msikilizaji maalum huonekana sawa katika faili ya usanidi na hujiendesha tofauti kwenye mtandao. Utafutaji wa njia unaonyesha chanzo ambacho kerneli ingechagua kwa mtiririko huo, na hilo hufafanua nakala kabla ya kubadilisha kitu chochote. Rudia vyote vitatu kwa IPv4 na IPv6 tofauti, kwa sababu ni visikilizaji tofauti na utafutaji tofauti, na ingizo la jumla kwa familia moja halisemi chochote kuhusu nyingine.

Uelekezaji, ugunduzi na uchujaji hubaki tofauti

Kuhifadhi chanzo cha jibu hakuweki njia ya kutoka, hakisasishi DNS inayobadilika, na hakifanyi familia moja ya anwani ikubali nyingine. Kwenye seva yenye viungo vingi vya juu, njia ya kurudi kwa kila chanzo lazima ikubaliwe kwa makusudi, vinginevyo majibu hutoka kupitia kiolongo ambacho kichujio cha mteja hakikuruhusu kamwe. Vivyo hivyo, anwani mpya baada ya mabadiliko ya kiambishi lazima ifikie wateja kupitia ugunduzi na mtiririko wa kuunganisha upya unaoungwa mkono, sio kupitia rekodi ya zamani.

Acha ukaguzi wa utambulisho wa seva na uthibitishaji wa vyeti uwe kama ulivyo, kwa sababu anwani iliyobadilika haihesabiki kukubali mwenzake ambaye hajathibitishwa. Ikiwa jibu sasa linatoka kwenye chanzo kilichokusudiwa na handaki bado linashindikana, chukulia tatizo la chanzo kuwa limetatuliwa na uendelee. Hitilafu inayofuata inayoonekana ni ya uelekezaji, uchujaji au uthibitishaji, na kubadilisha msikilizaji tena hakutafikia hilo. Andika chanzo cha jibu kwenye tiketi kando ya anwani ambayo mteja alipiga, ili mtu anayefuata aweze kukagua ukweli huo kwa amri moja.