Nem működik a Pritunl privát DNS-e? Adjon hozzá egy szűk resolver-útvonalat

A privát nevek mindenki számára feloldódnak a vállalati hálózaton, és mindenki számára lejárnak a VPN-en. A resolver válaszol az átjárónak, az útvonal hozzá létezik, és a lekérdezés mégsem kap soha választ. Nem egy másik nyilvános resolver vagy egy szélesebb útvonal hiányzik: hanem egy forrás-cím, amelyre a privát DNS-kiszolgáló hajlandó válaszolni.

Erősítse meg, hogy a resolver elutasítja az ügyfélkészletét

Kezdje annak bizonyításával, hogy a hiba a forrásról szól, nem az elérhetőségről. Csatlakozott ügyfélről kérdezze meg közvetlenül a privát resolvert, és figyelje, hogy a kérés időtúllépésbe fut-e vagy elutasításként tér vissza. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 időtúllépése, miközben ugyanaz a lekérdezés az átjáróról sikeres, hozzáférési házirendre utal a resolveren. A SERVFAIL válasz egészen másra utal, általában a zónára vagy a felső szintű továbbítóra.

Jegyezze fel az ügyfél címét a teszt előtt. ip -4 addr show tun0 az ügyfélen, vagy a konzolon látható bérlet megmondja, melyik készletet látja a resolver.

Ezután erősítse meg, hogy az útvonal egyáltalán létezik. Az az útvonal, amely a resolver címét az alagútba küldi, előfeltétel, nem a megoldás; ha a csomagok soha nem érkeznek meg, a forrásházirendet soha nem vizsgálják. Ellenőrizze ezt az ügyfélen a ip route get 10.40.0.53 paranccsal.

Adjon hozzá egy gazdaútvonalat ahelyett, hogy mindent lefordítana

A Pritunl privát DNS-útmutatója a szűk megoldást írja le: egy NAT-os /32 útvonalat a resolver címéhez, ezt a címet az ügyfelek DNS-kiszolgálójaként kiválasztva. Az útvonal csak a DNS-forgalom esetében változtatja meg a resolver által látott forrást. Az alkalmazásforgalom megtartja a forrásmegőrző kialakítást, amelyet ehhez választott.

A kiszolgáló támogatott útvonaltulajdonosán keresztül konfigurálja, miután átnézte a meglévő útvonalakat átfedés szempontjából. A fenti példában az úti cél a NAT-os 10.40.0.53/32, és az ügyfélkészlet 10.90.0.0/24 marad. Ne fordítsa le a teljes privát tartományt egyetlen szolgáltatás javításához, mert minden olyan további házirend, amely az ügyfél valódi címére támaszkodik, elkezdi helyette az átjárót látni. Erősítse meg a resolver által ténylegesen kapott címet úgy, hogy egy tesztkeresés során figyeli a lekérdezési naplóját. Egy gazdaútvonal önmagában semmit sem bizonyít a fordításról vagy az engedélyről.

A resolvernek továbbra is engedélyeznie kell a lefordított forrást UDP-n és TCP-n, és válaszainak vissza kell tudniuk térni. A forrás megváltoztatása nem hozhat létre hiányzó zónát vagy rekordot.

Döntse el, hogy a kiszolgáló vagy az ügyfél küldi a lekérdezést

A Pritunl egy DNS-proxy elrendezést is dokumentál a VPN Client DNS Mappinghez kapcsolva, ahol a kiszolgáló továbbítja a felső szintű lekérdezéseket az ügyfelek helyett. Ebben a modellben a felső szintű forrás a kiszolgáló saját hálózati környezetéhez tartozik, és az ügyféloldali kivétel a rossz megoldás.

Azonosítsa, melyik modell aktív, mielőtt bármit hozzáad. Három átfedő javítás, egy proxy, az ügyfél resolverének felülírása és egy kézi NAT-parancsfájl általában azt jelenti, hogy senki nem állapította meg: melyik összetevőnek kell a lekérdezést küldenie. Ellenőrizze a bootstrapot is: egy csak privát resolver nem lehet az egyetlen módja a végpont megtalálásának az alagút létezése előtt, és a resolver állandó módosítása nem élheti túl a kapcsolatot.

Privát lekérdezést teszteljen, ne nyilvános weboldalt

A módosítás alkalmazása és az újracsatlakozás után vizsgálja meg az ügyfél tényleges resolver-konfigurációját, majd oldjon fel egy nevet, amelyről tudja, hogy csak a privát zónában létezik. A dig intranet.example.net kifejezett kiszolgáló nélkül megmutatja, mit használ az ügyfél valójában. Kövesse egy kéréssel arra a címre, amelyet ez a keresés visszaadott, mert a feloldás és a szolgáltatáshoz való hozzáférés külön lépések. Egy böngésző, amely nyilvános oldalakat tölt be DNS-over-HTTPS-en keresztül, semmit sem bizonyít az operációs rendszer privát resolver-útvonaláról. Egy nyilvános másodlagos resolver sem hatóság egy belső zónához.

Jegyezze fel a resolver címét, a /32 útvonalat és az ügyfél DNS-beállítását együtt a kiszolgáló jegyzeteiben. Ennek a konfigurációnak a fele önmagában visszaállítva újratermeli az eredeti hibát.

Végül erősítse meg, hogy az alagút a sikeres DNS után is irányítja az alkalmazás úti célját. Az útvonal, a szolgáltatáshoz való hozzáférés és a hitelesítés független marad a névfeloldástól, és egy működő keresés semmit sem mond az átviteli teljesítményről. Ha a privát oldal lassú, de feloldódik, a resolver elvégezte a dolgát, és a probléma átkerült az útvonalra.