DNS ya faragha ya Pritunl inashindwa? Ongeza njia nyembamba ya resolver
Resolver ya faragha inayopuuza bwawa la VPN inahitaji msamaha wa chanzo, si njia pana zaidi. Ongeza /32 yenye NAT na ujaribu utafutaji halisi wa faragha.
Majina ya faragha hutatuliwa kwa kila mtu kwenye mtandao wa kampuni na huisha kwa kila mtu kwenye VPN. Resolver hujibu lango, njia ya kufika hapo ipo, na ombi bado halipati jibu kamwe. Kinachokosekana si resolver nyingine ya umma au njia pana zaidi: ni anwani ya chanzo ambayo seva ya DNS ya faragha iko tayari kuijibu.
Thibitisha kwamba resolver inakataa bwawa lako la wateja
Anza kwa kuthibitisha kwamba hitilafu inahusu chanzo, si ufikikaji. Kutoka kwa mteja aliyeunganishwa, uliza resolver ya faragha moja kwa moja na uangalie kama ombi linaisha muda au linarejea kama katazo. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 ikiisha muda wakati ombi lilelile kutoka lango likifanikiwa huonyesha sera ya ufikiaji kwenye resolver. Jibu la SERVFAIL huonyesha mahali pengine kabisa, kwa kawaida ukanda au kipitishaji cha juu.
Andika anwani ya mteja kabla ya jaribio. ip -4 addr show tun0 kwenye mteja, au kodi inayoonyeshwa kwenye konsoli, hukuambia ni bwawa gani resolver inaona.
Kisha thibitisha kwamba njia ipo kabisa. Njia inayotuma anwani ya resolver ndani ya handaki ni sharti, si suluhisho; ikiwa pakiti hazifiki kamwe, sera ya chanzo haizingatiwi hata. Iangalie kwa ip route get 10.40.0.53 kwenye mteja.
Ongeza njia moja ya mwenyeji badala ya kutafsiri kila kitu
Mwongozo wa DNS ya faragha wa Pritunl unaeleza tiba nyembamba: njia ya /32 yenye NAT kwa anwani ya resolver, ikiwa anwani hiyo imechaguliwa kama seva ya DNS ya wateja. Njia hubadilisha chanzo ambacho resolver inaona kwa trafiki ya DNS pekee. Trafiki ya programu huhifadhi muundo unaohifadhi chanzo uliochagua kwa ajili yake.
Iisanidi kupitia mmiliki wa njia anayeungwa mkono wa seva, baada ya kukagua njia zilizopo kwa mwingiliano. Katika mfano hapo juu lengo ni 10.40.0.53/32 yenye NAT, na bwawa la wateja linabaki 10.90.0.0/24. Usitafsiri masafa yote ya faragha ili kurekebisha huduma moja, kwa sababu kila sera ya chini inayotegemea anwani halisi ya mteja itaanza kuona lango badala yake. Thibitisha anwani ambayo resolver inapokea kweli kwa kuangalia kumbukumbu yake ya maombi wakati wa utafutaji wa jaribio. Njia moja ya mwenyeji peke yake haithibitishi chochote kuhusu tafsiri au ruhusa.
Resolver bado inapaswa kuruhusu chanzo kilichotafsiriwa kwenye UDP na TCP, na majibu yake lazima yaweze kurudi. Kubadilisha chanzo hakuwezi kuunda ukanda au rekodi inayokosekana.
Amua kama seva au mteja ndiye anayetuma ombi
Pritunl pia inaandika mpangilio wa proksi ya DNS unaohusiana na VPN Client DNS Mapping, ambapo seva hupeleka maombi ya juu kwa wateja. Katika muundo huo chanzo cha juu ni mali ya muktadha wa mtandao wa seva yenyewe, na msamaha upande wa mteja ni suluhisho lisilofaa.
Tambua ni muundo gani unaotumika kabla ya kuongeza kitu. Marekebisho matatu yanayogiliana, proksi, uingizwaji wa resolver kwenye mteja na hati ya NAT ya mkono kwa kawaida humaanisha kwamba hakuna aliyethibitisha: kipengele kipi kinapaswa kutuma ombi. Angalia pia bootstrap: resolver ya faragha pekee haiwezi kuwa njia pekee ya kupata kituo cha mwisho kabla handaki halijakuwepo, na mabadiliko ya kudumu ya resolver hayapaswi kuishi zaidi ya muunganisho.
Jaribu utafutaji wa faragha, si ukurasa wa wavuti wa umma
Baada ya kutumia mabadiliko na kuunganisha tena, kagua usanidi halisi wa resolver wa mteja, kisha tatua jina unalojua lipo katika ukanda wa faragha pekee. dig intranet.example.net bila seva bayana huonyesha kile mteja anachotumia kweli. Fuata kwa ombi kwa anwani ambayo utafutaji huo ulirudisha, kwa sababu utatuzi na ufikiaji wa huduma ni hatua tofauti. Kivinjari kinachopakua tovuti za umma kupitia DNS-over-HTTPS hakithibitishi chochote kuhusu njia ya resolver ya faragha ya mfumo wa uendeshaji. Resolver ya pili ya umma pia si mamlaka kwa ukanda wa ndani.
Andika anwani ya resolver, njia ya /32 na mpangilio wa DNS wa mteja pamoja katika maelezo ya seva. Nusu ya usanidi huo ukirejeshwa peke yake huzalisha tena hitilafu ya awali.
Hatimaye, thibitisha kwamba handaki bado linaelekeza lengo la programu baada ya DNS kufanikiwa. Njia, ufikiaji wa huduma na uthibitishaji hubaki huru kutoka kwa utatuzi wa majina, na utafutaji unaofanya kazi hausemi chochote kuhusu upitishaji data. Ikiwa ukurasa wa faragha ni wa polepole lakini unatatuliwa, resolver ilifanya kazi yake na tatizo lilihamia kwenye njia.