Яагаад nc -uz нь OpenVPN сервер бэлэн байгааг баталж чадахгүй вэ

Ажиллуулах нь nc -uz OpenVPN серверийн эсрэг бараг юу ч хэмждэггүй бөгөөд OpenBSD гарын авлага үүнийг анхааруулгадаа хэлдэг: тэр горим дахь UDP скан нь ямар нэг зүйл сонсож байгаа эсэхээс үл хамааран амжилт гэж мэдээлдэг. Гарах статус нь алсын төлөвийг бус, локал илгээлтийг илэрхийлдэг тул түүнд итгэдэг хянагч процессын хүснэгт үнэмшилтэй харагдаж байх хугацаанд үхсэн серверийг эрүүл гэж тэмдэглэсэн хэвээр байлгадаг. Түүнийг солих нь шалгалт ямар асуултад хариулах ёстойг шийдэхээс эхэлдэг, учир нь процесс, сонсогч, баталгаажуулалт, аппликейшнд хүрэх боломж гэдэг нь дөрвөн өөр ажиглалт юм. Тэдгээрийн аль нэгийг нэрлэсэн шалгалт ашигтай; дөрвийг нь ч заасан шалгалт бол ачаа.

UDP шалгалт юуг ажиглаж чадах, юуг чадахгүй

nc -uz датаграм илгээж, гарч оддог бөгөөд буцаасан статус нь локал илгээлтийг тодорхойлно. Хаалттай порт ICMP port unreachable-ээр хариулж болох ч энэ скан горимын баримтжуулсан зан үйл үүнийг бүтэлгүйтэл болгодоггүй, шүүсэн порт огт хариу өгөхгүй. Тиймээс чимээгүй байдал ба амжилт нь дуудагчид ижил утгатай.

Энэ нь шалгалтыг серверийн бус, локал стекийн туршилт болгодог. Хост хүрэх боломжтой, порт холбогдсон, OpenVPN процесс ажиллаж байгаа эсвэл клиент баталгаажуулж чадах эсэхийг тогтоодоггүй. TCP холболтын туршилт илүү хүчтэй, учир нь гар барих нь тодорхой хариулт өгдөг, гэхдээ байршуулалт үнэхээр TCP дээр сонсож байгаа үед л. Шалгалтыг мөн адил дугаар дээр TCP болгох нь байхгүй байж болох сонсогчийг туршдаг бөгөөд зөвхөн UDP серверийн эсрэг энэ нь эрүүл үйлчилгээг бүтэлгүйтүүлнэ.

Шалгалтыг тохируулсан тээвэртэй тааруулах нь хоёр үр дүнгийн аль нэгэнд итгэхээс өмнө ирдэг. UDP байршуулалтад өөр дохио хэрэгтэй, өөр протокол биш.

Гурван дуудагч, гурван өөр асуулт

Бэлэн байдал нь хэн асуухаас хамаарна. Унасан процессыг дахин эхлүүлж буй үйлчилгээний менежер тухайн инстанц эхэлж, сонсогчоо холбосныг мэдэх ёстой. Ачааллын тэнцвэржүүлэгч одоо ирж буй клиентийг хүлээж авахыг мэдэх ёстой. Хяналтын систем бодит сүлжээнээс ирэх зам зөвшөөрөгдсөн нөөц рүү сессийг тээж байгааг мэдэх ёстой.

Эдгээр нь нэг шалгалт биш бөгөөд нэг шалгалт гурвыг бүгдийг нь шударгаар хамарч чадахгүй. Эхлээд дуудагчийг сонго, дараа нь нотолгоог.

Шалгалтыг одоогийн инстанцаас бүтээ

OpenVPN нь инстанц эхлүүлэлтийг дуусгахад эхлэлийн мөр бичдэг бөгөөд тэр мөр нь локал эхлэлийн талаарх ашигтай нотолгоо юм. Үүнийг одоогийн эхлэлээс унш, нэмэгдэж буй файлын төгсгөлөөс биш, учир нь өнгөрсөн долоо хоногийн амжилт нэг минутын өмнөх амжилттай яг ижил уншигддаг. Сервер нь ямар ч клиент хэзээ ч холбогдохоос өмнө эхлүүлэлтийг дуусгаж болох тул мөр нь баталгаажуулалтын талаар юу ч хэлдэггүй.

