Yksityinen DNS toimii VPC:ssä mutta ei VPN:n kautta
Yksityinen nimi, joka ratkeaa EC2:ssa mutta ei VPN:n kautta, on resolver-polkujen ongelma. Lue vian muoto ennen kuin muokkaat vyöhykkeen tietuetta.
Yksityinen nimi ratkeaa EC2-instanssista mutta ei VPN:n kautta kytketystä kannettavasta, ja vyöhyke näyttää konsolissa oikealta. Ensimmäinen vaisto on muokata tietuetta, mikä ei lähes koskaan ole ongelma. Tietue vastaa jollekin; se ei vain vastaa kannettavallesi. Kahden kutsujan välinen ero on siinä, mitä resolveria ne kysyvät ja onko sillä resolverilla tuettu polku VPC:n DNS-näkymään.
Aloitan todistamalla, että tietue on olemassa, ja käytän loput ajasta kyselyn polkuun. Ne ovat erillisiä järjestelmiä ja epäonnistuvat eri tavoin.
Lue vian muoto ennen kuin muutat mitään
Kolme lopputulosta tarkoittaa kolmea eri asiaa, ja yksi kysely erottaa ne: aja dig nimelle sitä resolveria vasten, jota asiakas todella käyttää.
| 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 |
Aikakatkaisu on väite verkosta. NXDOMAIN on väite DNS-näkymästä. Julkinen vastaus on väite käytännöstä. Vyöhykkeen tietueen muokkaaminen aikakatkaisun aikana heittää pois tapauksen ainoan hyödyllisen todisteen.
Miksi VPC:n plus-kaksi-osoite ei ole etäresolveri
CIDR plus-kaksi -osoite on paikallinen palvelu VPC:n sisäisille resursseille. AWS dokumentoi, että kyselyjen välittäminen paikallisista verkoista tai toisen VPC:n DNS-palvelimista suoraan tuohon osoitteeseen ei ole tuettua ja voi tuottaa epävakaita tuloksia.
Se ei tarkoita, ettei kokeilu koskaan näyttäisi toimivan. Se tarkoittaa, että käyttäytyminen ei ole sopimus, jonka voi laittaa tukiskriptiin. Tuettu suunta on saapuva Resolver-päätepiste: osoitepari VPC:ssäsi, johon pääsee hallitsemastasi verkosta ja joka hyväksyy AWS:n ulkopuolelta saapuvia kyselyjä.
Rakenna polku siinä järjestyksessä, jossa se epäonnistuu puhtaasti
Kolmen hypyn on oltava olemassa, ja jokaisella on oma tapansa epäonnistua.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesVälittäjä tarvitsee reitin päätepisteen osoitteisiin VPN:n kautta, ja paluupolun on myös toimittava. Perinteiselle DNS:lle portissa 53 päätepiste vastaa UDP:n ja TCP:n yli, joten molemmat protokollat on sallittava ja molempien on selvittävä välikerroksen tilallistesta tarkistuksesta.
Tarkista sitten DNS-näkymä erikseen. Yksityinen ylläpidetty vyöhyke näkyy vain niille VPC:ille, joihin se on liitetty, tai tarkoituksellisen jakamisjärjestelyn kautta. Saavutettava päätepiste ei itsessään tee kaikista yksityisistä vyöhykkeistä ratkaistavia sen ratkaisukontekstissa.
Lähtevä päätepiste palvelee vastakkaiseen suuntaan eikä vastaa kannettavastasi tulevaan kyselyyn.
Vahvista molemmista päistä
Kysy asiakkaalta välittäjälle ja sitten välittäjältä päätepisteelle. Jos asiakas epäonnistuu välittäjän onnistuessa, ero on näiden kahden välissä.
Jos molemmat epäonnistuvat, katso päätepisteen käytäntöä ja lähdeosoitetta, jonka se todella näkee. NAT:n takana oleva välittäjä esittää NAT-osoitteen kannettavan VPN-osoitteen sijaan, ja pelkkä tämä ero riittää pudottamaan kyselyn. Jos molemmat onnistuvat mutta sovellus epäonnistuu yhä, sovellus saattaa käyttää eri resolveria kuin testaamasi.
Pidä julkinen ja yksityinen nimiavaruus tarkoituksella erillään. Split DNS on käytäntö, jonka määrität, ei yhden haun sivuvaikutus, joka sattui palauttamaan dataa.
Mitä en tekisi
En lisäisi NAT-sääntöä, joka sai yhden haun toimimaan, ja kutsuisi sitä suunnitteluksi.
En ohjaisi jokaista etäasiakasta plus-kaksi-osoitteeseen vain siksi, että yksi testi palautti kerran tietueen. Enkä laajentaisi päätepisteen käytäntöä koko VPN-altaaseen, kun yksi välittäjä tarvitsee pääsyn. Jos organisaatio jo pyörittää hyväksyttyä välittäjää VPC:ssä, lue se suunnitelma ensin, koska toinen päätepiste, jonka lisäät, on se, jota kukaan ei dokumentoi.