Zergatik huts egiten duen DNS erantzunak egoerarik gabeko VPN ertzeko suebakian

Tunela martxan dago, bezeroek VPN ostalaria iristen dute, eta ostalariak ezin du ezer ebatzi. Bere irteerako galderek interfazea garbi uzten dute, beraz hutsa itzulera bidean dago: ostalariak oraintxe bidali duena gogoratzen ez duen goiko ertz batean. Tunelaren portua baimentzeak ez du truke hori batere deskribatzen. DNS galdera baten erantzuna fluxu bereizia da, eta ertza egoerarik gabea bada, ezerk ez dio itzultzeko baimenik eman.

Bi trukeak ez dira truke bera

Idatzi tuplak eta akatsa agerikoa da. Eskaeraren helburu-portua erantzunaren iturri-portu bihurtzen da, eta hori jendeak 53 porturako sarrera-araua gehitzean irudikatzen duenaren kontrakoa da:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

53 helburu-portua eskatzen duen sarrera-arau batek ostalarian exekutatzen den DNS entzule batera zuzendutako trafikoa deskribatzen du, eta hori erabat bestelako zerbitzua da. Helbide horiek dokumentazioko adibideak dira, eta iturri-portua bezeroak aukeratzen du galdera bakoitzeko, beraz ez da arau batean kopiatu eta lanean jarraituko duela espero dezakezun balioa.

Egoerarik gabeko ertza versus egoeradun ostalari suebakia

Egoerarik gabeko ertz-iragazkiak sartzen den pakete bakoitza bere arau-zerrendaren aurka ebaluatzen du, atzean konexio-taularik gabe. Ongi atera zen irteerako galdera batek ez du bere sarrera-erantzunerako baimenik sortzen, gailuak ez baitu inoiz galderarik gertatu zenik jasotzen duen erregistrorik. Egoeradun ostalari suebakia kontrakoa da: bere konexio-jarraitzeak baimendutako truke baten itzulera-trafikoa ezagutzen du eta erantzunerako araurik gabe uzten du pasatzen. Bi mugak bide tipiko batean daude, eta biek pentsatutako paketea baimentzen dute.

Konparazioa garrantzitsua da bi gailuek modu ezberdinean huts egiten dutelako. Erantzuna ukatzen duen egoeradun suebaki batek jaregitea erregistratzen du; egoerarik gabeko ertzak isilpean ukatzen du, eta horregatik ostalariak denbora-muga besterik ez du jasaten.

Eraiki baimena protokoloaren inguruan, ez portu-zenbaki baten inguruan

Mugatu araua benetako resolver helbideetara, helburuko ostalarira eta produktuak onartzen duen harrera-portu politikara. Eduki DNS-ren TCP bidea ere kontuan, erantzun handi batek edo mozketak eragindako atzerapauso batek trukea TCPra eramaten baitu eta UDP soilik arau batek ez du estaliko. Ertzak fluxu zehatz baterako egoeradun ikuskapena onartzen badu, hobetsi hori eskuz idatzitako erantzun-arau baten ordez, egoeradun bideak automatikoki jarraitzen baititu bezeroak aukeratutako portuak.

Gero egiaztatu bideko zein produktuk iragazten duen trafikoa benetan. Dokumentatutako IPv4 ertz-esparru batek ez du IPv6 politikarik ezartzen, eta hornitzailearen barneko trafikoak agian ez du inoiz iragazki hori zeharkatuko.

Zergatik ez den konponbidea edozein iturri-portu 53 baimentzea

53 iturri-portua duela dioen edozer onartzen duen araua goiburu-eremu batean igorleak idazten duena onartzen duen araua da. Portu-zenbakiak ez du igorlea autentifikatzen eta ez du frogatzen karga erantzun baliozkoa denik, beraz arauak ostalariaren esposizioa handitzen du ebazpena fidagarriagoa egin gabe. Mantendu iturri-murrizketak eta bezeroaren beraren erantzun-egiaztapenak, iturri-portuaren ausazkotzea barne, sarbide-zerrenda bat sinplifikatzeko desaktibatu beharrean.

Resolverra kontrolatzen duzun zerbitzu bat bada, nahikoa da haren helbideetara mugatzea. Resolver publiko bat bada, mugatu onartu dituzun helbideetara eta aipa itzazu arauaren iruzkinean.

Egiaztatu muga egokian, norabide egokian

Hartu ostalarian eta ertzean galdera beraren kaptura, eta alderatu tuplak, ez pakete-kontuak. Bi aldeetan ikusgai dagoen galdera batek, ostalariaren aldean erantzunik ikusi gabe, sarrera-iragazkira seinalatzen du; ostalariaren aldean soilik ikusgai dagoen galdera batek bideratze-ra edo resolverrera berara seinalatzen du. Errepikatu TCP galdera batekin UDP soilik baimena baduzu, hori baita lehen probak ikusi ezin duen hutsunea.

Hau konpontzeak ostalariak benetan behar duen DNS trukea osatzen du. Ez du ostalaria resolver publiko bihurtzen, ez die baimenik ematen birbidalitako VPN fluxuei eta ez du frogatzen DNS zen lotu gabeko tunel arazo baten arrazoia.