DNS дахин чиглүүлсний дараа dnsmasq-ийн асуулга VPN-ээс яагаад гардаг вэ
Роутерын талын REDIRECT нь LAN-ийн DNS асуулгыг шийдэгчийн шинэ сокет болгоно. Клиентийн урсгал дээрх тэмдэглэгээ түүнд хэзээ ч хүрэхгүй тул дээд урсгалын гарах замыг шууд тохируулна уу.
LAN клиент өөрийн VPN-д зөв хүрдэг ч DNS асуулгууд нь буруу дээд холбоос дээр гарч ирсээр байна. Энэ нь ердийн утгаар алдагдал биш; роутер асуулгыг дамжуулахаа болиод өөрөө хариу өгөх үед ийм зүйл болдог. Тасалдал нь очих хаягийг локал сокет руу дахин бичээд, дараа нь шийдэгч өөрийн эх хаяг, өөрийн чиглүүлэх шийдвэртэй хоёр дахь, холбоогүй яриа нээнэ. Клиентийн урсгалд тавьсан тэмдэглэгээ нь эхний яриаг тодорхойлдог бөгөөд хоёр дахь тухай юу ч хэлдэггүй.
Тэмдэглэгээ асуулгатай хамт аялдаггүй
Пакетын тэмдэглэгээ conntrack бүртгэл дээр болон нисэж буй пакет дээр амьдардаг. REDIRECT дүрэм тэр нислэгийг дуусгана: ачаа локал сокет руу шилжиж, анхны бүртгэл ажлаа хийсэн байна. Үүний дараа роутероос гарч буй зүйл бол шийдэгчийн процессын үүсгэсэн шинэ сокет бөгөөд эх нь роутерын өөрийн хаяг юм.
Тиймээс LAN клиентийн хаяг дээр түлхүүрлэсэн бодлогын маршрут дээд урсгалын асуулгатай хэзээ ч таарахгүй. Шинэ сокет клиентийн биш, dnsmasq-ийнх бөгөөд цөм маршрутыг роутерын өөрийн урсгалд үнэлдэг. Эх дүрэм, интерфэйсийн дүрэм, тэмдэглэгээний дүрэм бүгд өөр tuple хардаг. Тэмдэглэгээ тархдаг гэж үзэх нь энэ тохиргооны хамгийн түгээмэл алдаа бөгөөд клиентийн талын бичлэгт харагдахгүй.
Хоёр яриа үнэхээр нэг нэр, нэг цагийг хуваалцдаг бөгөөд бичлэгийг хурдан харж байхад тэднийг нэг урсгал мэт харагдуулдаг нь энэ.
Дамжуулалт хаана локал шийдэл болж хувирдаг
53-р порт дахин чиглэгдэж байгаа эсэх, өөр хост руу хөрвүүлэгдэж байгаа эсэх, эсвэл хэвээр үлдэж байгааг тогтоож эхэл, учир нь гурван тохиолдол өөр өөрөөр ажилладаг. Локал порт руу дахин чиглүүлэх нь дамжуулалтыг дуусгадаг бол өөр машин руу хөрвүүлэх нь пакетыг хөдөлгөөнд байлгаж, клиентийн tuple-г утга учиртай байлгадаг.
Хоёр протоколыг хоёуланг нь хар. UDP болон TCP-ээр хүрэх боломжтой шийдэгч хоёулан дээр нь шалгагдана, зөвхөн UDP-г хамарсан дүрмийн багц том хариултуудад чимээгүй нүх үлдээдэг. Роутерын өөрийн тохиргооны менежерийн үүсгэсэн дүрмүүд ч тооцогдоно, үүсгэсэн файлыг засах нь ихэвчлэн дараагийн дахин ачааллалтад ялагддаг.
sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'
Эдгээр гаралт гурван асуултад дараалан хариулна: асуулгыг юу дахин бичдэг, юу хүлээж авдаг, сонсож буй сокетыг аль процесс эзэмшдэг. Эзэмшигч нь тодорхой болсны дараа дээд урсгалын бодлого амьдрах газартай болно.
Шийдэгчид өөрийн гарах бодлогыг өг
Домэйнд тусгайлсан дээд урсгал нь зөвхөн зарим нэрэнд туннель хэрэгтэй үед хамгийн цэвэр хэрэгсэл юм. dnsmasq домэйнээр хязгаарласан server мөрийг хүлээн авч, сонголтоор интерфэйс эсвэл эх хаягаар асуулгыг сонгосон төхөөрөмжөөс гаргана. Яг тэр чиглүүлэлт нь хоёр дахь яриаг VPN-ийг дагахад хүргэдэг.
server=/corp.example/10.30.0.53@tun_work
log-queries
Дээрх домэйн, хаяг, интерфэйс нь таны өөрийн утгуудад зориулсан орлуулагч юм. Домэйн сонголт ба гарах хяналт нь тусдаа шийдвэр хэвээр үлдэнэ: маршрут байх ёстой, эх хаягийг дээд урсгалын шийдэгч зөвшөөрөх ёстой, галт хана хариултыг зөвшөөрөх ёстой. Зөвхөн интерфэйсээр чиглүүлэх нь fail-closed биш, учир нь алга болсон туннель шийдэгчийг өөр зам руу унагаж болно. Аливаа нийтийн нөөц замыг нууц хэвээр байх ёстой нэрийн орон зайгаас хол байлга.
Мөрийг үүсгэсэн файлд биш, роутерын дэмждэг тохиргооны эзэмшигчид тавь, эс бөгөөс дараагийн дахин ачааллалт засварыг устгана.
Хуваалцсан кэш юуг хадгалж чадахгүй вэ
Нэг кэштэй нэг дамжуулагч LAN-ийн клиент бүрт үйлчилдэг бөгөөд энэ нь зарим сүлжээнд хэрэгтэй ялгааг нураадаг. Хоёр клиент нэг нэрийг өөр өөрөөр шийдэх ёстой бол хуваалцсан сокет ямар клиент асуусныг сэргээх аргагүй. Клиент тус бүрийн бодлого нь тусдаа шийдэгчийн хувилбарт эсвэл таних тэмдгийг хадгалдаг дамжуулалтын боломжид амьдрах ёстой.
Кэшлэсэн хариулт ч шинэ замын талаарх баталгаа биш. Хариулт санах ойгоос ирж болох бөгөөд дээд урсгалын маршрут эвдэрхий хэвээр байна.
53-р портын дүрмүүд DNS-ийг HTTPS эсвэл TLS дээр ярьдаг програмуудын талаар юу ч хэлдэггүй. Тэдгээр асуулга дахин чиглүүлэлтэд хэзээ ч хүрдэггүй тул зөвхөн 53-р порт дээр бүтээсэн бодлого урсгалын дэд олонлогийг тодорхойлдог бөгөөд үүнийг дэд олонлог гэж баримтжуулах ёстой.
Хоёр дахь яриаг шалга, эхнийхийг биш
Өөрийн хянадаг нэг нэрээр туршиж, хоёр талыг ажигла. Клиентийн талын бичлэг нь асуулга LAN-аас гарсныг батална; дараа нь хаашаа явсныг зөвхөн роутерын тал батална.
sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53
Оролдлого бүрийн өмнө кэшийг цэвэрлэ, учир нь дулаан хариулт эвдэрхий дээд урсгалыг нуудаг. TCP-ээр давтаж, дараа нь туннелийг унтраасан байдалтай давтаж, шийдэгч өөрийн илүүд үздэг зам алга болоход юу хийдгийг хар. Яг тэр сүүлийн зан төлөв нь загвар fail-closed мөн эсэх, эсвэл зүгээр л азтай байсныг шийднэ.