Wêrom giet de eigen DNS fan de router foarby de VPN-tunnel?

Kliïntsyktochten folgje de tunnel, wylst de eigen syktochten fan de router oer de WAN fuortgean, en de brânmuorrerel dy't de iene regelet hat gjin ynfloed op de oare. De reden is gjin bug: in trochstjoerde oanfraach en in oanfraach dy't de router sels makket binne twa aparte streams, en elk wurdt tsjin in oar diel fan de konfiguraasje ferlike. Allinnich de kliïnthelte fange jout in selswis antwurd oer in paad dat de twadde helte nea brûkt. De reparaasje is de resolvers fan de router bewust rjochtsje, en dan de twa paden apart testen.

By hokker stream de pakketopname eins heart

Ien syktocht omfettet twa útwikselings. In LAN-kliïnt stjoert in fraach nei de resolvers fan de router, en dy komt as trochstjoerd ferkear op 'e LAN-ynterface oan, sadat in beliedsrûte of NAT-rel skreaun foar trochstjoerde pakketten dy matsette kin. Dêrnei antwurdet de router út 'e cache of, by in misser, iepenet syn eigen fraach nei in opstream-server.

Dy twadde fraach hat de router as boarne en as eigen bestimmingsplak, en it platfoarm kiest syn paad út in oar konfiguraasjeblok. Beide útwikselings drage deselde namme, en gjinien is in kopy fan de oare. In opname oan 'e LAN-kant bewiist dus wêr't it pakket fan de kliïnt hinne gie en seit neat oer it útgeande pakket.

De praktyske kontrôle is beide kanten tagelyk te besjen. Op de router: list de socket fan de resolvers op, freegje dy lokaal en fange de WAN-ynterface:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

As de socketlist in harker toant dy't oan it loopback- of LAN-adres bûn is, antwurdet de router lokaal ynstee fan troch te stjoeren nei in oare host. De opname toant dan oft de resultearjende opstream-fraach oer de tunnel-ynterface of oer de WAN fuortgiet, en dat is it antwurd dat de beliedsrûterel nea jaan soe.

Wêrom't de beliedsrûte de twadde fraach nea sjocht

Brânmuorrerels wurde skreaun tsjin in ynterface, in boarne, in bestimmingsplak en in poarte, en se wurde beoardiele foar pakketten dy't troch it kast gean. In fraach dy't de router sels makket giet nearne troch, want in lokaal proses jout dy streekrjocht oan 'e rûtingstabel. Beliedsrûting en NAT jilde dêrom allinnich foar it trochstjoerde paad, en dêrom kin in regelset folslein lykje en dochs de DNS fan de router bûten de tunnel litte.

It ûnderskie oerlibbet elke firmware-herskriuwing om't it út it paad fan it pakket folget en net út in funksje. Alles wat it kast foar himsels makket, itsij resolvers-fragen, tiidsinchronisaasje, fernijingskontrôles of tagong ta pakketspiegels, is lokaal ûntstien en falt yn deselde bline flek. Dêrom bewiist in test fan in laptop ôf neat oer de router.

Wêr't in pfSense-resolvers syn eigen opstream-paad beslút

pfSense makket de split sichtber. Kliïntferkear kin mei beliedsrûting troch in VPN-poarte gean, wylst it eigen ferkear fan 'e brânmuorre de útgongynstelling fan 'e resolvers folget ynstee fan 'e LAN-regels. Yn 'e webynterface sit dy ynstelling ûnder Services > DNS Resolver > Outgoing Network Interfaces, en syn wearde is de list fan ynterfaces dy't de resolvers foar opstream-fragen brûke mei.

De tunnel-ynterface dêr neame, en allinnich dy ynterface, is wat de eigen syktochten fan de router de tunnel folgje lit. Lit op 'e standert, dan kiest de resolvers in útgong út 'e rûtingstabel, dy't op in host mei dûbele WAN of VPN faak de WAN is.

Oare firmware iepenbieret deselde beslissing ûnder in oar label: in opstream-tsjinnerlist bûn oan in boarneadres, in modus fan allinnich trochstjoere, of in dokumintearre rûtebelied. De ynstelling dy't jo sykje moatte is altyd dy't in útgong of in boarne kiest foar lokaal makke fragen. De referinsje foar resolvers-konfiguraasje dokumintearret dy opsje foar pfSense en is it lêzen wurdich foar de feroaring.

Kies it falgedrach foar de ynstelling

As de tunnel falt, binne twa gedrachsmanieren te ferdigenjen: opstream-fragen stopje sadat neat lekt, of weromfalle nei in goedkarde resolvers op in bekend paad. Beide binne belied, en gjinien is wat jo standert krije. Beslút hokker it netwurk nedich hat foardat jo de ynterfacelist oanreitsje.

Sluten by fal is makliker te ferdigenjen, mar it makket in tunnelútfal ta in namme-oplossingsútfal foar elk apparaat efter de router. Weromfal hâldt it kantoar brûkber, mar tsjin de priis fan in opstream-útwikseling bûten de tunnel dy't bewust akseptabel wêze moat en net tafallich. Skriuw de kar op, want de folgjende persoan dy't in resolvers-adres bûten de VPN sjocht, sil it as in lek lêze, útsein as in notysje oars seit. Dy notysje is wat in dokumintearre weromfal skiedt fan in ûnferklearre fynst yn 'e resinsje fan it folgjende kwartaal.

Twa gefallen meitsje de beslissing kompleks. Partikuliere nammen kinne in ynterne resolvers nedich hawwe dy't de tunnel berikke kin, en in browser of applikaasje mei eigen fersifere DNS kin de router folslein foarbygean, sadat de resolvers dy't jo konfigurearre hawwe net altyd dejinge is dy't in bepaalde app brûkt.

Test beide paden en hâld de resultaten apart

In browser-basearre DNS-test beantwurdet in smelle fraach: hokker resolvers brûkte dy browser, ûnder de omstannichheden fan dy test. Hy ynventarisearret de apparaten yn it netwurk net en kin in fraach dy't de router foar himsels makke net sjen. Behannelje syn útfier as ien datapunt en net as in audit.

Freegje fan in LAN-kliïnt de router om in iepenbiere namme en dan om in partikuliere dy't allinnich jo ynterne sône beantwurdzje moat. In fal by allinnich de twadde fraach wiist op nametrochstjoering en net op de tunnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Bring dan de tunnel del en werhelje beide fragen. Antwurden dy't wegere wurde betsjutte dat de resolvers by fal slút; in suksesfol antwurd wiist op in weromfal-resolvers en it paad dat dy brûkte. Ferlykje dat mei de notysje dy't jo skreaun hawwe en mei in opname op 'e WAN-ynterface út deselde minút.

Hâld de waarnimmings apart yn it rekord: de útwikseling fan kliïnt en router, de útwikseling fan router en opstream, en de konfiguraasje dy't de twadde besleat. In lettere rûteferoaring sil dy twadde útwikseling sûnder warskôging oefenje. In antwurd dat fan in oar plak as it VPN-einpunt komt is op himsels gjin lek; it wurdt pas in lek as de konfiguraasje dat paad tafallich keazen hat.