Miksi reitittimen oma DNS ohittaa VPN-tunnelin?

Asiakkaiden kyselyt seuraavat tunnelia, kun taas reitittimen omat kyselyt lähtevät WANin kautta, eikä toista ohjaavalla palomuurisäännöllä ole vaikutusta toiseen. Syy ei ole vika: välitetty pyyntö ja pyyntö, jonka reititin itse luo, ovat kaksi erillistä virtaa, ja kumpikin sovitetaan eri osaan kokoonpanoa. Vain asiakkaan puolikkaan tallentaminen antaa varman vastauksen polusta, jota toinen puolikas ei koskaan käytä. Korjaus on ohjata reitittimen resolver tarkoituksella ja testata sitten molemmat polut erikseen.

Mihin virtaan pakettitaltiointi oikeastaan kuuluu

Yksi kysely sisältää kaksi vaihtoa. LAN-asiakas lähettää kyselyn reitittimen resolverille, ja se saapuu välitettynä liikenteenä LAN-liitäntään, joten välitetyille paketeille kirjoitettu reittikäytäntö tai NAT-sääntö voi osua siihen. Sen jälkeen reititin vastaa välimuistista tai avaa osuman puuttuessa oman kyselynsä ylävirran palvelimelle.

Tuon toisen kyselyn lähteenä on reititin itse ja kohteena samoin se itse, ja alusta valitsee sen polun toisesta kokoonpanolohkosta. Molemmat vaihdot kantavat samaa nimeä, eikä kumpikaan ole toisen kopio. Siksi LAN-puolella otettu tallennus todistaa, minne asiakkaan paketti meni, eikä kerro lähtevästä paketista mitään.

Käytännön tarkistus on seurata molempia puolia samanaikaisesti. Listaa reitittimellä resolverin socket, kysy sitä paikallisesti ja tallenna WAN-liitäntä:

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

Jos socket-luettelo näyttää loopback- tai LAN-osoitteeseen sidotun kuuntelijan, reititin vastaa paikallisesti sen sijaan että välittäisi toiselle isännälle. Tallennus näyttää silloin, lähteekö syntyvä ylävirran kysely tunneliliitännän vai WANin kautta, ja se on vastaus, jota reittikäytännön sääntö ei koskaan antaisi.

Miksi reittikäytäntö ei koskaan näe toista kyselyä

Palomuurisäännöt kirjoitetaan liitännälle, lähteelle, kohteelle ja portille, ja ne arvioidaan laitteen läpi kulkeville paketeille. Kysely, jonka reititin luo, ei kulje minkään läpi, koska paikallinen prosessi antaa sen suoraan reititystauluun. Reittikäytäntö ja NAT koskevat siksi vain välitettyä polkua, ja juuri siksi sääntöjoukko voi näyttää täydelliseltä ja jättää silti reitittimen DNS:n tunnelin ulkopuolelle.

Erottelu säilyy jokaisen laiteohjelmiston uudelleenkirjoituksen jälkeen, koska se seuraa paketin polusta eikä ominaisuudesta. Kaikki, mitä laite luo itselleen, olivatpa kyseessä resolverin kyselyt, ajan synkronointi, päivitystarkistukset tai pakettipeilien käyttö, on paikallisesti syntynyttä ja putoaa samaan sokeaan pisteeseen. Siksi kannettavalta tietokoneelta tehty testi ei todista reitittimestä mitään.

Missä pfSense-resolver päättää oman ylävirran polkunsa

pfSense tekee jaon näkyväksi. Asiakasliikenne voidaan ohjata käytännöllä VPN-yhdyskäytävän kautta, kun taas palomuurin oma liikenne seuraa resolverin lähtevää asetusta eikä LAN-sääntöjä. Verkkokäyttöliittymässä tämä asetus on kohdassa Services > DNS Resolver > Outgoing Network Interfaces, ja sen arvo on luettelo liitännöistä, joita resolver saa käyttää ylävirran kyselyihin.

