Squid üzərindən bir VPN son nöqtəsi: dar CONNECT istisnası

Squid CONNECT sorğusuna uyğun gələn ilk http_access sətri ilə cavab verir və həmin sətir imtina ola bilər. Bu tək fakt VPN son nöqtəsi istisnasının adətən ilk cəhddə niyə uğursuz olduğunu izah edir, çünki sorğu kimsənin aşağıda əlavə etdiyi icazəyə heç vaxt çatmır. Dar düzəliş mövcud port qoruyucularını saxlayır və onlara bir yoxlanılmış mənbə, təyinat və port barədə məlumat verir. Proksidə qalan hər şey əvvəlki kimi davranmağa davam edir.

Squid CONNECT sorğusunu necə qərarlaşdırır

CONNECT sorğusu bir host və bir port göstərir, Squid isə http_access sətirlərini sıra ilə keçərək onlardan biri uyğun gələnə qədər davam edir. Uyğun gələn imtina qiymətləndirməni dərhal bitirir və müştəri proksidən 403 alır. Qaydanın yerləşməsinin onun ifadəsindən daha vacib olmasının səbəbi budur. Eyni sətri bir pillə yuxarı qaldırmaq nəticəni tamamilə dəyişə bilər.

Ənənəvi qoruyucular Safe_ports xaricində hər şeyi və SSL_ports xaricində CONNECT-i imtina edir. Bu adlar öz konfiqurasiyanızda təyin olunan ACL-lərdir, yəni onların məzmunu protokola deyil, sizə aiddir. Bir distributiv Safe_ports kimi geniş port aralığına icazə verib CONNECT-i ayrıca məhdudlaşdıra bilər. Portun dizayn üzrə bağlandığını fərz etməzdən əvvəl canlı dəyərləri oxuyun.

Sorğunu rədd edən komponentin proksi olduğunu təsdiqləyin. Squid-in yaratdığı 403 VPN serverindən gələn TLS xəbərdarlığına heç bənzəmir və ikisini bir problemdə birləşdirmək ilk saatı baha başa gəlir. Sorğu üçün giriş jurnalı sətrinə baxın, çünki o, həm hərəkəti, həm də onu yaradan qaydayı qeyd edir.

Üç ayrı ACL yerinə bir birləşmiş uyğunluq qurun

İstisnanı üç faktdan qurun: təsdiqlənmiş mənbə diapazonu, bir təsdiqlənmiş təyinat ünvanı və son nöqtənin dinlədiyi tək port. İki ayrı ACL və bir birləşmiş uyğunluq çox fərqli siyasət yaradır, çünki qiymətləndirilən məhz birləşmədir. Birləşmiş ACL-i daşıdığı metoda görə deyil, icazə verdiyi şeyə görə adlandırın.

Aşağıdakı forma yoxlanılmış dəyərlərlə əvəz edilməli olan sənədləşmə diapazonlarından istifadə edir. Squid bu adların heç birini özünə saxlamır, yəni onları seçmək də, ardıcıl saxlamaq da sizə aiddir. Bu resept all-of qrupunu dəstəkləyən sənədləşdirilmiş konfiqurasiyaya malik Squid 6 və 7 üçün nəzərdə tutulub. Cari sənəd bu direktivləri Squid 8-də mövcud olmayan kimi qeyd edir, ona görə bunu miqrasiya yolu deyil, versiyaya bağlı resept kimi qəbul edin və tətbiq etməzdən əvvəl direktivi öz buraxılışınızın sənədi ilə yoxlayın.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of qrupu yalnız hər üzv uyğun gəldikdə uyğunlaşır, yəni mənbə, təyinat və port bir sətirdə yoxlanılır. Qrup özü heç nə vermir və üç faktdan yalnız ikisinə uyğun gələn sorğu onu ödəyə bilməz. Bu xüsusiyyət kimsə sonradan ikinci şlüz əlavə etdikdə istisnanı dar saxlayır. Ya yeni təyinat qəsdən əlavə edilir, ya da sorğu ilkin qoruyuculara qayıdır.

Port qoruyucularını silmədən onları əyin

