A privát DNS működik a VPC-ben, de VPN-en keresztül nem
Az a privát név, amely EC2-ben feloldható, de VPN-en keresztül nem, resolver-útvonal probléma. Olvasd el a hiba alakját, mielőtt szerkeszted a zónarekordot.
Egy privát név feloldódik EC2-példányból, de nem a VPN-en keresztül csatlakozó laptopból, és a zóna jól néz ki a konzolon. Az első ösztön a rekord szerkesztése, ami szinte soha nem a probléma. A rekord válaszol valakinek; csak éppen a laptopodnak nem válaszol. A két hívó közti különbség az, melyik resolverhez fordulnak, és hogy annak a resolvernek van-e támogatott útvonala a VPC DNS-nézetébe.
Azzal kezdem, hogy bebizonyítom a rekord létezését, a maradék időt pedig a lekérdezési útvonalra szánom. Ezek külön rendszerek, és másképp hibáznak.
Olvasd el a hiba alakját, mielőtt bármit megváltoztatsz
Három kimenet három különbséget jelent, és egyetlen lekérdezés elválasztja őket: futtasd a dig parancsot a névre azzal a resolverrel szemben, amelyet az ügyfél valóban használ.
| 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 |
Az időtúllépés a hálózatról szóló állítás. Az NXDOMAIN a DNS-nézetről szóló állítás. A nyilvános válasz a házirendről szóló állítás. Zónarekord szerkesztése időtúllépés közben eldobja az ügy egyetlen hasznos bizonyítékát.
Miért nem távoli resolver a VPC plusz-kettes címe
A CIDR plusz-kettes cím helyi szolgáltatás a VPC-n belüli erőforrásoknak. Az AWS dokumentálja, hogy a lekérdezések továbbítása helyszíni hálózatokból vagy egy másik VPC DNS-kiszolgálóiról közvetlenül erre a címre nem támogatott, és instabil eredményeket adhat.
Ez nem jelenti azt, hogy egy kísérlet soha nem tűnik működőnek. Azt jelenti, hogy a viselkedés nem szerződés, amit segélyszolgálati szkriptbe lehet tenni. A támogatott irány a bejövő Resolver-végpont: egy címpár a VPC-den belül, amely elérhető az általad irányított hálózatból, és elfogadja az AWS-en kívülről érkező lekérdezéseket.
Építsd fel az útvonalat abban a sorrendben, amelyben tisztán hibázik
Három ugrásnak kell léteznie, és mindegyiknek megvan a maga hibamódja.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesA továbbítónak útvonalra van szüksége a végpont címeihez a VPN-en keresztül, és a visszaútnak is működnie kell. Az 53-as porton futó hagyományos DNS esetében a végpont UDP-n és TCP-n válaszol, ezért mindkét protokollt engedélyezni kell, és mindkettőnek át kell élnie a közbenső állapotvizsgálatot.
Utána külön ellenőrizd a DNS-nézetet. A privát hosztolt zóna csak azoknak a VPC-knek látható, amelyekhez hozzá van rendelve, vagy egy szándékos megosztási megállapodás révén. Egy elérhető végpont önmagában nem tesz minden privát zónát feloldhatóvá a maga feloldási környezetében.
A kimenő végpont az ellenkező irányt szolgálja ki, és nem válaszol a laptopodról érkező lekérdezésre.
Ellenőrizd mindkét oldalról
Kérdezz az ügyféltől a továbbító felé, majd a továbbítótól a végpont felé. Ha az ügyfél hibázik, miközben a továbbító sikeres, a különbség a kettő között van.
Ha mindkettő hibázik, nézd meg a végpont biztonsági házirendjét és azt a forrás címet, amelyet valóban lát. A NAT mögötti továbbító a NAT-címet mutatja a laptop VPN-címe helyett, és már ez a különbség elég a lekérdezés eldobásához. Ha mindkettő sikeres, de az alkalmazás továbbra is hibázik, lehet, hogy az alkalmazás más resolvert használ, mint amit teszteltél.
Tartsd szándékosan külön a nyilvános és a privát névteret. A Split DNS egy általad beállított házirend, nem egyetlen keresés mellékhatása, amely véletlenül adatot adott vissza.
Amit nem tennék
Nem adnék hozzá olyan NAT-szabályt, amely egyetlen keresést működésre bírt, és nem nevezném tervnek.
Nem irányítanék minden távoli ügyfelet a plusz-kettes címre csak azért, mert egy teszt egyszer visszaadott egy rekordot. És nem szélesíteném a végpont biztonsági házirendjét az egész VPN-készletre, amikor egyetlen továbbítónak kell hozzáférés. Ha a szervezet már üzemeltet jóváhagyott továbbítót a VPC-n belül, előbb olvasd el azt a tervet, mert a második végpont, amit hozzáadsz, az, amelyet senki nem dokumentál.