Tunneliliitännän nimeäminen siinä, ja vain se liitäntä, saa reitittimen omat kyselyt seuraamaan tunnelia. Oletusarvoon jätettynä resolver valitsee lähdön reititystaulusta, ja kahden WANin tai VPN:n isännällä se on usein WAN.

Muut laiteohjelmistot paljastavat saman päätöksen toisella nimellä: lähdeosoitteeseen sidottu ylävirran palvelinluettelo, vain välitys -tila tai dokumentoitu reittikäytäntö. Etsittävä asetus on aina se, joka valitsee lähdön tai lähteen paikallisesti luoduille kyselyille. Resolverin kokoonpanon viite dokumentoi tuon vaihtoehdon pfSenselle ja kannattaa lukea ennen muutosta.

Valitse vikakäyttäytyminen ennen asetusta

Kun tunneli kaatuu, kaksi käyttäytymistä on puolustettavissa: pysäyttää ylävirran kyselyt, jotta mitään ei vuoda, tai pudota hyväksytylle resolverille tunnetulla polulla. Molemmat ovat käytäntöjä, eikä kumpikaan ole se, minkä saat oletuksena. Päätä, kumpaa verkko tarvitsee, ennen kuin kosket liitäntäluetteloon.

Vikatilanteessa sulkeutuminen on helpompi puolustaa, mutta se muuttaa tunnelin katkoksen nimien selvityksen katkokseksi jokaiselle reitittimen takana olevalle laitteelle. Paluu pitää toimiston käyttökelpoisena, mutta tunnelin ulkopuolisen ylävirran vaihdon hinnalla, ja sen on oltava hyväksyttävä tarkoituksella eikä vahingossa. Kirjoita valinta muistiin, koska seuraava henkilö, joka näkee resolverin osoitteen VPN:n ulkopuolella, lukee sen vuodoksi, ellei muistiinpano toisin sano. Juuri se muistiinpano erottaa dokumentoidun paluun selittämättömästä havainnosta seuraavan neljänneksen katsauksessa.

Kaksi tapausta monimutkaistaa päätöstä. Yksityiset nimet voivat vaatia sisäisen resolverin, johon tunneli yltää, ja selain tai sovellus, jolla on oma salattu DNS, voi kiertää reitittimen kokonaan, joten määrittämäsi resolver ei aina ole se, jota tietty sovellus käyttää.

Testaa molemmat polut ja pidä tulokset erillään

Selainpohjainen DNS-testi vastaa kapeaan kysymykseen: mitä resolvereita kyseinen selain käytti kyseisen testin olosuhteissa. Se ei inventoi verkon laitteita eikä näe kyselyä, jonka reititin loi itselleen. Käsittele sen tulosta yhtenä datapisteenä, älä auditointeina.

Kysy LAN-asiakkaalta reitittimeltä julkinen nimi ja sitten yksityinen, johon vain sisäisen vyöhykkeesi pitäisi vastata. Epäonnistuminen vain toisessa kyselyssä viittaa nimien välitykseen eikä tunneliin:

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

Laske sitten tunneli alas ja toista molemmat kyselyt. Hylätyt vastaukset tarkoittavat, että resolver sulkeutuu vikatilanteessa; onnistunut vastaus viittaa varasolveriin ja sen käyttämään polkuun. Vertaa sitä kirjoittamaasi muistiinpanoon ja samana minuuttina WAN-liitännältä otettuun tallennukseen.

Pidä havainnot erillään kirjauksessa: asiakkaan ja reitittimen välinen vaihto, reitittimen ja ylävirran välinen vaihto sekä kokoonpano, joka päätti toisen. Myöhempi reititysmuutos käyttää tuota toista vaihtoa ilman varoitusta. Vastaus, joka saapuu muualta kuin VPN:n päätepisteestä, ei ole itsessään vuoto; siitä tulee vuoto vasta, kun kokoonpano valitsi polun vahingossa.