OpenConnect тасарсан VPN руу хэр удаан дахин холбогдохыг оролдох ёстой вэ?

--reconnect-timeout нэг нарийн асуултад хариулна: туннель унасны дараа энэ клиент процесс бууж өгч гарахаас өмнө хэр удаан оролдсоор байх вэ. OpenConnect-ийн гарын авлагын хуудас энэ сонголтыг алдагдсан холбоо эсвэл хариу өгөхөө болиулсан түншийн дараах дахин оролдлогуудад зориулсан баримтжуулсан 300 секундын өгөгдмөл утгатай бүртгэдэг бөгөөд энэ тоо нь ажиллаж буй нэг клиентэд зориулсан хугацаа бөгөөд VPN хүртээмжтэй хэвээр байх баталгаа биш юм. Энэ нь мөн процессыг амьд байлгах бодлого биш бөгөөд будлианы ихэнх нь эндээс эхэлдэг.

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

Дахин холбогдох цонх үнэндээ юуг хязгаарладаг вэ

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

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

Цонх ажиллаж байх хооронд програмууд юу хийдгийг ч зохицуулдаггүй. Платформ болон алдаа хэр хол явсанаас хамааран клиент маршрутууд суурилагдсан хэвээр байхад эсвэл тэдгээрийг авсны дараа дахин холбогдож болно. Тиймээс тасалдлын дунд илгээсэн хүсэлт хурдан бүтэлгүйтэхийн оронд таймаут дуустал өлгөөтэй байдаг.

Хянагчийн дахин эхлүүлэлт ба клиентийн дахин оролдлогууд хоёр давхарга

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Тэр мөрөнд хоёр нарийн зүйл жинтэй. --background процессыг салгадаг тул pid файл түүн дээрх цорын ганц найдвартай бариул болдог, таймаут нь зөвхөн тэр процесс амьд байх хугацаанд зарцуулагддаг; түүнийг алдаг хянагч үргэлжлүүлэх төсөв үлдээдэггүй.

Зориудын салгалтуудад өөрийн дохио хэрэгтэй. Төлөвлөсөн завсарлага ба бодит тасалдал гэнэн ажиглагчид адилхан харагддаг, хоёулаа «холбогдоогүй» гэж уншигддаг. Завсарлагыг хянагчийн зогсоох үйлдлээр эсвэл бүрхүүлийн ойлгодог тэмдгээр удирдаж, зориудын зогсолт хэн ч хүсээгүй дахин эхлүүлэлт үүсгэхгүй байг.

Шилжүүлгийг дахин оролдлогын давталттай өрсөлдөхөөс сэргийлэх

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

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

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

Тасалдлын үеэр болон дараа нь юуг шалгах вэ

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

Шалгалтуудыг гадагш чиглүүлж бай, учир нь процессын хүснэгт дангаараа маш бага зүйлийг нотолдог. Богино тасалдлын турш pid тогтвортой байгаа эсэхийг хар, дараа нь уртын дараа тэр явж, нэг удаа солигдсоныг батал:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

Зориудын зогсолтын хувьд эрүүл мэндийн URL хүртээмжгүй хэвээр, процесс доош хэвээр байх ёстой. Дараа нь программын талаас давталтыг хаа: мөн тэр хүсэлт туннель байхгүй үед бүтэлгүйтэж, буцаж ирсний дараа таны бодлого хүлээж буй эх үүсвэрийн хаягаас амжилттай байх ёстой. Ногоон туннелийн дүрс нотолгоо биш, харин гүйцэтгэсэн хүсэлт нотолгоо юм.