Nola irakurri VPN DNS bideratzea esteka bakoitzeko resolvectl-eko irteeran
resolvectl status-ek zerbitzariak, domeinuak eta bide lehenetsia erakusten ditu esteka bakoitzeko. Irakurri batera, gero galdetu izena eta ohartu zein estakek erantzun duen.
Exekutatu resolvectl status eta esteka bakoitzeko blokeen horma bat lortuko duzu, bakoitza bere zerbitzariekin eta bere domeinu-lerroarekin. Bideratzea erabakitzen duen lerroa domeinu-zerrenda da, ez izen-zerbitzariaren helbidea, tokiko stub-ak kontsulta bakoitza izena aldarrikatzen duen estekara birbidaltzen duelako. Irakurri aldarrikapen horiek erantzuna irakurri aurretik, gero galdetu izena eta egiaztatu zein estakek sortu zuen. Esteka zuzeneko erantzun okerra beste arazo bat da esteka okerreko erantzun zuzena baino.
Zer esaten dizu esteka bakoitzeko blokeak
Bloke bakoitzak resolver-ak interfaze horretarako erabiliko dituen zerbitzariak, domeinu-zerrenda eta esteka bide lehenetsia den ala ez zerrendatzen ditu. Domeinu-zerrenda aldarrikapenen multzo bat da, eta resolver-ak atzizkirik luzeenaren bat-etortzea aplikatzen du: host.corp.example-ren kontsulta corp.example daraman esteka batek aldarrikatzen du, bide lehenetsia soilik daramanaren aurretik. Atzizki bera aldarrikatzen duten bi estekek emaitza lehentasunaren eta ordenaren esku uzten dute, horregatik bikoiztuek merezi dute arreta lehenengo. Uneko zerbitzari-lerroak erakusten du zerrendatutako zerbitzarietako zein den une horretan erabiltzen.
127.0.0.53 bezalako stub helbide batek /etc/resolv.conf-en apenas dio stub-a aurrealdean dagoela. Ez du erantzun zuen goiko fluxua izendatzen, horregatik resolv.conf soilik oinarritutako diagnostikoak blokeatuta geratzen da.
Irakurri zuzen hiru domeinu-sarrera motak
| Sarrera | Zer aldarrikatzen du | Ohiko akatsa |
|---|---|---|
| corp.example | bideratze-domeinua eta bilaketa-atzizkia: azpiko izenak esteka honetara doaz, eta katea izen biluziei gehitzen zaie | kenduta bideratzeak hala ere funtzionatzen duela ematen duelako |
| ~corp.example | bide soilik: azpiko izenak esteka honetara doaz, baina atzizkia ez zaie gehitzen | bideratzeko beharrezkoa zela pentsatu zen |
| ~. | bide lehenetsia: beste inongo estekak bat egiten ez dituen kontsultak aldarrikatzen ditu | profil zatituan aktibo utzita, izen publikoek tunela jarraitzen dute |
Tildeak bilaketaren portaera aldatzen du, ez bideratzea. Tilderik gabeko sarrera bideratze-domeinua eta bilaketa-domeinua da aldi berean, beraz azpiko izenak esteka horretara bidaltzen dira eta etiketa bakarreko izenei atzizkia gehitzen zaie. Tilde bidezko sarrerak atzizki bera bideratzen du bilaketa-zerrendatik kanpo edukiz. Horregatik tildea kentzeak zein izen biluz ebazten diren aldatzen du, eta horregatik falta den tildea bilaketa arazoa da, ez DNS zatituaren hutsegitea.
Bide lehenetsiko sarrerak beste inongo estekak bat egiten ez duen guztia aldarrikatzen du. Tunel osoko profilek normalean nahi du eta profil zatituek normalean ez, izen publikoak orduan resolver pribatura joaten baitira eta han huts egin dezakete. Irakurri taula profilaren asmoaren aurka, profil artean banderak kopiatu beharrean. Bi estekek atzizki bera aldarrikatzen dutenean, konpondu lehentasunaren kontua beste ezer editatu aurretik.
Galdetu izen bat eta ikusi zein estakek erantzun zuen
query azpikomandoak erantzuna sortu zuten helbidea, protokoloa eta esteka edo esparrua inprimatzen ditu. Probatu atzizki pribatuak aldarrikatu beharko lukeen izen bat eta ohiko izen publiko bat, gero alderatu jakinarazitako iturriak. Izen pribatuak haririk gabeko estekatik erantzuten badu, aldarrikapena falta da edo tunela behera dago; profil zatituan izen publiko batek tunelatik erantzuten badu, bide lehenetsia zabalegia da. Bi hutsegite horiek berdinak dirudite nabigatzailean eta aurkakoak irteera honetan.
resolvectl status
resolvectl query host.corp.exampleBegiratu jakinarazitako protokoloa ere, cachetik edo host fitxategitik datorren erantzun bat inongo goiko fluxuri galdetu gabe irits baitaiteke. Cachetik datorren erantzunak izena noizbait ebatz zela frogatzen du, ez egungo politikak zuzen bideratzen duenik.
Eduki izen-bideratzea pakete-bideratzetik bereizita
Resolver-aren erabakiak ez du bide bat sortzen. Aukeratutako zerbitzariak oraindik bere helbiderako bidea behar du, eta itzultzen den helbideak oraindik sare pribaturako bidea behar du, beraz DNS politika zuzena inoiz irekitzen ez den konexio batekin batera egon daiteke. Izen bat ebazten denean eta aplikazioak huts egiten duenean, aztertu helbidea eta bidea DNS berriro aldatu beharrean. Izen-ebazpena eta irisgarritasuna bi galdera dira bi jabe desberdinekin.
Aplikazioek sistema-resolver-a erabat saihestu dezakete beren DNS seguruaren ezarpenaren edo resolver integratu baten bidez. resolvectl-en emaitzak sistemaren bidea deskribatzen du, eta hura baztertzen duen nabigatzaileak egiten duzun proba bakoitzarekin desados egongo da. Egiazta ezazu ezarpen hori politika hautsi dela ondorioztatu aurretik.
Idatzi izena zein helbidetara ebatzi zen, estekaren ondoan. Helbide oker batera seinalatzen duen izen zuzena erregistro arazoa da, ez bideratze arazoa.
Egiaztatu berriro esteka aldatu ondoren
Birkonexio batek edo haririk gabeko aldaketak estekaren egoera berreraikitzen du, eta sare-kudeatzaileak bere domeinuak eta zerbitzariak eskuz ezarritakoaren gainean berrinstala ditzake. Galdetu geroago bi izen berak eta alderatu erregistratutako oinarri-lerroarekin. Eskuzko aldaketa bat desagertu bada, konponketa konexio-profilari dagokio eta ez shell komando bati. Aurretik eta ondoren erregistratzeak egiten du hori ikusgai.
Partekatu txostenak behar dituen izenak eta zerbitzari-testuingurua soilik, barneko atzizkiek topologia agerian uzten baitute. systemd-resolved-en domeinu-bideratzeari buruzko dokumentazioak bat-etortze luzeenaren araua eta tildearen portaera biltzen ditu, eta behin irakurtzeak goiko taulako akats gehienak saihesten ditu: systemd-resolved-en kontsulta-bideratzea.