Dalawang VPN, Isang Resolver: Ang Huling Sumulat ang Mananalo

May dalawang kliyenteng VPN na nakakonekta, isa para sa trabaho at isa para sa laboratory network, at ang mga panloob na pangalan ay nireresolba lamang para sa kliyenteng huling kumonekta. Mukhang bug sa isa sa mga kliyente ang pattern na ito. Karaniwan itong nahuhulaang resulta ng dalawang programang nagsusulat ng parehong configuration ng resolver nang walang kasunduan kung kanino ang aling pangalan.

Ang mito: pag-aari ng pinakabagong VPN ang DNS

Walang pangkalahatang tuntuning nananalo ang pinakabagong koneksyon. Ang nangyayari ay depende sa mekanismo ng platform at sa paraan ng pagsulat ng bawat kliyente. Ang kliyenteng pumapalit ng file ng resolver ay nagbibigay ng isang resulta; ang kliyenteng nagdadagdag ng domain sa bawat link ay nagbibigay ng iba; ang kliyenteng walang ginagawa ay iniiwan ang dating estado nang buo.

Kaya ang naobserbahang pag-uugali ay katangian ng dalawang implementasyon, hindi dokumentadong priyoridad. Ang pangangatwiran mula sa pagkakasunod-sunod ng paglunsad lamang ay minsang tama at minsang mali sa paraang mahirap ulitin. Isulat na lang ang pagmamapa. Ang disenyong nabubuhay sa dalawang kliyente ay hindi disenyo.

Itugma ang mga namespace sa mga resolver

Ilista ang mga pribadong suffix at ang resolver na kailangan ng bawat network, pagkatapos ay magpasya kung saan dapat pumunta ang mga pampublikong pangalan. Ang listahang iyon ang disenyo. Kung wala ito, aksidente ang desisyon ng mga kliyente.

Ang platform na sumusuporta sa DNS sa bawat link o routing domain ay maaaring sadyang ipahayag ang paghahati: ang isang domain ay pumupunta sa isang link, ang isa pa sa kabila, at ang lahat ng iba ay sumusunod sa tahasang default. Hindi mapapanatili ng dalawang payak na script na nagsusulat muli ng parehong file ang disenyong iyon, dahil ang bawat isa ay naniniwalang pag-aari nito ang buong configuration.

Sa Windows, maaaring ituro ng talahanayan ng patakaran sa paglutas ng pangalan ang mga suffix sa partikular na server, at maaaring mag-install ng mga patakaran doon ang kliyenteng VPN. Suriin ang patakaran sa halip na ang listahan ng adapter, dahil hindi ang listahan ng adapter ang nagreresolba ng pangalan.

Panatilihin ang bootstrap path

Kailangang hanapin ng bawat kliyente ang sariling endpoint bago nito magamit ang serbisyong ibinibigay ng endpoint na iyon. Kung ang hostname ng endpoint ay maaaring resolbahin lamang sa pamamagitan ng tunnel, at kailangan ng tunnel ang naresolbang hostname, mayroon kang paikot na dependency na lumilitaw bilang timeout ng koneksyon. Panatilihin ang isang bootstrap path sa labas ng dalawang tunnel. Wala itong gastos hanggang sa araw na mailigtas nito ang koneksyon.

Tingnan ang landas sa bawat resolver, hindi lamang ang pangalang naka-configure para dito. Ang resolver na maaabot lamang sa pamamagitan ng kabilang tunnel ay kumikilos na parang kulang, at ang sintomas ay timeout sa halip na error sa routing.

Ang magkakapatong na address ay hindi problema sa DNS

Ang dalawang pribadong network na gumagamit ng parehong saklaw ng address ay hindi maaayos ng pagkakasunod-sunod ng DNS. Kung parehong nag-aangkin ng 10.0.0.0/8 ang dalawang tunnel, ang pangalang tama ang resolusyon ay tumuturo pa rin sa address na hindi kayang i-routing ng host patungo sa tamang tunnel. Kailangan nito ng solusyon sa antas ng address, tulad ng magkaibang saklaw, namespace, o pagsasalin, hindi isa pang setting ng resolver. Ang maagang pagpapasya nito ay pumipigil sa mahabang pagliko sa configuration ng DNS na hindi kailanman gagana.

Ihambing ang mga pagtatalaga ng address ng dalawang tunnel bago sisihin ang resolusyon ng pangalan. Kapag parehong itinutulak ng magkabilang panig ang parehong prefix, isang ruta lang ang pinapanatili ng host para dito, at ang pangalang naresolba sa pamamagitan ng ikalawang tunnel ay dumarating pa rin sa address na pag-aari ng unang tunnel. Magkaibang saklaw, namespace sa bawat network, o pagsasalin ang mga pagwawasto; pagkatapos kumonekta ang bawat kliyente, tiyakin na ipinapakita ng talahanayan ng ruta ang landas na nilayon mo.

Patunayan ito gamit ang totoong aplikasyon

Pumili ng dalawang host na umiiral lamang sa sariling namespace at isang pampublikong pangalan, pagkatapos ay resolbahin ang bawat isa sa kliyenteng dapat may-ari nito. Ang tamang sagot mula sa inaasahang resolver ay hindi nagpapatunay na naaabot ng aplikasyon ang host, dahil maaaring mabigo pa rin ang ruta sa address na iyon. Sundan ang bawat paghahanap ng pagsubok sa koneksyon mula sa programang aktuwal na patatakbuhin ng user.

Ang kliyenteng may sariling naka-encrypt na opsyon sa DNS ay maaaring lumampas sa patakarang bago mo lang na-verify, kaya suriin ang setting na iyon bilang bahagi ng pagsusuri. Pagkatapos ay ikonekta muli ang dalawang kliyente sa pagkakasunod-sunod na sinusuportahan ng vendor at ulitin ang mga paghahanap; kung nagpapalit ang mga sagot kapag nagbago ang pagkakasunod-sunod, pag-aari pa rin ng karibal na manunulat ang bahagi ng configuration. Alamin kung aling bahagi ang nag-install ng patakaran - ang kliyente, ang profile ng operating system, o isang management agent - bago mag-edit ng kahit ano. Itala ang pagkakasunod-sunod at ang mga may-ari para hindi na kailangang muling tuklasin ng susunod na tao.