Private DNS werk in die VPC, maar nie oor die VPN nie
'n Private naam wat binne EC2 opgelos word maar nie oor die VPN nie, is 'n probleem met die resolver-pad. Lees die foutvorm voordat jy die sone-inskrywing wysig.
'n Private naam los op vanaf 'n EC2-instansie, maar nie vanaf 'n skootrekenaar wat deur die VPN verbind is nie, en die sone lyk korrek in die konsole. Die instink is om die inskrywing te wysig, wat byna nooit die probleem is nie. Die inskrywing antwoord iemand; dit antwoord net nie jou skootrekenaar nie. Wat tussen die twee oproepers verskil, is watter resolver hulle vra, en of daardie resolver 'n ondersteunde pad na die VPC se DNS-aansig het.
Ek begin deur te bewys dat die inskrywing bestaan, en spandeer die res van die tyd op die navraagpad. Dit is aparte stelsels, en hulle faal op verskillende maniere.
Lees die foutvorm voordat jy iets verander
Drie uitkomste beteken drie verskillende dinge, en een navraag onderskei hulle: voer dig uit vir die naam teen die resolver wat die kliënt werklik gebruik.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
'n Tydverstreke is 'n netwerkverklaring. NXDOMAIN is 'n DNS-aansigverklaring. 'n Openbare antwoord is 'n beleidsverklaring. Om 'n sone-inskrywing te wysig terwyl jy 'n tydverstreke het, gooi die een bruikbare bewysstuk in die saak weg.
Waarom die VPC se plus-twee-adres nie 'n afgeleë resolver is nie
Die CIDR-plus-twee-adres is 'n plaaslike diens vir hulpbronne binne die VPC. AWS dokumenteer dat die deurstuur van navrae vanaf plaaslike netwerke, of vanaf 'n ander VPC se DNS-bedieners, direk na daardie adres nie ondersteun word nie en onstabiele resultate kan lewer.
Dit beteken nie dat 'n eksperiment nooit werk nie. Dit beteken die gedrag is nie 'n kontrak wat jy in 'n helpdesk-skrip kan sit nie. Die ondersteunde rigting is 'n inkomende Resolver-eindpunt: 'n adrespaar binne jou VPC, bereikbaar vanaf die netwerk wat jy beheer, wat navrae aanvaar wat van buite AWS kom.
Bou die pad in die volgorde wat skoon faal
Drie spronge moet bestaan, en elkeen het sy eie manier van faal.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesDie deurstuurder het 'n roete na die eindpuntadresse deur die VPN nodig, en die terugpad moet ook werk. Vir konvensionele DNS op poort 53 antwoord die eindpunt oor UDP en TCP, dus moet albei protokolle toegelaat word en albei moet enige toestandsvolle inspeksie in die middel oorleef.
Kontroleer dan die DNS-aansig apart. 'n Private gehoste sone is net sigbaar vir die VPC's waarmee dit geassosieer is, of deur 'n doelbewuste delingsreëling. 'n Bereikbare eindpunt maak nie op sigself elke private sone oplosbaar in sy resolusiekonteks nie.
'n Uitgaande eindpunt dien die teenoorgestelde rigting en sal nie 'n navraag antwoord wat van jou skootrekenaar inkom nie.
Verifieer van beide kante
Vra vanaf die kliënt teen die deurstuurder, dan vanaf die deurstuurder teen die eindpunt. As die kliënt faal terwyl die deurstuurder slaag, is die gaping tussen daardie twee.
As albei faal, kyk na die sekuriteitsbeleid op die eindpunt en na die bronadres wat dit werklik sien. 'n Deurstuurder agter NAT wys die NAT-adres eerder as die skootrekenaar se VPN-adres, en daardie verskil alleen is genoeg om die navraag te laat val. As albei slaag maar die toepassing steeds faal, gebruik die toepassing moontlik 'n ander resolver as die een wat jy getoets het.
Hou die openbare en private naamruimtes doelbewus apart. Split DNS is 'n beleid wat jy instel, nie 'n neweproduk van een opsoektog wat toevallig data teruggee nie.
Wat ek nie sou doen nie
Ek sou nie 'n NAT-reël byvoeg wat een opsoektog laat werk het nie, en dit 'n ontwerp noem nie.
Ek sou nie elke afgeleë kliënt na die plus-twee-adres wys omdat een toets een keer 'n inskrywing teruggegee het nie. En ek sou nie die eindpunt se sekuriteitsbeleid na die hele VPN-poel verbreed wanneer een enkele deurstuurder toegang nodig het nie. As die organisasie reeds 'n goedgekeurde deurstuurder binne die VPC bedryf, lees daardie ontwerp eerste, want die tweede eindpunt wat jy byvoeg, is die een wat niemand dokumenteer nie.