Waarom omseil die roeteerder se eie DNS die VPN-tonnel?

Kliënt-soektogte volg die tonnel, terwyl die roeteerder se eie soektogte oor die WAN vertrek, en die vuurmuurreël wat die een beheer het geen uitwerking op die ander nie. Die rede is nie ’n fout nie: ’n deurgegee versoek en ’n versoek wat die roeteerder self skep, is twee afsonderlike strome, en elkeen word teen ’n ander deel van die opstelling getoets. Om net die kliënt-helfte vas te vang, lewer ’n selfversekerde antwoord oor ’n pad wat die tweede helfte nooit gebruik nie. Die oplossing is om die roeteerder se oplosser doelbewus te rig en dan die twee paaie afsonderlik te toets.

Watter stroom die pakkie-opvang eintlik aan behoort

Een soektog behels twee uitruilings. ’n LAN-kliënt stuur ’n navraag na die roeteerder se oplosser, en dit kom as deurgegee verkeer op die LAN-koppelvlak aan, sodat ’n beleidsroete of NAT-reël wat vir deurgegee pakkies geskryf is, dit kan pas. Die roeteerder antwoord dan uit die kas, of, by ’n misslag, maak sy eie navraag na ’n opstroom-bediener oop.

Daardie tweede navraag het die roeteerder as sy bron en sy eie bestemming, en die platform kies sy pad uit ’n ander opstellingsblok. Albei uitruilings dra dieselfde naam, en nie een is ’n kopie van die ander nie. ’n Opvang wat aan die LAN-kant geneem is, bewys dus waar die kliënt se pakkie heen gegaan het en sê niks oor die uitgaande een nie.

Die praktiese kontrole is om albei kante gelyktydig te dophou. Op die roeteerder, lys die oplosser-sok, vra dit plaaslik en vang die WAN-koppelvlak:

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

As die sok-lys ’n luisteraar wys wat aan die loopback- of LAN-adres gebind is, antwoord die roeteerder plaaslik eerder as om na ’n ander gasheer deur te stuur. Die opvang wys dan of die gevolglike opstroom-navraag oor die tonnel-koppelvlak of oor die WAN vertrek, wat die antwoord is wat die beleidsroete-reël nooit sou gee nie.

Waarom die beleidsroete die tweede navraag nooit sien nie

Vuurmuurreëls word teen ’n koppelvlak, ’n bron, ’n bestemming en ’n poort geskryf, en hulle word geëvalueer vir pakkies wat deur die boks gaan. ’n Navraag wat die roeteerder self skep, gaan deur niks, want ’n plaaslike proses gee dit regstreeks aan die roetertabel. Beleidsroetering en NAT geld dus net vir die deurgegee pad, en daarom kan ’n reëlstel volledig lyk en tog die roeteerder se DNS buite die tonnel laat.

Die onderskeid oorleef elke firmware-herbeskrywing omdat dit uit die pakkie-pad volg en nie uit ’n funksie nie. Enigiets wat die boks vir homself skep, of dit oplosser-navrae, tydsinchronisering, opdateringskontroles of pakket-spieëltoegang is, is plaaslik ontstaan en beland in dieselfde blindekol. Dit is ook waarom ’n toets wat van ’n skootrekenaar af werk, niks oor die roeteerder bewys nie.

Waar ’n pfSense-oplosser sy eie opstroom-pad bepaal

pfSense maak die skeiding sigbaar. Kliënt-verkeer kan deur ’n VPN-gateway beleidsgerig word terwyl die vuurmuur se eie verkeer die oplosser se uitgaande instelling volg eerder as die LAN-reëls. In die webkoppelvlak woon daardie instelling onder Services > DNS Resolver > Outgoing Network Interfaces, en sy waarde is die lys koppelvlakke wat die oplosser vir opstroom-navrae mag gebruik.

Om die tonnel-koppelvlak daar te noem, en net daardie koppelvlak, is wat die roeteerder se eie soektogte die tonnel laat volg. Gelaat by die verstek, kies die oplosser ’n uitgang uit die roetertabel, wat op ’n dubbel-WAN- of VPN-gasheer dikwels die WAN is.

Ander firmware stel dieselfde besluit onder ’n ander etiket bloot: ’n opstroom-bedienerlys wat aan ’n bronadres gebind is, ’n slegs-deurstuur-modus, of ’n gedokumenteerde roetebeleid. Die instelling om na te soek is altyd die een wat ’n uitgang of ’n bron vir plaaslik geskepte navrae kies. Die verwysing vir oplosser-opstelling dokumenteer daardie opsie vir pfSense en is die moeite werd om te lees voor die verandering.

Kies die falingsgedrag voor die instelling

Twee gedragswyses is verdedigbaar wanneer die tonnel wegval: stop opstroom-navrae sodat niks lek nie, of val terug na ’n goedgekeurde oplosser op ’n bekende pad. Albei is beleide, en nie een is wat jy by verstek kry nie. Besluit watter een die netwerk nodig het voordat jy aan die koppelvlak-lys raak.

Faal-geslote is eenvoudiger om te verdedig, maar dit verander ’n tonnel-onderbreking in ’n naamoplossing-onderbreking vir elke toestel agter die roeteerder. Terugval hou die kantoor bruikbaar, ten koste van ’n opstroom-uitruiling buite die tonnel wat doelbewus aanvaarbaar moet wees eerder as per ongeluk. Skryf die keuse neer, want die volgende persoon wat ’n oplosser-adres buite die VPN sien, sal dit as ’n lek lees tensy ’n nota anders sê. Daardie nota is wat ’n gedokumenteerde terugval van ’n onverklaarde bevinding in volgende kwartaal se hersiening skei.

Twee gevalle kompliseer die besluit. Privaat name het dalk ’n interne oplosser nodig wat die tonnel kan bereik, en ’n blaaier of toepassing met sy eie geënkripteerde DNS kan die roeteerder heeltemal omseil, so die oplosser wat jy opgestel het, is nie altyd die een wat ’n gegewe app gebruik nie.

Toets albei paaie en hou die resultate apart

’n Blaaiergebaseerde DNS-toets beantwoord ’n eng vraag: watter oplossers het daardie blaaier gebruik, onder daardie toets se omstandighede. Dit inventariseer nie die toestelle op die netwerk nie en dit kan nie ’n navraag sien wat die roeteerder vir homself geskep het nie. Behandel sy uitset as een datapunt eerder as as ’n oudit.

Vra vanaf ’n LAN-kliënt die roeteerder om ’n openbare naam en dan om ’n privaat een wat net jou interne sone behoort te beantwoord. ’n Faling op net die tweede navraag wys op naamdeurstuur eerder as op die tonnel:

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

Bring dan die tonnel af en herhaal albei navrae. Geweierde antwoorde beteken die oplosser is faal-geslote; ’n suksesvolle antwoord wys op ’n terugval-oplosser en die pad wat dit gebruik het. Vergelyk dit met die nota wat jy geskryf het en met ’n opvang op die WAN-koppelvlak wat in dieselfde minuut geneem is.

Hou die waarnemings apart in die rekord: die kliënt-tot-roeteerder-uitruiling, die roeteerder-tot-opstroom-uitruiling, en die opstelling wat die tweede een besluit het. ’n Latere roeteverandering sal daardie tweede uitruiling sonder waarskuwing oefen. ’n Antwoord wat van elders as die VPN-eindpunt kom, is nie op sigself ’n lek nie; dit word eers ’n lek wanneer die opstelling daardie pad per ongeluk gekies het.