Af hverju fer eigið DNS beinisins fram hjá VPN-göngunum?

Uppflettingar biðlara fylgja göngunum á meðan eigin uppflettingar beinisins fara út um WAN, og eldveggsreglan sem stjórnar öðru hefur engin áhrif á hitt. Ástæðan er ekki villa: framsend beiðni og beiðni sem beinirinn býr sjálfur til eru tvö aðskilin flæði, og hvort um sig er parað við annan hluta stillinganna. Að grípa aðeins biðlarahlutann gefur öruggt svar um slóð sem seinni hlutinn notar aldrei. Lagfæringin er að beina leysanda beinisins viljandi og prófa svo slóðirnar tvær í sitthvoru lagi.

Hvaða flæði pakkagreipin tilheyrir í raun

Ein uppfletting felur í sér tvö skipti. LAN-biðlari sendir fyrirspurn til leysanda beinisins, og hún berst sem framsend umferð á LAN-tenginu, þannig að stefnuvegur eða NAT-regla sem skrifuð er fyrir framsend pakka getur passað við hana. Síðan svarar beinirinn úr skyndiminni eða, ef ekkert finnst, opnar sína eigin fyrirspurn til uppstreymisþjóns.

Sú seinni fyrirspurn hefur beininn sjálfan sem uppsprettu og áfangastað, og kerfið velur slóð hennar úr öðrum stillingarhluta. Bæði skiptin bera sama nafn, og hvort um sig er ekki eintak af hinu. Því sannar grep sem tekið er á LAN-hlið hvert pakki biðlarans fór og segir ekkert um útfarandi pakkann.

Hagnýta prófið er að fylgjast með báðum hliðum á sama tíma. Á beininum: skráðu sæti leysandans, spurðu það staðbundið og greindu WAN-tengið:

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

Ef sætalistinn sýnir hlustanda bundinn við loopback- eða LAN-tölu svarar beinirinn staðbundið í stað þess að framsenda til annars hýsils. Grepið sýnir þá hvort uppstreymisfyrirspurnin sem verður til fer út um tengi ganganna eða um WAN, og það er svarið sem stefnuvegsreglan hefði aldrei gefið.

Af hverju stefnuvegurinn sér aldrei seinni fyrirspurnina

Eldveggsreglur eru skrifaðar fyrir tengi, uppsprettu, áfangastað og port, og þær eru metnar fyrir pakka sem fara í gegnum tækið. Fyrirspurn sem beinirinn býr til fer í gegnum ekkert, því staðbundið ferli afhendir hana beint til leiðartöflunnar. Stefnumiðað leiðarval og NAT eiga því aðeins við framsendu slóðina, og einmitt þess vegna getur reglusafn litið út fyrir að vera fullkomið og samt skilið DNS beinisins eftir utan ganganna.

Þessi greinarmunur lifir af hverja endurskrifun fastbúnaðar því hann leiðir af slóð pakkans en ekki eiginleika. Allt sem tækið býr til fyrir sjálft sig, hvort sem það eru fyrirspurnir leysandans, tímastilling, uppfærsluprófanir eða aðgangur að pakkaspegli, er staðbundið að uppruna og lendir í sama blinda blettinum. Þess vegna sannar próf frá fartölvu ekkert um beininn.

Hvar leysandi pfSense ákveður sína eigin uppstreymisslóð

pfSense gerir skiptinguna sýnilega. Hægt er að beina umferð biðlara með stefnu í gegnum VPN-gátt á meðan eigin umferð eldveggsins fylgir útstillingu leysandans í stað LAN-reglna. Í vefviðmótinu er sú stilling undir Services > DNS Resolver > Outgoing Network Interfaces, og gildi hennar er listinn yfir tengi sem leysandinn má nota fyrir uppstreymisfyrirspurnir.

Að nefna tengi ganganna þar, og aðeins það tengi, er það sem lætur eigin uppflettingar beinisins fylgja göngunum. Ef það er látið vera sjálfgefið velur leysandinn útgang úr leiðartöflunni, sem á hýsli með tveimur WAN eða VPN er oft WAN.

Annar fastbúnaður sýnir sömu ákvörðun undir öðru heiti: listi uppstreymisþjóna bundinn við uppsprettutölu, hamur þar sem aðeins er framsent, eða skjalfest stefna um leiðarval. Stillingin sem leita skal að er alltaf sú sem velur útgang eða uppsprettu fyrir fyrirspurnir sem búnar eru til staðbundið. Tilvísun um stillingu leysandans skjalfestir þann valkost fyrir pfSense og er þess virði að lesa fyrir breytinguna.

Veldu hegðun við bilun fyrir stillinguna

Þegar göngin falla eru tvær hegðanir verjanlegar: stöðva uppstreymisfyrirspurnir svo ekkert leki, eða falla aftur á samþykktan leysanda á þekktri slóð. Báðar eru stefnur, og hvorug er það sem fæst sjálfgefið. Ákveddu hvora netið þarf áður en þú snertir tengjalistann.

Lokun við bilun er auðveldari að verja, en hún breytir niðurföllum ganganna í niðurfall nafnaupplausnar fyrir hvert tæki að baki beininum. Afturhvarfið heldur skrifstofunni nothæfri, en á kostnað uppstreymisskipta utan ganganna sem verða að vera ásættanleg af ásetningi en ekki fyrir tilviljun. Skrifaðu valið niður, því næsta manneskja sem sér leysandatölu utan VPN mun lesa það sem leka nema athugasemd segi annað. Sú athugasemd er það sem greinir skjalfest afturhvarf frá óútskýrðri niðurstöðu í endurskoðun næsta ársfjórðungs.

Tvö tilvik flækja ákvörðunina. Einkanöfn gætu þurft innri leysanda sem göngin ná til, og vafri eða forrit með sitt eigið dulkóðaða DNS getur farið alveg fram hjá beininum, þannig að leysandinn sem þú stilltir er ekki alltaf sá sem tiltekið forrit notar.

Prófaðu báðar slóðir og haltu niðurstöðunum aðskildum

DNS-próf í vafra svarar þröngri spurningu: hvaða leysendur sá vafri notaði við skilyrði þess prófs. Það tekur ekki saman tækin á netinu og getur ekki séð fyrirspurn sem beinirinn bjó til fyrir sig. Meðhöndlaðu úttak þess sem einn gagnapunkt en ekki endurskoðun.

Frá LAN-biðlara, biddu beininn um opinbert nafn og svo einkanaft sem aðeins innra svæðið þitt ætti að svara. Bilun aðeins á seinni fyrirspurn bendir til framsendingar nafna en ekki ganganna:

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

Láttu þá göngin falla og endurtaktu báðar fyrirspurnirnar. Hafnað svör þýða að leysandinn lokar við bilun; árangursríkt svar bendir til varaleysanda og slóðarinnar sem hann notaði. Berðu það saman við athugasemdina sem þú skrifaðir og grep á WAN-tenginu sem tekið var á sömu mínútu.

Haltu athugununum aðskildum í skránni: skiptum biðlara og beinis, skiptum beinis og uppstreymis, og stillingunni sem réð hinu seinni. Síðari breyting á leiðarvali mun nýta þau seinni skipti án viðvörunar. Svar sem berst annars staðar frá en VPN-endapunktinum er ekki leki út af fyrir sig; það verður leki aðeins þegar stillingin valdi þá slóð fyrir tilviljun.