Эхлэлийн шалгалтын хувьд процессын төлөвийг одоогийн логоны нотолгоо болон тохируулсан тээвэрт тохирох сонсогчтой хослуул. Процесс ажиллаж байгаа ч эхлүүлэлтийг дуусгаагүй үед шалгалт бүтэлгүйтэх ёстой бөгөөд энэ нь логоны асуултыг энэ ачаалалт, энэ нэгжээр хязгаарлах шаардлагатай гэсэн үг.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Гурван гаралт, гурван мэдэгдэл: нэгж идэвхтэй, энэ ачаалалт эхлүүлэлтийн мөрийг үүсгэсэн, ямар нэг зүйл UDP портыг барьж байна. Аль нь ч клиент холбогдож чадна гэж хэлэхгүй. Тэдгээрийг статусын хуудсанд тусдаа байлга, инцидент нэг ногоон цэгт нуралдахгүйн тулд.

Үүнийг санаатайгаар эвдэж, шалгалтыг ажигла

Шалгалт нь бүтэлгүйтэхийг нь харсны дараа л итгэмжлэгдэнэ. Серверийг зогсоож, шалгалтыг ажиллуулж, хүлээгдэж буй үр дүнг батал. Дараа нь дахин эхлүүлж, өөр ямар ч өөрчлөлтгүйгээр шалгалт сэргэж байгааг батал.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Блокийг мөр мөрөөр унш. netcat команд нь exit=0 гэж хэвлэдэг боловч юу ч холбогдоогүй байна, энэ бол бүх асуудал нэг мөрөнд. Эхний ss юу ч хэвлэхгүй, дахин эхлүүлэлт амжилттай болж, хоёр дахь нь ss сонсогчийг дахин харуулна. Хэрэв таны шалгалт зогсоосон серверийн эсрэг давсан бол энэ нь локал стекийг хэмжиж байгаа бөгөөд өөр юу ч биш.

Эсрэг бүтэлгүйтэл ч чухал. Эрүүл серверийн эсрэг бүтэлгүйтдэг шалгалт нь хэзээ ч хэрэггүй байсан дахин эхлүүлэлтүүдийг үүсгэдэг бөгөөд дахин эхлүүлэлтийн давталт нь өөрөө нэг тасалдал юм. Шалгалтыг түүнд үйлчилж чадах зүйлд холбохоос өмнө хоёр чиглэлийг турш.

Статусын мөр юу хэлэх ёстой вэ

Шалгалт бүр ямар хил хязгаарыг хамарч байгааг бич: процесс, сонсогч, баталгаажуулалт эсвэл аппликейшн. Нэг шалгалт нэгээс олон хязгаарыг хамардаг нь ховор бөгөөд тэдгээрийг “up” болгон шахаж буй статусын хуудас нь инцидентийн үед чухал ялгааг нуудаг. Сүлжээний замын хувьд тусгай таних тэмдэг бүхий бодит клиентийг ашиглаж, гар барих болон зөвшөөрөгдсөн нэг хор хөнөөлгүй үйлдлийг дуусгаад, дараа нь салга. Энэ нь нэг алхамаар удирдлагын суваг, баталгаажуулалтын бодлого, сонсогчийг сургадаг.

Тэр таних тэмдгийг бодит хэрэглэгчдээс тусдаа байлгаж, шалгалтад хэрэгтэй хамгийн бага эрхийг өг. Өргөн хандалт бүхий бэлэн байдлын шалгалт нь тав тухын тулд нэмэгдсэн шинэ халдлагын гадаргуу юм. Түүний итгэмжлэлийг бусад бүртгэлийн адил эргүүл, учир нь баталгаажуулалтыг зогсоосон шалгалт нь клиентийг хүлээн авахаа зогсоосон сервертэй яг адилхан харагддаг.

Анхааруулгын текстэд хилийг нэрлэ, ингэснээр анхны хариулагч нэгж, сокет, гэрчилгээ эсвэл маршрут руу харах эсэхээ мэдэх болно. Юу баталснаа хэлж чадахгүй шалгалтад буруу шалтгаанаар итгэх болно, netcat шалгалт анхнаасаа яг ингэж амьд үлдсэн юм.