vpnc Check Point эсвэл Nortel-ийн эсрэг: яагаад гацдаг вэ

Шинж тэмдгийг буруу уншихад амархан: vpnc ажиллаж эхлээд бүлгийн нууц үг асууж, дараа нь зорилтоос хариу ирэхгүй гэж мэдэгдэх хүртэл хэлэлцээрийн алхамд зогсдог. Гаралтад гарцын бүтээгдэхүүнийг хаана ч дурдаагүй бөгөөд бүртгэл хөтөчөөс ажилладаг тул илт дүгнэлт нь буруу нууц үг эсвэл хаагдсан порт юм. Эдгээр тохиолдлын ихэнхэд гарц нь огт IPsec түнш биш тул солилцоо нэвтрэх мэдээллийг шалгах хүртэл хэзээ ч хүрдэггүй. Профайлд өөр зүйлийг өөрчлөхөөс өмнө энэ загварыг шалгах нь зүйтэй.

Профайлын өөр талбарыг засахын өмнө бүтээгдэхүүнийг тодорхойлно уу.

Алдаа нь буруу нэвтрэх мэдээлэл мэт харагдана

vpnc нь UDP 500 рүү IKE илгээж эхэлдэг ба NAT-аар дамжих санал болговол UDP 4500 рүү ч илгээдэг. IPsec-ийн оронд SSL-ийг дуусгадаг гарц нь аль алинд нь хариу өгдөггүй тул клиент дахин оролдож, эцэст нь ерөнхий алдаатайгаар бууж өгдөг. Хэрэв ижил бүртгэл жижиг туслах програмыг ачаалдаг хөтчийн порталаар ажилладаг бол энэ нь туннель SSL-д суурилсан бөгөөд клиент буруу асуулт асууж байгаагийн хүчтэй дохио юм.

Энд гарсан бүтэлгүй оролдлого нь хэрэглэгчийн бүртгэлийн талаар юу ч хэлэхгүй, учир нь гарцад нэвтрэх мэдээлэл хэзээ ч танилцуулагдаагүй.

Гарц ямар протокол санал болгодогийг шалгана уу

Хоёр минутын шалгалт нь IPsec түншийг SSL порталаас ялгадаг. Тэдгээрийг клиент ашиглах ижил сүлжээнээс ажиллуулж, баримт бичигт аль порт байгааг биш, аль порт хариу өгч байгааг уншина уу. Үр дүнг хадгаарай, учир нь яг тэдгээр порт нь гарцын эзэн ямар клиентийг дэмжих ёстойг тодорхойлдог. Гарцын дэргэдэх хостноос биш, клиентийн сүлжээнээс шалгана уу.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Нэвтрэх хуудас руу чиглүүлэх замаар нээлттэй 443 болон 500, 4500 дээр нам гүм байх нь SSL VPN руу заана. 443 дээр сертификат өгсөн нээлттэй 500, 4500 нь вэб интерфэйс бас ажиллуулдаг IPsec гарц байгааг сануулж байгаа бөгөөд vpnc яг энэ тохиолдолд зориулж бүтээгдсэн.

Check Point-ийн SSL Network Extender болон Nortel-ийн Aventail клиент хоёулаа хоёрдугаар ангилалд багтах бөгөөд аль нь ч IKEv1 бүлгийн нууцыг хүлээж авдаггүй.

vpnc профайл юуг илэрхийлж чадах, юуг чадахгүй

Дотооддоо vpnc бүлгийн урьдчилан хуваалцсан түлхүүрийн эсрэг IKEv1 ажиллуулж, дараа нь XAuth-аар дамжуулан хувь хэрэглэгчийн нэвтрэх мэдээллийг илгээдэг. Түүний тохиргооны файлд байгаа бүхэн тэр солилцоонд хамаарна: гарц, бүлгийн нэр, бүлгийн нууц, хэрэглэгчийн нэр, хэрэглэгчийн нууц үг. Эдгээр талбар нь нэг протоколыг дүрсэлдэг бөгөөд тэдгээрийн ямар ч хослол клиентийг өөр протокол ярихыг албадаж чадахгүй.

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

Гарцад тохирох клиентийг сонгох

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

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

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