Buhay ang tunnel, naaabot ng mga kliyente ang VPN host, ngunit wala itong maresolba. Malinis na lumalabas sa interface ang sarili nitong outgoing query, kaya nasa pabalik na landas ang sira: sa isang gilid sa itaas na nagsasala ng papasok na trapiko nang hindi naaalala ang ipinadala ng host. Ang pagpayag sa port ng tunnel ay hindi naglalarawan sa palitang iyon. Ang tugon sa DNS query ay hiwalay na daloy, at kung ang gilid ay stateless, wala pang nagbigay ng pahintulot na bumalik ito.

Ang dalawang palitan ay hindi isang palitan

Isulat ang mga tuple at magiging malinaw ang mali. Ang destination port ng kahilingan ay nagiging source port ng tugon, na kabaligtaran ng iniisip ng karamihan kapag nagdaragdag ng papasok na patakaran para sa port 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Ang papasok na patakaran na nangangailangan ng destination port 53 ay naglalarawan ng trapikong nakadirekta sa isang DNS listener na tumatakbo sa host, at ibang serbisyo iyon. Ang mga address na iyon ay halimbawa sa dokumentasyon, at ang source port ay pinipili ng kliyente para sa bawat query, kaya hindi ito halagang makokopya sa isang patakaran at aasahang patuloy na gagana.

Stateless na gilid kumpara sa stateful na firewall ng host

Sinusuri ng stateless na filter sa gilid ang bawat papasok na packet laban sa listahan ng patakaran nito nang walang talahanayan ng koneksyon sa likod nito. Ang outgoing query na matagumpay na lumabas ay hindi lumilikha ng pahintulot para sa papasok na tugon nito, dahil walang tala ang aparato na may naganap na query. Ang stateful na firewall ng host ay kabaligtaran: nakikilala ng pagsubaybay ng koneksyon nito ang pabalik na trapiko ng pinapayagang palitan at hinahayaang dumaan nang walang patakaran para sa tugon. Umiiral ang dalawang hangganan sa karaniwang landas, at pareho silang dapat payagan ang nilalayong packet.

Mahalaga ang paghahambing dahil magkaiba ang pagkapalya ng dalawang aparato. Ang stateful na firewall na tumatanggi sa tugon ay nagtatala ng pagbagsak; ang stateless na gilid ay tahimik na tumatanggi, kaya nag-time out na lamang ang host.

Itayo ang pahintulot sa paligid ng protocol, hindi ng numero ng port

Limitahan ang patakaran sa tunay na mga address ng resolver, sa destination host, at sa patakaran ng receiving port na sinusuportahan ng produkto. Tandaan din ang TCP na landas ng DNS, dahil ang malaking tugon o ang pag-atras dahil sa pagputol ay naglilipat ng palitan sa TCP at hindi ito sasaklawin ng patakarang UDP lamang. Kung sinusuportahan ng gilid ang stateful na inspeksyon para sa tinukoy na daloy, mas piliin iyon kaysa sa manu-manong isinulat na patakaran ng tugon, dahil awtomatikong sinusundan ng stateful na landas ang mga port na pinili ng kliyente.

Pagkatapos ay tiyakin kung aling produkto sa landas ang tunay na nagsasala ng trapiko. Ang dokumentadong saklaw ng gilid para sa IPv4 ay hindi nagtatatag ng patakaran para sa IPv6, at ang panloob na trapiko ng provider ay maaaring hindi kailanman dumaan sa parehong filter.

Bakit hindi solusyon ang payagan ang anumang source port 53

Ang patakarang tumatanggap sa lahat ng nag-aangking may source port 53 ay patakarang tumatanggap sa isinulat ng nagpadala sa field ng header. Hindi pinatutunayan ng numero ng port ang nagpadala at hindi pinapatunayan na ang payload ay wastong tugon, kaya pinalalawak ng patakaran ang pagkakalantad ng host nang hindi ginagawang mas maaasahan ang resolusyon. Panatilihin ang mga paghihigpit sa source at panatilihin ang sariling pagsusuri ng tugon ng kliyente, kasama ang randomization ng source port, sa halip na patayin ang mga ito para pasimplehin ang access list.

Kung ang resolver ay serbisyong kontrolado mo, sapat na ang paglimita sa mga address nito. Kung pampublikong resolver ito, limitahan sa mga address na inaprubahan mo at itala ang mga ito sa komento ng patakaran.

Beripikahin sa tamang hangganan, sa tamang direksyon

Kunin sa host at sa gilid ang parehong query, at ihambing ang mga tuple sa halip na ang bilang ng packet. Ang query na nakikita sa magkabilang panig nang walang tugon sa panig ng host ay tumuturo sa papasok na filter; ang query na nakikita lamang sa panig ng host ay tumuturo sa routing o sa resolver mismo. Ulitin gamit ang TCP query kung UDP lamang ang pahintulot mo, dahil iyon ang puwang na hindi nakikita ng unang pagsubok.

Ang pagwawasto nito ay kinukumpleto ang isang palitan ng DNS na tunay na kailangan ng host. Hindi nito ginagawang pampublikong resolver ang host, hindi nito pinapayagan ang mga ipinasa ng VPN na daloy, at hindi nito pinapatunayan na DNS ang dahilan ng anumang walang kaugnayang problema sa tunnel.

Kaugnay na mga artikulo