Gesplete DNS en VPN: domeinreëls is nie IP-roetes nie

Jou skootrekenaar los intranet.corp deur die tonnel op, terwyl gitlab.com aanhou om na die ISP-oplosser te gaan, en dit is die reëling wat werk soos ontwerp. Twee afsonderlike besluite het dit veroorsaak: 'n naampassingreël het die oplosser gekies, en 'n roete het die antwoord teruggedra. Breek enigeen van die twee en die blaaier wys 'n fout wat van buite dieselfde lyk. Die meeste verslae oor gesplete DNS beskryf die tweede fout terwyl hulle bewyse oor die eerste aanhaal.

Die twee helftes woon op verskillende plekke en word gewoonlik deur verskillende mense geredigeer. Die een is DNS-beleid wat aan die VPN-profiel geheg is, die ander is 'n roete wat die tonnel installeer of weerhou. Ontfouting staak wanneer niemand vasstel watter helfte werklik beweeg het nie.

Twee besluite versteek in een versoek

Die naamhelfte is 'n beleidsobjek eerder as 'n roete. Op Windows is dit 'n naamresolusiebeleid op die VPN-profiel; op Apple-platforms 'n stel pasdomeine op 'n DNS-instellingsvoorwerp; op Linux 'n roeteringsdomein, 'n gesplete oplosserreël of die naamdiens-skakelorde. Die padhelfte is gewone roetering, wat deur die tonnel of met die hand geïnstalleer word, en dit het geen idee wat 'n gasheernaam is nie. 'n Profiel wat 'n agtervoegsel toelaat, besluit net wie antwoord; dit maak die antwoord nooit bereikbaar nie.

'n Vinnige simptoontoets skei hulle: vervang die naam met 'n adres. As die adres werk, is die pad reg en die reël verkeerd. As die adres ook faal, kan die reël reg wees en die pad ontbreek.

Hoe elke platform dieselfde naamreël uitdruk

Die bedoeling is identies en die veldname is nie. 'n Voorbeeld wat van een kliënt na 'n ander gekopieer word, ontleed netjies en pas nooit nie. Die drie vorms lyk so:

'n Pas- of roeteringsdomein is 'n agtervoegseltoets, so intranet.corp dek git.intranet.corp en dek nie corp.intranet nie, en om dit om te draai is die mees algemene fout in die hele opstelling. Windows dra die kartering as 'n naamresolusiebeleid wat aan die profiel geheg is, met sy eie voorrangorde teenoor watter agtervoegsellys die koppelvlak reeds gehad het. Apple-platforms heg pasdomeine aan die DNS-instellingsvoorwerp van die netwerkuitbreiding, en die stelsel pas hulle per afgebakende oplosser toe. Nie een van hierdie vorms is 'n roete nie, en nie een kan 'n onbereikbare adres bereikbaar maak nie. Die verwysing Windows-naamresolusiebeleid lys die veldname en die voorrangreëls vir daardie platform, en dit is nie die wat die Apple- of systemd-dokumente gebruik nie.

'n Korrekte antwoord het steeds 'n pad nodig

'n Oplosserantwoord is net 'n adres, en die toepassing moet dit steeds bereik. 'n Gesplete-tonnelontwerp stoot dikwels 10.20.0.0/16 en weerhou die verstekroete, so die interne naam los op en die verbinding hang dan. Die teenoorgestelde geval is net so algemeen: die roete bestaan, 'n openbare oplosser antwoord die private naam met NXDOMAIN, en die fout word as 'n roeteringsprobleem ingedien. Om eers die pad te toets laat jou na roetes staar vir 'n naam wat nooit sou oplos nie.

Daar is ook 'n derde hek wat nie een helfte dek nie. 'n ACL op die poort, 'n firewall-reël of 'n kliëntkant-beleid kan die verbinding laat val nadat albei besluite reg was. Wanneer die naam oplos, die roete bestaan en die verbinding steeds uittyd, stop om DNS te toets.

Om name en paaie in 'n vaste volgorde te toets

Kies 'n volgorde en hou daarby, anders jaag jy die stap wat die meeste onlangs gefaal het. Los die gedokumenteerde volle interne naam op, bevestig dat die antwoord 'n adres is wat die roetetabel kan dra, herhaal dan met 'n openbare naam om te bewys die tonnel het nie alles gevang nie. Op 'n systemd-gasheer is die navraag en die oplosser se roeteringsdomein een opdrag uitmekaar:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

'n Windows-kliënt vra dieselfde twee vrae met ander cmdlets. Die tweede een rapporteer die koppelvlak wat die stelsel werklik sou gebruik:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

As die opsoek 'n adres teruggee en die padtoets die fisiese koppelvlak noem, het die naamreël gewerk en die roete nie. As die kort naam faal terwyl die volle naam oplos, is die agtervoegsellys verkeerd eerder as die oplosser.

Waar die vergelyking gewoonlik verkeerd gaan

Die eerste fout is om 'n onverwante openbare oplosser oor 'n private naam te vra en die weiering as bewyse oor die VPN te lees. Die tweede is om te aanvaar dat 'n werkende openbare opsoek die tonnel se oplosserpad bewys. Die derde is om gesplete tonneling en gesplete DNS as een ontwerpbesluit te behandel, terwyl 'n ontplooiing in die een korrek en in die ander stukkend kan wees. Elke fout lewer selfversekerde gevolgtrekkings uit 'n toets wat nooit die deel wat beskuldig word, geoefen het nie.

'n Blaaier met sy eie veilige DNS kan ook die stelselreël omseil, en daarom is dit nie 'n teenstrydigheid as een blaaier faal terwyl 'n ander slaag nie. Vergelyk die oplosser wat geantwoord het, nie die blaaier wat gekla het nie.

Sodra albei helftes sigbaar is, is die oorblywende vraag 'n beleidsvraag eerder as 'n tegniese een: watter naamruimtes hoort by die organisasie, wie besit elke antwoord, en watter van hulle moet die masjien hoegenaamd verlaat. Skryf dit langs die profiel neer, want die volgende persoon wat aan die reël raak, sal dit nodig hê.