Kial la propra DNS de la enkursigilo preteriras la VPN-tunelon?

Klientaj informpetoj sekvas la tunelon, dum la propraj informpetoj de la enkursigilo eliras tra la WAN, kaj la fajroŝirmila regulo, kiu regas unu, havas neniun efikon al la alia. La kialo ne estas cimo: plusendita peto kaj peto, kiun la enkursigilo mem kreas, estas du apartaj fluoj, kaj ĉiu estas kongruigata kun malsama parto de la agordo. Kapti nur la klientan duonon produktas memfidan respondon pri vojo, kiun la dua duono neniam uzas. La riparo estas celkonscie direkti la solvilon de la enkursigilo kaj poste testi la du vojojn aparte.

Al kiu fluo la paketa kaptado vere apartenas

Unu informpeto enhavas du interŝanĝojn. LAN-kliento sendas informpeton al la solvilo de la enkursigilo, kaj ĝi alvenas kiel plusendita trafiko sur la LAN-interfaco, do politika vojo aŭ NAT-regulo skribita por plusenditaj pakoj povas kongruigi ĝin. Poste la enkursigilo respondas el la kaŝmemoro aŭ, ĉe maltrafo, malfermas sian propran informpeton al suprena servilo.

Tiu dua informpeto havas la enkursigilon kiel fonton kaj kiel sian propran celon, kaj la platformo elektas ĝian vojon el malsama agorda bloko. Ambaŭ interŝanĝoj portas la saman nomon, kaj neniu estas kopio de la alia. Kaptado prenita ĉe la LAN-flanko do pruvas, kien iris la pako de la kliento, kaj diras nenion pri la eliranta pako.

La praktika kontrolo estas observi ambaŭ flankojn samtempe. Sur la enkursigilo listigu la solvilan ingon, demandu ĝin loke kaj kaptu la WAN-interfacon:

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

Se la ingolisto montras aŭskultanton ligitan al la loopback- aŭ LAN-adreso, la enkursigilo respondas loke anstataŭ plusendi al alia gastiganto. La kaptado tiam montras, ĉu la rezulta suprena informpeto eliras tra la tunela interfaco aŭ tra la WAN, kaj tio estas la respondo, kiun la politika voja regulo neniam donus.

Kial la politika vojo neniam vidas la duan informpeton

Fajroŝirmilaj reguloj estas skribataj laŭ interfaco, fonto, celo kaj pordo, kaj ili estas taksataj por pakoj, kiuj pasas tra la skatolo. Informpeto, kiun la enkursigilo mem kreas, pasas tra nenio, ĉar loka procezo transdonas ĝin rekte al la vojiga tabelo. Politika vojigo kaj NAT do validas nur por la plusendita vojo, kaj ĝuste tial reguloaro povas ŝajni kompleta kaj tamen lasi la DNS de la enkursigilo ekster la tunelo.

Tiu distingo postvivas ĉiun firmvaran reverkon, ĉar ĝi devenas de la paka vojo kaj ne de trajto. Ĉio, kion la skatolo kreas por si mem, ĉu solvilaj informpetoj, ĉu temposinkronigo, ĉu ĝisdatigaj kontroloj, ĉu aliro al paketaj speguloj, estas loke originita kaj falas en la saman blindan punkton. Tial ankaŭ testo, kiu funkcias el tekkomputilo, pruvas nenion pri la enkursigilo.

Kie la solvilo de pfSense decidas sian propran suprenan vojon

pfSense igas la disigon videbla. Klienta trafiko povas esti politike vojigita tra VPN-kluzo, dum la propra trafiko de la fajroŝirmilo sekvas la eliran agordon de la solvilo anstataŭ la LAN-regulojn. En la reta interfaco tiu agordo troviĝas sub Services > DNS Resolver > Outgoing Network Interfaces, kaj ĝia valoro estas la listo de interfacoj, kiujn la solvilo rajtas uzi por suprenaj informpetoj.

