TCP дахин тохируулга нь VPN блоклогдож байгааг нотлохгүй

Клиентийн логт «холболт дахин тохируулагдлаа, дахин эхлүүлж байна» гэж гарч ирэх ба дүгнэлт нь нотолгооноос өмнө ирдэг. Хэн нэгэн сүлжээ VPN-ийг блоклож байна, эсвэл гэрчилгээ буруу, эсвэл тодорхой улс оролцож байна гэж шийддэг. Дахин тохируулга нь холболтыг дуусгадаг TCP пакет бөгөөд лог мөр нь таны клиент нэгийг хүлээн авсныг бүртгэдэг. Энэ нь илгээсэн төхөөрөмжийг ч, шалтгааныг ч нэрлэхгүй.

Дахин тохируулга бол пакет, шийтгэл биш

TCP нь дахин тохируулгын боловсруулалтыг тодорхойлдог: RST тугтай сегмент холболтыг даруй дуусгана. Хүлээн авагч хэлэлцээ хийхгүй, дахин оролдохгүй, яагаад гэж асуухгүй. Дахин тохируулгын талаар мэдэгдээд үргэлжлүүлнэ.

Клиентийн мэдэх зүйл тэгээд л. RST нь сервер, прокси, галт хана эсвэл төлөвөө алдсан ачааллын тэнцвэржүүлэгчээс ирсэн байж болно.

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

Аль холболт дахин тохируулагдсаныг баталгаажуул

Эхлээд идэвхтэй профайл үнэхээр TCP ашиглаж байгаа эсэхийг шалга. UDP туннел дээр дахин тохируулга утгагүй бөгөөд HTTP проксийн лог нь VPN-ээс өөр TCP хэсэгт хамаарч болно.

Очих газрыг, портыг, оролдлогын цагийг болон клиентийн хүрсэн үе шатыг тэмдэглэ.

Үе шат нь хамгийн ашигтай талбар. TLS гар барилтын үеийн дахин тохируулга нэг сэжигтнүүдийн бүлгийг заана; баталгаажуулалтын дараах дахин тохируулга өөр бүлгийг. Үе шатгүй бол ямар ч онол тохирно.

Замын хоёр үзүүрийг харьцуул

Хэрэв та серверийг удирддаг бол ижил оролдлогын хувьд түүний үйл явдлуудыг харьцуул. Холболтыг хүлээн авсан уу? Санаатайгаар хаасан уу? Хариулт нэг хилээс гарч дараагийн хилд хүрээгүй юу?

Боломжтой бол клиент болон сервер дээр бичлэг хий. Клиент дээр харагдаж сервер дээр харагдахгүй дахин тохируулга сервер дээр үүсээгүй.

Хоёр чиглэлд RST сегментүүдийг ажиглаарай:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Хяналттай харьцуулалтаар нарийсга

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

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

«Энэ зам бүтэлгүйтдэг» ба «энэ нэрлэсэн оролцогч үүнийг үүсгэсэн» хоёрын ялгааг хадгал. Эхнийх нь шалгах боломжтой; хоёр дахь нь ихэвчлэн нэг клиентээс шалгах боломжгүй.

Итгэлийн тохиргоог өөрчлөхгүйгээр засварыг шалга

TLS баталгаажуулалтыг бүү унтраа, итгэмжлэлийг бүү дахин үүсгэ, нэг дахин тохируулгын мөрөнд үндэслэн блоклох бодлого зарлаж болохгүй. Эдгээр өөрчлөлт бүр туршиж буй системийг өөрчилж, дараагийн харьцуулалтыг утгагүй болгоно.

Тодорхойлсон бүрэлдэхүүнийг эзэмшигчээр нь засварлаад, дараа нь ижил профайл болон ижил ажиглалтыг давт:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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