Mövcud mövqelərində iki ənənəvi qoruyucu sətir belə görünür. Onlar adətən autentifikasiyadan sonra və hər şeyə icazə verən siyasət sətirlərindən əvvəl durur.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Hər birinə inkarlaşdırılmış birləşmiş uyğunluğu əlavə edin ki, uyğun gələn istisna əks halda onu rədd edəcək qoruyucudan keçsin. Yalnız qoruyucu sətirlər dəyişir və hər birinə yalnız bir əlavə şərt qatılır.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Bir giriş sətrindəki şərtlər birləşdirilir, ona görə sətir artıq yalnız həm ilkin yoxlamada, həm də istisnada uğursuz olan sorğuları rədd edir. Təsdiqlənmiş son nöqtə üçün sorğu keçir, qalan bütün sorğular isə köhnə port davranışını saxlayır. Bu, portu qlobal SSL_ports siyahısına əlavə etməkdən daha dardır, hansı ki həmin portu hər təyinat üçün icazəli edərdi. Əgər port artıq həmin siyahıda varsa, bu ACL heç nəyi daraltmır və köhnə, daha geniş icazə digər təyinatlar üçün qüvvədə qalır, ona görə istisnanın portu açdığını iddia etməzdən əvvəl canlı siyahını oxuyun. O da geri qaytarıla biləndir, çünki iki sətir əvvəlki formasına qayıdır. Giriş nəzarəti sənədi bu dəyişikliyin dayandığı sıralamanı və ənənəvi qoruyucuları sənədləşdirir.

İstisnanın yerləşdirilməməli olduğu yer

Cazibə qoruyucuların üstündə icazə qoyub bitirməkdir. Bu yerləşdirmə eyni zamanda işlək konfiqurasiyanın adətən yuxarısında duran autentifikasiya və yerli təyinat müdafiələrini də atlayır. Nəticə dar istisna deyil, üstündə şərh olan bir deşikdir. Hər hansı yeni icazəni müştəri siyasətinin qalan hissəsi ilə eyni yoxlanılmış mərhələdə saxlayın.

Port qoruyucularından sonra sorğunun hələ nəyə ehtiyacı olduğunu yoxlayın. Autentifikasiya olunmuş hesab, icazəli müştəri ünvanı və təyinat siyasəti hələ də tətbiq olunur və istisna onların heç birini dəyişmir. Əgər proksiniz təsdiqlənmiş hesaba artıq ixtiyari təyinatlar açırsa, port qoruyucusu heç vaxt əsl nəzarət olmayıb.

Son nöqtənin ümumiyyətlə TCP olub-olmadığını düşünün. CONNECT istisnası TCP axınlarını daşıyır və UDP istifadə edən OpenVPN profili onun vasitəsilə əlçatan olmayacaq. Profili TCP-yə yalnız server belə dinləyirsə və operator davranış fərqini qəbul edirsə dəyişin.

Sərhədi parserlə və real sorğu ilə yoxlayın

Yenidən yükləməzdən əvvəl konfiqurasiyanı analiz edin və bunu edərkən ikinci sessiyanı açıq saxlayın. Yenidən yükləmə zamanı sintaksis xətası proksini köhnə konfiqurasiyada saxlaya və ya yenisini tamamilə rədd edə bilər. Analizator rədd edilən sətri bildirir ki, bu da müştəri xətasının sizə deyəcəyindən çoxdur.

Sonra yenidən yükləyin və təsdiqlənmiş mənbədən proksi vasitəsilə bir real CONNECT göndərin. Analizatorun işə salınması birinci gəlir, çünki səhv yazılmış yenidən yükləmə sizə siyasət barədə heç nə öyrətmir.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Üç halı sınayın: təsdiqlənmiş mənbə və hesab, təsdiqlənməmiş mənbə, və eyni portda fərqli təyinat. Üçüncü hal istisnanın dar olduğunu sübut edən haldır, çünki portu təyinat uyğunluğu olmadan yoxlayır. Müştəri mesajına güvənmək əvəzinə hər üçü üçün giriş jurnalını oxuyun. Uğurlu CONNECT yalnız TCP axını yaradır, ona görə VPN əl sıxışması ayrıca test olaraq qalır.