Kikoa chako cha VPN katika dnsmasq si uhamishaji wa eneo

Unatafuta eneo la shirika katika usanidi wa dnsmasq wa mteja, hukulipata, na unahitimisha kuwa VPN haikusukuma kikoa chake. Kilichosukumwa ni kidokezo cha uelekezaji, si eneo. Mteja hurekodi kikoa na resolver inayopaswa kujibu kwa ajili yake, na backend inayosimamiwa hugeuza hilo kuwa usambazaji wa masharti. Kutafuta mahali pasipo sahihi hutoa utambuzi wa kujiamini na wa uongo kabisa.

Kile mteja alikikubali si kile gateway ilikitoa

Gateway inaweza kutoa resolver, kikoa na njia inayohitajika kufikia resolver hiyo, na mteja anaweza kukubali zote tatu au hakuna. Wasifu ulioingizwa, script ya msaidizi au sera inayopuuza chaguo zilizosukumwa zinaweza kuacha seti iliyokubaliwa tupu wakati upande wa seva unaonekana sahihi. Anza na hali iliyorekodiwa ya mteja badala ya usanidi wa seva, kwa sababu hali hiyo ndiyo resolver inayopokea kwa kweli. Ikiwa kikoa kilichokubaliwa hakipo, hakuna kingine zaidi kitakachojali. Angalia sifa za DNS za muunganisho kabla ya kuchunguza akiba yoyote.

Tofauti hiyo inaeleza ripoti nyingi za kikoa ambacho hakikufika kamwe. Kilitolewa, na hakikutumika.

Aina mbili za ingizo la kikoa

Muunganisho unaweza kubeba vikoa vya kawaida vya utafutaji na vikoa vya njia pekee, na aina ya pili huanza na tilde. Kikoa cha utafutaji huelekeza maswali na hurusi majina mafupi kupanuliwa, jambo ambalo ni rahisi kwenye kituo cha kazi na la kushangaza kwenye seva. Kikoa cha njia pekee kinasema kwamba maswali ya kiambishi hicho yanapaswa kwenda kwa seva mahususi bila kubadilisha jinsi majina mafupi yanavyotatuliwa. Kuandika kikoa kimoja kwa njia zote mbili si ziada, kwa sababu ingizo mbili hufanya kazi tofauti.

Kwa nafasi ya majina ya kibinafsi, umbo la njia pekee kwa kawaida ndilo unalotaka. Huliweka kiambishi cha shirika kikielekea kwenye resolver ya shirika na kuacha kila kitu kingine.

localhost katika resolv.conf si hitilafu

Wakati resolver ya akiba ya ndani inatumika, faili ya mfumo huelekeza kwenye anwani ya loopback na hakuna kingine. Ingizo hilo hutambua msikilizaji wa ndani, si seva za juu ambazo msimamizi alimpa. Anwani ya shirika itakosekana kwa halali katika faili.

Kubadilisha ingizo hilo na resolver ya umma ni marekebisho potofu ya kawaida. Hurejesha utatuzi wa majina ya umma na hutupa sera ya masharti katika uhariri huo huo.

Usichanganye backend

Kipengele cha dnsmasq kinachosimamiwa na resolver ya mfumo ni programu tofauti zenye usanidi tofauti na maoni tofauti ya hali. Amri ya hali kwa moja haisemi kitu chochote cha manufaa kuhusu nyingine.

Tambua ni backend ipi msimamizi amesanidiwa kutumia, kisha soma usanidi uliozalishwa wa backend hiyo badala ya faili ya usambazaji wote ambayo kwa bahati ipo. Msimamizi huandika usanidi wa kipengele chake mwenyewe na huunga mkono chaguo maalum kwa kipengele hicho, kwa hivyo kuhariri faili ya kimataifa isiyohusiana hakubadilishi chochote na huonekana kama mabadiliko bila athari. Kuanzisha daemon ya pili kwenye bandari 53 ni mbaya zaidi kuliko bure, kwa sababu sasa programu mbili hazikubaliani nani anamiliki bandari. Kwanza thibitisha mmiliki, kisha hariri mahali ambapo mmiliki huyo anasoma.

Jaribu nafasi ya majina, si jibu pekee

Uliza jina moja la kibinafsi linaloruhusiwa na jina moja la udhibiti la umma kupitia njia ya kawaida ya programu. Swali la moja kwa moja kwa seva ya shirika huthibitisha kuwa rekodi ipo; haliwezi kuthibitisha kuwa mteja alichagua seva hiyo. Swali la pili ndilo linalojaribu sera.

Kisha rudia baada ya kuunganisha tena na baada ya kukata muunganisho. Uhusiano unapaswa kufuata mzunguko wa maisha ya muunganisho, na majina ya kibinafsi yanapaswa kuacha kutatuliwa wakati handaki haipo, badala ya kuanguka tena kwa resolver ya umma inayojibu kiambishi hicho. Ikiwa yanaanguka tena, umepata uvujaji, ambao ni kasoro tofauti na utafutaji uliovunjika. Andika ni backend ipi ilifanya kazi, ni vikoa gani vilitumika na kila swali lilirejesha nini.