Nomi tie la tunelan interfacon, kaj nur tiun interfacon, estas tio, kio igas la proprajn informpetojn de la enkursigilo sekvi la tunelon. Laste lasita je la default, la solvilo elektas eliron el la vojiga tabelo, kiu sur gastiganto kun duobla WAN aŭ VPN ofte estas la WAN.

Alia firmvaro elmetas la saman decidon sub alia etikedo: listo de suprenaj serviloj ligita al fonta adreso, reĝimo nur-plusenda aŭ dokumentita voja politiko. La agordo, kiun vi devas serĉi, estas ĉiam tiu, kiu elektas eliron aŭ fonton por loke kreitaj informpetoj. La referenco pri solvila agordo dokumentas tiun opcion por pfSense kaj indas legi antaŭ la ŝanĝo.

Elektu la malsukcesan konduton antaŭ la agordo

Kiam la tunelo falas, du kondutoj estas defendeblaj: haltigi suprenajn informpetojn, por ke nenio liku, aŭ retroiri al aprobita solvilo sur konata vojo. Ambaŭ estas politikoj, kaj nek estas tio, kion vi ricevas defaŭlte. Decidu, kiun la reto bezonas, antaŭ ol tuŝi la interfacan liston.

Fermiĝo ĉe malsukceso estas pli facile defendebla, sed ĝi transformas tunelan interrompon en nomrezolvan interrompon por ĉiu aparato malantaŭ la enkursigilo. Retroiro tenas la oficejon uzebla, je la kosto de suprena interŝanĝo ekster la tunelo, kiu devas esti akceptebla intence, ne hazarde. Skribu la elekton, ĉar la sekva persono, kiu vidos solvilan adreson ekster la VPN, legos ĝin kiel likon, krom se noto diras alie. Tiu noto estas tio, kio apartigas dokumentitan retroiron de neklarigita trovaĵo en la revizio de la sekva kvartalo.

Du kazoj komplikigas la decidon. Privataj nomoj eble bezonas enan solvilon, kiun la tunelo povas atingi, kaj retumilo aŭ aplikaĵo kun propra ĉifrita DNS povas tute preteriri la enkursigilon, do la solvilo, kiun vi agordis, ne ĉiam estas tiu, kiun donita aplikaĵo uzas.

Testu ambaŭ vojojn kaj tenu la rezultojn aparte

Retumila DNS-testo respondas mallarĝan demandon: kiujn solvilojn tiu retumilo uzis, sub la kondiĉoj de tiu testo. Ĝi ne inventaras la aparatojn en la reto kaj ne povas vidi informpeton, kiun la enkursigilo kreis por si mem. Traktu ĝian eligon kiel unu datumpunkton, ne kiel revizion.

De LAN-kliento, demandu la enkursigilon pri publika nomo kaj poste pri privata, kiun nur via ena zono devus respondi. Malsukceso nur ĉe la dua informpeto montras al nomplusendado, ne al la tunelo:

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

Poste mallevu la tunelon kaj ripetu ambaŭ informpetojn. Rifuzitaj respondoj signifas, ke la solvilo fermiĝas ĉe malsukceso; sukcesa respondo montras al rezerva solvilo kaj al la vojo, kiun ĝi uzis. Komparu tion kun la noto, kiun vi skribis, kaj kun kaptado sur la WAN-interfaco prenita en la sama minuto.

Tenu la observojn aparte en la protokolo: la interŝanĝo de kliento kun enkursigilo, la interŝanĝo de enkursigilo kun suprena servilo kaj la agordo, kiu decidis la duan. Posta vojiga ŝanĝo ekzercos tiun duan interŝanĝon sen averto. Respondo, kiu alvenas de aliloke ol la VPN-finpunkto, mem ne estas liko; ĝi fariĝas liko nur kiam la agordo elektis tiun vojon hazarde.