VPN işə düşəndən sonra bulud təhlükəsizlik divarı hansı ünvanı görür
Tam tunnel verilənlər bazanızın gördüyü mənbə ünvanını dəyişir. İcazə siyahısını, özəl yolu və ya bölünmüş tunnel-i dəyişin, kredensialı yox.
VPN qoşulmazdan əvvəl işləyən və qoşulduqdan sonra uğursuz olan verilənlər bazası nadir hallarda kredensial problemi olur. Bulud təhlükəsizlik divarları mənbə ünvanlarını uyğunlaşdırır və tam tunnel onların uyğunlaşdırdığı ünvanı əvəz edir. Noutbukunuzun göndərdiyini düşündüyünüzlə serverin aldığı arasındakı fərq bütün xətanın özüdür və bir addımda ölçülə bilər.
Mənbə ünvanı nəyə çevrilir
Tam tunnel-də hər paket VPN şlüzündən çıxır, ona görə server ev bağlantınızı deyil, şlüzün çıxış ünvanını görür. Yolda irəli proxy varsa, gələn onun ünvanı olur. Hər ikisi qanuni mənbədir və heç biri ilk qaydanızdakı ünvan deyil.
Azure SQL-in server səviyyəli və verilənlər bazası səviyyəli firewall qaydaları məntiqi serverə çatan müştəri ünvanını uyğunlaşdırır, tam tunnel-dən sonra bu, çıxış ünvanıdır. Tək ünvana icazə verən AWS təhlükəsizlik qrupu da eyni cür davranır. Paket autentifikasiyadan əvvəl atılır, ona görə aldığınız xəta icazə problemi deyil, şəbəkə nasazlığı kimi görünür. İnsanların şifrələri sıfırlamağa başlamasının səbəbi məhz budur.
İcazə siyahısı harada qərarlaşır
Uğursuz yola uyğun gələn qaydayı oxuyun, yaratdığınızı xatırladığınız qaydayı yox. Onun əhatəsini, portunu, protokolunu və hər hansı kimlik yoxlamasından əvvəl qiymətləndirilib-qiymətləndirilmədiyini qeyd edin.
Sonra hansı qatın bu qərara qanuni sahib olduğunu müəyyənləşdirin. Ünvan qaydası trafikin haradan gəldiyini cavablandırır. Özəl son nöqtə xidmətin ümumiyyətlə özəl yoldan əldə edilə bildiyini cavablandırır. Bölünmüş tunnel istisnası hansı təyinatların tunnel-dən yan keçdiyini cavablandırır. Bunlar bir-birini əvəz etmir və hər biri tunnel dəyişəndə fərqli şəkildə uğursuz olur.
Üç düzəliş, üç qat
Aşağıdakı hər variant axını fərqli səbəbdən düzəldir və səhv olanı seçmək növbəti şlüz dəyişikliyinə qədər işləyən bağlantı yaradır.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Çıxış ünvanını əlavə etmək ən kiçik dəyişiklik və ən kövrəkdir, çünki yeni şlüz və ya başqa region onu səssizcə etibarsız edir. Ünvanı tunnel tərifinin yanında sənədləşdirin ki, ikisi birlikdə dəyişsin. Müvəqqəti geniş diapazon diaqnostikadır, düzəliş deyil; onu yerində saxlamaq daxili xidmətlərin belə açıq qalmasına səbəb olur.
Niyə idarə olunan platforma tunnel-ə qoşula bilmir
Heroku, AppHarbor və ya CloudBees kimi tətbiq platformaları kodunuzu tun və ya tap cihazı olmayan və onu yaratmaq üçün imtiyazı da olmayan mühitdə işlədir. Onların giriş modeli ixtiyari dinləmə soketi deyil, HTTP-dir. VPN binarını daşıyan buildpack yenə də interfeysi qoyacaq yer tapmır. İşlək üsullar verilənlər bazasının icazə verə biləcəyi statik çıxış ünvanı, platformanın təqdim etdiyi özəl bağlantı məhsulu və ya DMZ-də HTTPS ilə əldə edilən proxydır.
Bu proxy öz autentifikasiyası və jurnalı olan giriş yoludur. O, platformanı VPN-inizin üzvü etmir və bunu belə təsvir etmək heç kimin audit edə bilməyəcəyi qaydalar yaradır.
Uğursuz olan müştəridən yoxlayın
Yenidən qoşulun və müştərinin dəqiq yolunu təkrarlayın. Xidmətin jurnala yazdığı mənbə ünvanını, müştərinin verilənlər bazası adı üçün seçdiyi marşrutu və faktiki sorğunun nəticəsini bu sıra ilə yoxlayın. Şlüzdən edilən test şlüzün işlədiyini sübut edir, bu isə heç vaxt şübhə altında olmayıb. Əgər bağlantı indi autentifikasiya olunur və sorğu hələ də uğursuz olursa, qalan problem verilənlər bazası icazəsidir.
Tunnel hər dəyişdikdə bu qaydaları nəzərdən keçirin. Dəyişdirilmiş şlüz və ya yeni çıxış diapazonu tətbiq konfiqurasiyasında heç bir dəyişiklik olmadan yolu pozur.