Pi хотспот, Pi-hole болон VPN: үйлчилгээ бүрт ажил онооно уу
Нэг Pi дээр гурван туслахыг асаахаас өмнө DHCP, DNS болон пакет дамжуулалтыг хэн эзэмшихээ шийдээрэй. Давхардсан эзэд өрсөлдөх lease болон resolver давталт үүсгэдэг.
Утас Pi-ийн хотспотод холбогдож, хаяг авдаг ч хуудас ажиллахгүй хэвээр байна. Pi нь хотспотын туслах, Pi-hole болон VPN клиентийг ажиллуулж, тус бүр нь замын нэг хэсгийг эзэмшдэг гэж боддог. Эдгээр угсралтын ихэнх нь компонент эвдэрснээс биш, хоёр компонент нэг ажлыг хийдгээс бүтэлгүйтдэг. Аль нэгийг нь тохируулахаас өмнө функц бүрт нэг эзэмшигч томил.
Функц бүрт нэг эзэмшигч томил
Энд дөрвөн функц чухал бөгөөд тус бүрд яг нэг эзэмшигч хэрэгтэй. Доорх хүснэгтэд функц, ажиллах боломжтой эзэмшигч, хоёр үйлчилгээ үүнийг шаардвал юу буруу болохыг харуулав.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
Давхцал ихэвчлэн нэг пакетаар ирдэг. Хотспотын туслах өөрийн dnsmasq хуулбарыг суулгаж, Pi-hole 53 портыг хүсэж, VPN клиент маршрут нэмдэг. Алхам бүр дангаараа боломжит мэт харагдах боловч хамтдаа хоёр дахь үйлчилгээ эхнийхийн зан төлөвийг чимээгүй өөрчилдөг машин үүсгэдэг.
Өөр юу ч асаахаас өмнө эзэмшигчдийг бич. Угсралтын тэмдэглэл дэх богино хүснэгт дараагийн суулгалт аль хэдийн эзэнтэй функцийг авахаас сэргийлнэ.
Нэг мужийг сонгоод туннелээс хол байлга
Хотспотын муж, түүн дэх Pi-ийн хаяг, DHCP пул болон клиентүүдийн авдаг resolver-ийг сонго. Тэр мужийг дээд LAN болон VPN туннелийн мужаас тусдаа байлга, учир нь давхцах дэд сүлжээнүүд маршрутын асуудлыг хаяг хөрвүүлэх төсөл болгоно. Туннелтэй давхцсан муж Pi-ийг ижил хоёр префиксийн хооронд санамсаргүй маршрутизатор болгоно. Мужийг болон пулыг анхдагч утгад үлдээхгүй, хотспотын тохиргоонд бич.
Хэрэв хотспотыг NetworkManager-ийн хуваалцсан горим эзэмшдэг бол DHCP сервер нэмэхээс өмнө бодит холболтыг шалга. Хуваалцсан горим өөрийн туслахуудыг ажиллуулж, дамжуулалтыг асаадаг тул тэр интерфэйсийн хаягийн төлөвийг аль хэдийн эзэмшдэг. Боломжтой учраас хоёр дахь сервер нэмэх нь нөөц биш, өрсөлдөх санал үүсгэдэг.
IPv6-ийн талаар зориуд шийд. Олон тохиргоонд маршрутизаторын зарлал болон DHCPv6 нь DHCPv4-өөс өөр туслахаас ирдэг бөгөөд VPN бодлого зөвхөн IPv4-ийг хамарч байхад IPv6-г асаалттай үлдээвэл клиентүүд туннелийг тойрсон зам авна. IPv6 талыг төлөвлө, эсвэл хотспотын интерфэйс дээр бичгээр үндэслэлтэйгээр унтраа.
53 порт дээр үнэхээр хэн хариулдаг вэ
Тохиргоог өөрчлөхөөс өмнө 53 портыг сонсож буй процесс бүрийг жагсаа. Орон нутгийн resolver stub, Pi-hole болон хуваалцах туслах ажилладаг Pi дээр сонсогчдын жагсаалт нь асуултад хэн хариулдгийг харуулах цорын ганц найдвартай зураг:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole-ийн интерфэйсийн гарын авлага нэг интерфэйсээр хязгаарлагдсан хүлээн авах горим wildcard socket ашиглаж, өөр газар ирсэн зүйлийг хаяж болохыг тайлбарладаг. Энэ нь зөвхөн сонгосон интерфэйсүүдийг холбохтой ижил биш бөгөөд өөр DNS үйлчилгээ машиныг хуваалцах ёстой үед зориулагдсан зохицуулалт юм.
Хоёр процесс ихэвчлэн ижил хаяг, портыг холбож чадахгүй, гэхдээ SO_REUSEPORT хуваалцсан холболтыг амжилттай болгож чадна; тэр ч байтугай wildcard сонсогч нарийн үйлчилгээнд зориулсан ирэлтийг авч чадна. Хүссэн үүргийнхээ баримтжуулсан горимыг сонгоод үйлчилгээнүүдийг зорьсон дарааллаар дахин эхлүүл.
Pi-hole-ийн удирдлагын хуудсыг хотспотын сүлжээнээс гадуур байлга. Клиентүүдэд resolver хэрэгтэй, resolver-ийн тохиргоог өөрчилж чадах вэб интерфэйс эсвэл API биш.
Хоёр DNS хөл, тус бүрд нэг бодлого
Клиентийн асуулт утаснаас Pi руу явдаг бол тусдаа асуулт Pi-ээс түүний дээд resolver руу явдаг. Хотспотын дамжуулсан трафикт тохирох маршрутын дүрэм хоёр дахь хөлд автоматаар үйлчлэхгүй, учир нь Pi тэр трафикийг локалаар үүсгэдэг. Хэрэв VPN DNS зөөх ёстой бол локал замд өөрийн бодлого хэрэгтэй.
Давталтаас сэрэмжлээрэй. Pi-hole-ийн дээд resolver-ийг Pi өөрөө үйлчилдэг хаяг руу чиглүүлэх нь шууд эсвэл порт дамжуулалтаар дамжуулан хугацаа дуусах хүртэл эргэлддэг асуулт үүсгэдэг. Түүнд жинхэнэ дээд resolver эсвэл хариулж чадахгүй домэйнуудад нөхцөлт forwarder өг.
Туннел унахад юу болохыг шийд. Локал resolver руу буцах нь хөтлөлтийг амьд байлгах боловч нэрсийг VPN-ээс гадагш алдаж болно; блоклох нь бодлогыг бүрэн хадгалж, гэмтлийг харагдах алдаа болгоно. Аль ч сонголт хамгаалагдах боловч анхдагч утгаас өвлөхгүйгээр сонгох ёстой.
Замыг болон гэмтлийн үеийн зан төлөвийг батал
Давхаргаар турш: клиент хаяг авна, клиент нэрийг Pi-ээр шийднэ, Pi зорьсон дээд resolver-ээр шийднэ, апп хүсэлтийг дуусгана. Амжилттай ping нь DNS-ийн талаар юу ч хэлэхгүй, амжилттай хайлт нь дамжуулалтын талаар юу ч хэлэхгүй.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1Дараа нь туннелийг зогсоож, давт. Зорьсон зан төлөв хэдхэн секундын дотор гарч ирэх ёстой, Pi-hole эсвэл хотспотын үйлчилгээг гараар дахин эхлүүлсний дараа биш. Гэмтлийн үед клиентийн resolver тохиргоог шалга, учир нь хоёрдогч нийтийн resolver бодлого алдаа хүлээж байсан ч хариулсаар байна.
Дамжуулалт болон NAT-д нэг эзэмшигч байлгаж, үүнийг Pi-ээс биш клиентээс шалга. Pi-ээс амжилттай гарсан хүсэлт буцах замд хаягдаж болно, клиент бол бүх замыг харж болох цорын ганц газар.