Нэг Pi, хоёр OpenVPN инстанц: юнит бүр юу уншдаг вэ
Нэг Pi дээрх хоёр OpenVPN демон өөр өөр тохиргооны файл уншиж, өөр өөр дэгээгээр гардаг. Инстанц бүрийг зураглаад, дараа нь ачааллын замыг тусад нь шалгана уу.
Профайлд хүрэхээс өмнө OpenVPN процессуудыг тоол. Роуминг хэрэглэгчдийг хүлээн авч, зэрэг дээд урсгалын үйлчилгээ рүү залгадаг Pi хоёр демон ажиллуулдаг бөгөөд тус бүр нь таны оруулсан инстанцын нэрээр сонгогдсон тохиргооны файлыг уншдаг. Багцын загварууд дараа нь демон бүрт өөрийн ажлын хавтас, өөрийн ажиллах үеийн төлөвийн файл, өөрийн туннелийн төхөөрөмжийг өгдөг. Энэ хуваалтыг буруу хийвэл ажиллаж буй процесс хэзээ ч нээдэггүй файл доторх зөв тохиргоог өөрчлөхөд нэг орой зарцуулна.
Инстанц бүрийн нэр өөрийн файлыг сонгоно
OpenVPN 2.6-той хамт ирдэг юнит файлуудад эхлүүлэх аргументууд нь @ тэмдгийн дараах текстээр дүүргэгддэг инстанцын орлуулагчийг агуулдаг. Серверийн загвар нь серверийн тохиргооны хавтсаас ажиллаж, аргументаа тэнд байгаа %i.conf дээр шийддэг бол клиентийн загвар нь клиентийн хавтсаас мөн адил хийдэг. Тиймээс [email protected] серверийн хавтас дахь admits.conf-ыг уншиж, [email protected] клиентийн хавтас дахь uplink.conf-ыг уншдаг бөгөөд эдгээр нэрсийн аль нь ч нөгөө хавтаст ямар ч утгагүй.
Багц дээд урсгалын анхдагч утгыг хадгалсан гэж бодохгүйгээр зураглалыг машин дээр батал. Дистрибутивы drop-in нь ажлын хавтас эсвэл тохиргооны аргументыг бүрэн сольж болно.
systemctl cat [email protected]
systemctl cat [email protected]Тухайн гаралт дахь WorkingDirectory мөрийг болон тохиргооны аргументыг унш, учир нь аль файл ачаалагдахыг зөвхөн идэвхжсэн юнит шийддэг. ExecStart-д --config нэмдэг drop-in нь загварын зам зөв харагдаж байсан ч загварыг дийлдэг. Локал дамжуулалт байгаа эсэхийг мэдэхийг хүсвэл фрагмент болон drop-in-ийн замыг асуу. Хоёр үүрэг хоёулаа нэг файл руу шийдэгдвэл танд нэг процесс сервер ба клиент хоёулаа болохыг оролдож байгаа бөгөөд тэр файл дахь дараагийн сонголт чимээгүйхэн дийлдэг.
Локал тээвэр ба дамжуулсан ачаалал өөр өөр дэгээнд тусалдаг
Серверийн роуминг хэрэглэгч бүртэй хийх шифрлэгдсэн холболт Pi дээр өөрөө үүсдэг тул түүний гадаад хариултууд локал гаралтын дэгээгээр гардаг. Клиентийн дээд урсгалын хамтрагчтай холбогдох нь ч гэсэн алслагдсан сүлжээнд хүрдэг боловч локалаар үүсгэсэн гаралт юм. Дамжуулсан ачаалал гурав дахь ангилал бөгөөд цөм нь пакетийн гарах төхөөрөмжийг аль хэдийн сонгосны дараа л түүнийг тааруулдаг.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
forward гинжийн дотор гарах интерфэйстэй таардаг дүрэм нь чиглүүлэлт аль хэдийн тэр интерфэйст хуваарилсан пакетыг зөвшөөрөх эсвэл хаях боломжтой боловч интерфэйсийг хэзээ ч сонгодоггүй. Нэг хост нэг туннелийг дуусгаад нөгөөг эхлүүлэх үед хэрэглэгчийн ачааллыг дээд урсгалын туннель руу илгээдэг бодлого болон Pi-ийн өөрийн шифрлэгдсэн хариултыг хамгаалдаг бодлого нь хоёр тусдаа шийдвэр юм. Тэд санамсаргүйгээр нэг физик NIC дээр буудаг тул андуурдаг.
Энэ ялгаа нь түгээмэл хагас алдааг тайлбарладаг. Хэрэглэгчид холбогдож, гар барилт дуусдаг ч тэдний урсгал буруу замаар гарсаар байдаг, учир нь гар барилт локал, ачаалал нь forward байсан бөгөөд хоёрын зөвхөн нэгийг нь шалгасан.
Импортолсон маршрут хэрэглэгчдэд чинь очих хариултыг залгиж болно
Клиентийн профайлын аюулгүй байдлын тохиргоо нь дээд урсгал Pi-ийн чиглүүлэлтийн хүснэгт рүү юу push хийж болохыг шийддэг бөгөөд өргөн redirect нь ажиллаж байсан хос үүрэгт хост-ыг эвдэрхий болгодог сонголт юм. Хэрэв push хийсэн маршрут роуминг хэрэглэгчдийн нийтийн хаягуудыг хамарч байвал серверийн тэдэн рүү үүсгэдэг хариултууд underlay-ээр гарахын оронд шинэ маршрутыг дагаж дээд урсгалын туннель руу орж болно. Хүмүүс нийлүүлэгч рүү чиглэсэн туннель хэвээр ажиллаж байгааг баталгаажуулаад тэнд зогсдог, учир нь тэр урсгал нь туннелийн өөрийн тээвэр бөгөөд бусад бүхэн буруу ажиллаж байхад ч үргэлжлэн урсдаг.
Эх сурвалж эсвэл mark-д суурилсан бодлого нь хоёр урсгалыг тусгаар байлгах арга юм. OpenVPN-ийн Linux mark сонголт нь демоны өөрийн шифрлэгдсэн пакетуудад галт ханын mark тавьдаг бөгөөд чиглүүлэлтийн дүрэм түүнийг тусгай хүснэгт рүү илгээж болно. Серверийн гадаад хариултууд үргэлж нэг underlay хаягаас гардаг бол эх сурвалжийн хаягууд ч мөн адил сайн ажилладаг. Аль ч аргад сонгосон хүснэгтэд хүчинтэй маршрут болон нийлүүлэгчийн endpoint-д үл хамаарах зүйл шаардлагатай, эс бөгөөс туннель өөрөө босохгүй.
Ямар ч дүрэм бичихээс өмнө хариулт үнэндээ ямар замаар явахыг цөмөөс асуу. Доорх хаягууд нь Pi-ийн underlay хаяг болон нэг роуминг хэрэглэгчийн нийтийн хаягийн орлуулагч юм.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Хуваалтыг батал, дараа нь үүрэг бүрийг нэг нэгээр нь зогсоо
Гурван урсгалыг тусад нь шалга, учир нь амжилттай гар барилт нөгөө хоёрын талаар юу ч баталдаггүй. Шинэ ирж буй холболтыг хүлээн авч, зөвшөөрөгдсөн нэг аппликейшныг дээд урсгалын гаралтаар илгээж, хоёр процесс хоёулаа өөрсдийн хамтрагчдаа хүрсээр байгааг батал.
Дараа нь клиентийн үүргийг зогсоож, серверийн үүрэг юу хадгалж байгааг ажигла. Нэг инстанцад зориулагдсан боловч хоёуланд нь хэрэглэгдсэн маршрут эсвэл mark дүрмийг олох хамгийн хямд арга энэ.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerТаны хармаар байгаа зүйл бол клиентийн үүрэг унтарсан үед сонсогч хэвээр холбогдсон, туннелийн төхөөрөмж хэвээр байгаа, лог шинэ алдаагүй байх явдал юм. Клиентийг зогсоох нь серверийн одоо байгаа хэрэглэгчдэд өгөх хариултыг ч тасалбол хоёр үүрэг нэгэнд нь л хязгаарлагдах ёстой байсан зүйлийг хуваалцаж байна. Өөрчлөлт бүр аль инстанц, аль тохиргооны файл, аль урсгалын эзэнд хүрснийг тэмдэглэ, эс бөгөөс энэ хост-ыг дараа нь дибаг хийх хүн мөнөөх нээлтийг тэгээс давтана.