Неге маршрутизатордың өз DNS-і VPN туннелін айналып өтеді?
Клиент сұранысы мен маршрутизатордың жоғары ағын сұранысы екі түрлі ағын. Екеуін де жазып алыңыз, шешушінің шығу жолын таңдаңыз, содан кейін туннельдің үзілу жағдайын тексеріңіз.
Клиент сұраныстары туннельге ереді, ал маршрутизатордың өз сұраныстары WAN арқылы шығады, және біреуін реттейтін брандмауэр ережесі екіншісіне ешқандай әсер етпейді. Себебі қате емес: жіберілген сұраныс пен маршрутизатордың өзі жасайтын сұраныс — екі бөлек ағын және әрқайсысы конфигурацияның басқа бөлігімен салыстырылады. Клиенттің жартысын ғана жазып алу екінші жартысы ешқашан қолданбайтын жол туралы сенімді жауап береді. Түзету — маршрутизатордың шешушісін әдейі бағыттау, содан кейін екі жолды бөлек тексеру.
Пакет жазуы шын мәнінде қай ағынға жатады
Бір сұраныс екі алмасуды қамтиды. LAN клиенті маршрутизатордың шешушісіне сұраныс жібереді және ол LAN интерфейсінде жіберілген трафик ретінде келеді, сондықтан жіберілген пакеттер үшін жазылған саясат маршруты немесе NAT ережесі оған сәйкес келуі мүмкін. Содан кейін маршрутизатор кэштен жауап береді немесе жазба болмаса, жоғары ағын серверіне өз сұранысын ашады.
Бұл екінші сұраныстың көзі — маршрутизатордың өзі, барар жері де өзі, ал платформа оның жолын басқа конфигурация блогынан таңдайды. Екі алмасу да бірдей атауды алып жүреді және ешқайсысы екіншісінің көшірмесі емес. Сондықтан LAN жағында алынған жазба клиент пакетінің қайда кеткенін дәлелдейді және шығатын пакет туралы ештеңе айтпайды.
Практикалық тексеру — екі жақты бір уақытта бақылау. Маршрутизаторда шешушінің сокетін тізімдеңіз, оған жергілікті сұраныс жасаңыз және WAN интерфейсін жазып алыңыз:
sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53Егер сокет тізімі loopback немесе LAN мекенжайына байланған тыңдаушыны көрсетсе, маршрутизатор басқа хостқа жіберудің орнына жергілікті жауап береді. Сонда жазу нәтижесіндегі жоғары ағын сұранысының туннель интерфейсімен немесе WAN арқылы шығатынын көрсетеді, және бұл саясат маршруты ережесі ешқашан бермейтін жауап.
Неге саясат маршруты екінші сұранысты ешқашан көрмейді
Брандмауэр ережелері интерфейс, көз, барар жер және порт бойынша жазылады және құрылғы арқылы өтетін пакеттер үшін бағаланады. Маршрутизатор жасайтын сұраныс ешнәрседен өтпейді, өйткені жергілікті процесс оны тікелей маршруттау кестесіне береді. Саясаттық маршруттау және NAT сондықтан тек жіберілген жолға қатысты, және дәл сондықтан ережелер жиынтығы толық көрініп, бәрібір маршрутизатордың DNS-ін туннельден тыс қалдыруы мүмкін.
Бұл айырмашылық әрбір прошивка қайта жазылғаннан кейін де сақталады, өйткені ол функциядан емес, пакет жолынан туындайды. Құрылғы өзі үшін жасайтынның барлығы — шешуші сұраныстары, уақыт синхрондауы, жаңарту тексерістері немесе пакет айналарына қатынау — жергілікті шыққан және сол бір соқыр нүктеге түседі. Сондықтан ноутбуктен жасалған тест маршрутизатор туралы ештеңе дәлелдемейді.
pfSense шешушісі өзінің жоғары ағын жолын қайда айқындайды
pfSense бұл бөлінуді көрнекі етеді. Клиент трафигін саясат бойынша VPN қақпасы арқылы өткізуге болады, ал брандмауэрдің өз трафигі LAN ережелерін емес, шешушінің шығыс параметрін ұстанады. Веб-интерфейсте бұл параметр Services > DNS Resolver > Outgoing Network Interfaces астында орналасқан, және оның мәні шешуші жоғары ағын сұраныстары үшін қолдана алатын интерфейстер тізімі.
Сол жерде туннель интерфейсін атау, және тек сол интерфейсті атау — маршрутизатордың өз сұраныстарын туннельге ертіп отыратын нәрсе. Әдепкі күйінде қалдырылса, шешуші маршруттау кестесінен шығуды таңдайды, ал екі WAN немесе VPN бар хостта бұл көбінесе WAN болады.
Басқа прошивкалар сол шешімді басқа белгімен ұсынады: көз мекенжайына байланған жоғары ағын серверлер тізімі, тек жіберу режимі немесе құжатталған маршрут саясаты. Іздеуге тиіс параметр — әрқашан жергілікті жасалған сұраныстар үшін шығу немесе көз таңдайтын параметр. Шешуші конфигурациясының анықтамалығы pfSense үшін сол опцияны құжаттайды және өзгеріске дейін оқыған жөн.
Параметрден бұрын ақаулық тәртібін таңдаңыз
Туннель құлағанда екі тәртіп ақталады: ештеңе ағып кетпес үшін жоғары ағын сұраныстарын тоқтату, немесе белгілі жолдағы бекітілген шешушіге қайту. Екеуі де саясат, және әдепкі бойынша олардың ешқайсысы берілмейді. Интерфейстер тізіміне тиюден бұрын желіге қайсысы керек екенін шешіңіз.
Ақаулық кезінде жабылуды қорғау оңайырақ, бірақ ол туннельдің үзілуін маршрутизатор артындағы әрбір құрылғы үшін атау шешуінің үзілуіне айналдырады. Қайту кеңсені пайдалануға жарамды ұстайды, бірақ туннельден тыс жоғары ағын алмасуының құнымен, ол кездейсоқ емес, әдейі қабылдануға тиіс. Таңдауды жазып қойыңыз, өйткені VPN-нен тыс шешуші мекенжайын көрген келесі адам оны ағу деп оқиды, егер жазба өзгеше айтпаса. Дәл сол жазба құжатталған қайтуды келесі тоқсанның шолуындағы түсіндірілмеген табылғаннан ажыратады.
Шешімді екі жағдай күрделендіреді. Жеке атауларға туннель жете алатын ішкі шешуші қажет болуы мүмкін, ал өз шифрланған DNS-і бар браузер немесе қосымша маршрутизаторды мүлде айналып өтуі мүмкін, сондықтан сіз конфигурациялаған шешуші әрқашан белгілі бір қосымша қолданатын шешуші бола бермейді.
Екі жолды да тексеріңіз және нәтижелерді бөлек ұстаңыз
Браузердегі DNS тесті тар сұраққа жауап береді: сол тесттің шарттарында сол браузер қандай шешушілерді қолданды. Ол желідегі құрылғыларды түгендемейді және маршрутизатор өзі үшін жасаған сұранысты көре алмайды. Оның нәтижесіне аудит емес, бір дерек ретінде қараңыз.
LAN клиентінен маршрутизатордан алдымен ашық атау, содан кейін тек ішкі аймағыңыз жауап беруі тиіс жеке атау сұраңыз. Тек екінші сұраныстағы сәтсіздік туннельге емес, атауларды жіберуге нұсқайды:
dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lanСодан кейін туннельді түсіріңіз және екі сұранысты қайталаңыз. Қабылданбаған жауаптар шешушінің ақаулықта жабылатынын білдіреді; сәтті жауап қосалқы шешушіге және оның қолданған жолына нұсқайды. Мұны жазған жазбаңызбен және сол минутта WAN интерфейсінде алынған жазбамен салыстырыңыз.
Жазбада бақылауларды бөлек ұстаңыз: клиент пен маршрутизатор арасындағы алмасу, маршрутизатор мен жоғары ағын арасындағы алмасу және екіншісін шешкен конфигурация. Кейінгі маршрут өзгерісі сол екінші алмасуды ескертусіз іске қосады. VPN соңғы нүктесінен басқа жерден келген жауап өздігінен ағу емес; ол конфигурация бұл жолды кездейсоқ таңдағанда ғана ағуға айналады.