Zašto privatna DNS imena ne rade na VPN klijentima i gdje provjeriti

Otvorite laptop u hotelskoj sobi, pokrenete klijenta, upišete ime internog servera datoteka i ne dobijete ništa. Tunel prijavljuje vezu, a ping na adresu u istoj podmreži još odgovara, pa je sam transport u redu. Samo ime ne uspijeva, a ta praznina svodi problem na dva mjesta: koji resolver je klijent pitao i može li dobijeni odgovor putovati natrag kroz tunel. Riješite jedno, a drugo preskočite, i kvar se jednostavno preseli.

Prije nego uredite bilo koji profil, provjerite šta klijent radi s imenom. Na Linuxu resolvectl query files.corp.example pokazuje preko kojeg linka i kojeg resolvera je odgovor nastao. Na Windowsu Resolve-DnsName files.corp.example pokazuje server koji je odgovorio i adresu koju je vratio.

Pročitajte odgovor prije nego što bilo šta promijenite

Ako se ime vrati kao NXDOMAIN u nekoliko milisekundi, upit nikada nije stigao do vaše zone i odgovorio je neki javni ili hotelski resolver. Ako se vrati tek nakon duge pauze, nešto na putu odbacuje UDP port 53 i klijent je na kraju pao na rezervu. Ako odgovori ispravnom adresom, ali veza i dalje zapinje, razrješavanje je u redu i vaš problem je u rutiranju ili u samoj usluzi.

Ta podjela na tri štedi sat nagađanja. Kaže vam i da li uopće treba dirati VPN: ime koje se razriješi na ispravnu privatnu adresu već je dokazalo put resolvera, pa je preostali posao na putu podataka.

Podijelite resolver iz unutrašnjosti tunela

Klijenti se dijele u dvije grupe. Jednoj server može zadati resolver tokom uspostavljanja veze; druga drži postavku u lokalnoj datoteci koju nijedan gateway ne može promijeniti na daljinu.

OpenVPN je u prvoj grupi. Na serveru push "dhcp-option DNS 10.8.0.53" i push "dhcp-option DOMAIN corp.example" putuju kontrolnim kanalom, ali samo ako u konfiguraciji klijenta još stoji omogućen pull. Ručno uređen klijent sa pull-filter ignore "dhcp-option" nikada ih neće vidjeti, a taj jedan red objašnjava iznenađujuće mnogo slučajeva tipa „server to gura, ali moj laptop se ne slaže“.

WireGuard je u drugoj grupi, jer protokol uopće nema pregovaranje opcija. Resolver i domena pretrage idu u vlastiti [Interface] blok klijenta kao DNS = 10.8.0.53, corp.example. wg-quick to primjenjuje preko resolvconfa ili systemd-resolveda, a na Windowsu službeni klijent instalira NRPT pravila koja postoje samo dok je tunel podignut: Get-DnsClientNrptPolicy ih izlistava, što to čini brzim načinom da vidite je li klijent ikada primijenio vašu datoteku.

IPsec/IKEv2 stoji između. attr dodatak strongSwana može vratiti DNS server izvučen iz poola, a Windows klijent to obično prihvati, ali profil koji fiksira vlastiti imenski server pobjeđuje sve što gateway ponudi. Na Linux klijentu ekvivalentni ručni korak je resolvectl dns wg0 10.8.0.53 pa resolvectl domain wg0 '~corp.example'; oboje nestaje zajedno s interfejsom, što je upravo ono što želite za postavku ograničenu na tunel.

Ograničite sufiks umjesto da progutate svaki upit

Usmjeriti cijelu listu resolvera klijenta na vaš interni server lako je i obično pogrešno. Tada se svako javno ime razrješava preko izlaza vašeg data centra, CDN-ovi vraćaju udaljene adrese, a jedan ispad resolvera nosi sa sobom i korisnikovo pregledanje.

Šaljite prema unutra samo privatni sufiks. Na systemd-resolvedu, domena koja počinje sa ~ služi samo za rutiranje, pa ~corp.example znači da upiti pod tim sufiksom idu na servere tog linka, dok sve ostalo i dalje koristi fizičku mrežu. Windows radi isto s NRPT pravilima ograničenim na imenski prostor, a macOS s dopunskom datotekom resolvera u /etc/resolver/.

Multicast imena zaslužuju vlastiti odgovor. .local imena su po dizajnu link-local (RFC 6762) i punkt-na-punkt tun interfejs ne nosi tu multicast grupu, pa je dodavanje javnog resolvera neće objaviti, a pitanje internom unicast resolveru za njih vraća NXDOMAIN. Reflektor kao avahi u reflektorskom režimu može premostiti dva segmenta, ali to je odluka na strani servera koju nijedan klijent ne može zahtijevati. Ako printer ili NAS mora biti dostupan po imenu, dajte mu umjesto toga A zapis u svojoj zoni.

Dokažite da odgovor može putovati natrag

Ispravan odgovor koji pokazuje na nedostupnu adresu izgleda točno kao problem resolvera dok ne provjerite rutu. Pitajte kernel kamo bi odgovor išao: ip route get 10.20.5.20 imenuje interfejs i, korisnije, izvornu adresu koju bi koristio.

Pratite samu adresu resolvera. Klijent sa DNS = 10.8.0.53 pored AllowedIPs = 10.20.0.0/16 šalje svoje upite kroz fizičku NIC, gdje tiho umiru, jer resolver nije unutar nijednog prefiksa koji tunel traži. Ta neusklađenost je najčešći jednostruki uzrok kvara u cijelom ovom području i ostaje nevidljiva ako ne uporedite DNS postavku s dozvoljenim prefiksima red po red.

Preklapajući rasponi uzrokuju suprotan kvar. Odgovor je ispravan, ruta postoji i pokazuje na pogrešnog hosta, jer je 192.168.0.0/24 kod kuće specifičniji od rute tunela prema istom rasponu. Prenumerirajte jednu stranu ili progurajte užu rutu, pa potvrdite firewall i povratni put hosta usluge; strongSwanove bilješke o prosljeđivanju pokrivaju sysctl stranu tog puta.

Certifikati su zasebna provjera identiteta koju ljudi pripisuju DNS-u. Ako preglednik prijavi neslaganje imena umjesto greške razrješavanja, pretraga je već radila i SAN na certifikatu je ono što treba popraviti. Testirajte HTTPS na ime, nikada na golu IP adresu.

Ponovo testirajte s klijenta, ne s gatewaya

Testirajte unutar aplikacije na koju se korisnik žali, jer pretraga iz komandne linije ne dokazuje da preglednik ide istim putem. Chromeov sigurni DNS i Firefoxov network.trr.mode mogu potpuno zaobići sistemski resolver, a kad to učine, privatno ime ili ne uspije ili iscuri javnom resolveru. Poređenje resolvectl query s ručno pokrenutim dig @10.8.0.53 files.corp.example kaže vam koji se od ta dva dogodio.

Zatim se odspojite i ponovo spojite prije nego što to nazovete riješenim. Postavke ručno zadane na interfejsu nestaju s interfejsom, a profil koji je izgledao ispravno samo zbog zaboravljene lokalne izmjene pasti će pri sljedećem podizanju.

Kratka kontrolna lista za sljedeću mašinu: ime se razrješava preko resolvera tunela, sufiks je ograničen, a ne globalan, adresa resolvera leži unutar dozvoljenih prefiksa, host iz odgovora odgovara na portu usluge i certifikat pokriva ime koje je korisnik upisao.