DNS az AWS Client VPN-nél: a VPC resolverét használja, ne az alhálózatét

Az endpoint a 10.0.8.0/24 hálózatban van, tehát a resolvernek 10.0.8.2-nek kell lennie. Ez a leggyakrabban hallott érvelés, és kétszeresen hibás. A Route 53 Resolver a VPC elsődleges IPv4-tartományán plusz kettőn válaszol, ami egy 10.0.0.0/16 VPC esetén 10.0.0.2, függetlenül attól, melyik alhálózatot használja az endpoint. A második hiba halkabb: a helyes cím beírása az endpointba nem jelenti azt, hogy a kliens operációs rendszere valaha is kérdezné. Mindkét hiba ugyanazt a tünetet adja: a névfeloldás egyes klienseknél működik, másoknál meghiúsul.

A mítosz az alhálózat-társítással kezdődik

A társítás arról szól, hol élnek a klienskapcsolatok rugalmas hálózati interfészei, nem arról, melyik resolver-cím létezik. Az endpoint alhálózatai a VPC-n belüli címet adnak a klienseknek, és egyik sem hordoz saját resolvert.

Amint különválasztja ezt a két gondolatot, az aritmetika megszűnik titokzatos lenni, és a hibakeresés a klienshez kerül, ahol ezeknek az eseteknek a többsége valójában véget ér.

Számítsa ki a címet az elsődleges VPC-tartományból

Vegye a VPC elsődleges IPv4-CIDR-jét, és adjon kettőt a hálózati címhez. 10.0.0.0/16 10.0.0.2-t ad, 172.31.0.0/16 172.31.0.2-t ad, és a másodlagos tartományú VPC a resolvert az elsődlegesen tartja. Egy 10.0.8.0/24 alhálózat ezen a VPC-n belül nem mozdítja el. Írja fel a címet a VPC ID mellé, mielőtt hozzányúl az endpointhez, mert a szám a VPC tulajdonsága, nem a kapcsolaté.

A VPC a link-local 169.254.169.253 címen is válaszol. Ez a cím a VPC-n belülről elérhető, de nem általános útvonalon elérhető cél egy alagút túlsó végén lévő laptop számára.

Tehát két érvényes resolver-cím van, és egyik sem az alhálózat plusz kettő.

Mit tesz és mit nem tesz az endpoint beállítása

A Client VPN endpointnak vannak DNS-kiszolgáló mezői, és ahol a konzol VPC-resolver lehetőséget kínál, ugyanezt az ötletet tölti ki. Beállításuk megváltoztatja, mit ad a szolgáltatás a klienseknek a kapcsolat létrehozásakor. Nem változtatja meg, mit tesz egy nem kezelt OpenVPN kliens ezzel az értékkel, mert a kliensnek még alkalmaznia kell az operációs rendszeren. Ebből a résből jön a «működik a Mac-emen, de a Linux gépen nem».

Linuxon a resolver-integráció a kapcsolatkezelő tulajdona, nem a felhasználóé. A /etc/resolv.conf kézi szerkesztése bizonyítja, hogy a cím egy munkamenetre működik, majd újracsatlakozáskor eltűnik — ezért jön vissza olyan sok javított eset másnap reggel.

Csatlakozás után a kliensen ellenőrizze az aktív resolvert, ne az endpoint beállítási oldalát.

A split tunneling felülírhat egy helyes resolvert

Split tunnelingnél csak az alagútba betolt útvonalak használatosak. Ha a resolver címe nincs lefedve útvonallal, a lekérdezés a helyi interfészen keresztül távozik, és az otthoni router válaszol rá. Az endpointban lévő cím továbbra is helyes, és a keresés továbbra is meghiúsul. Adja hozzá a resolver útvonalát, majd teszteljen újra.

Az átfedő helyi tartományok ugyanezt az eredményt adják kellemetlenebb módon: a lekérdezés választ kap, csak a rossz kiszolgálótól.

Ne nyisson security groupot az Amazon DNS-címhez

Amikor a keresések időtúllépésbe futnak, az ösztön az, hogy szabályt adjunk hozzá, amely engedélyezi az UDP 53-at a resolver címére. Az AWS dokumentálja, hogy a security groupok és a hálózati ACL-ek nem szűrik az Amazon DNS-forgalmat úgy, ahogy a saját DNS-példány felé irányuló forgalmat szűrik. Ezeknek a szabályoknak a megnyitása semmit nem változtat a VPC resolveren, és ok nélkül tágítja a határt. Az általad üzemeltetett resolver más eset, és valóban saját szabályokat igényel.

Ha mindkettő szerepel a tervben, nézze meg, melyikre mutat valójában a kliens, mielőtt bármelyik szabályt szerkeszti.

Ellenőrizze az útvonalat, aztán mérjen mást

Oldjon fel egy nyilvános nevet, oldjon fel egy privát nevet, amely a VPC-hez társított privát hosztolt zónában van regisztrálva, és olvassa le a kettő között a kliens aktív resolverét. Ez a sorrend választja el a «resolver címe hibás» esetet a «zóna nincs társítva» és a «kliens figyelmen kívül hagyta a beállítást» esettől. Mindegyiknek más a javítása, és egyik sem átviteli teljesítmény-probléma.

A sikeres keresés semmit nem mond a tartós átviteli sebességről, ezért a jelentésnél tartsa külön ezt a két beszélgetést.