İkinci WAN VPN girişi işləmir, əsas giriş isə işləməyə davam edir
İkinci WAN VPN girişi öz dinləyicisini, uyğun sertifikat kimliyini və geri dönüş yolunu tələb edir ki, müştəri keçidi ondan istifadə edə bilsin.
Əsas tunel işlək qalır, istifadəçilər işlərini davam etdirir, ikinci provayder xətti isə nə dəyişsəniz də boş qalır. Ehtiyat xətt üçün ünvan dərc etdiniz, ona ad yönəltdiniz, bəlkə müştəriyə ehtiyat giriş əlavə etdiniz, və müştəri ya onu heç sınamır, ya da autentifikasiyadan keçib sonra sıradan çıxır. Araşdırdığım hallarda keçid funksiyası adətən qaydasında idi; çatışmayan girişi istifadəyə yararlı edən beş şeydən biri idi. Ad ehtiyat ünvana çevrilə bilər, halbuki həmin interfeysdə heç nə dinləmir, və dinləyici bağlantını qəbul edə bilər, halbuki cavab əsas interfeysdən çıxır. Hər WAN-ı öz müqaviləsi olan ayrı giriş kimi qəbul edin, o zaman nasazlıq müştəri xətası kimi görünməyi dayandırır.
Hər WAN öz giriş müqaviləsini tələb edir
Hər WAN üçün beş sahə qeyd edin: ümumi ad və ünvan, nəqliyyat və port, onu sonlandıran interfeys və ya kontekst, təqdim etməli olduğu həmsöhbət kimliyi və cavabın haradan çıxdığı. İki xətt iki tam dəst deməkdir. Əgər ikinci dəstdə sonlandırıcı interfeys və ya geri dönüş yolu yoxdursa, ehtiyat girişiniz yoxdur; sadəcə niyyəti təsvir edən DNS qeydiniz var.
Cihaz və onun buraxılışı da bu quruluşu dəstəkləməlidir. DNS qeydi başqa interfeysdə xidmət aça bilməz və bir çox platformada dinləyici cihaz üzrə deyil, ünvan üzrə konfiqurasiya olunur. ASA-da interfeys əsaslı IPsec kripto xəritələrini və tunel qruplarını xarici interfeysə bağlayır, ona görə ikinci yuxarı kanal paketlərin həqiqətən gəldiyi yerdə siyasət tələb edir. Marşrut əsaslı dizaynlar fərqli davranır: dinləyici hər ünvana və ya bir adlandırılmış ünvana bağlana bilər və bu seçim B provayderinin ümumiyyətlə cavab verə biləcəyini müəyyən edir.
İkinci WAN-ın həqiqətən cavab verdiyini yoxlayın
Hər iki xəttin xaricindən sınaqdan keçirin, şlüz arxasındakı maşından deyil, və müştəri profilinin istifadə etdiyi dəqiq adı sınayın. TLS dinləyicisi üçün sürətli yoxlama openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts əmrinin şəbəkənizin xaricindəki hostdan işlədilməsidir. Profildəki ada uyğun zənciri olan tamamlanmış əl sıxma istəyirsiniz, sadəcə bağlantı qəbul edən TCP portu deyil.
RFC 9525 müştərinin nəyi yoxladığını izah edir: çatmaq istədiyi kimliyi xidmətin təqdim etdiyi sertifikatla müqayisə edir. Əsas girişin sertifikatını qaytaran və ya iki addan heç birini sadalamayan standart sertifikat təqdim edən ikinci giriş bu sınaqdan keçmir, hərçənd port açıqdır və firewall ona icazə verir.
Buradakı nasazlıqların çoxunu iki nümunə izah edir. Asılı qalan bağlantı adətən həmin interfeysdə dinləyicinin olmaması, yalnız əsas alt şəbəkələrə icazə verən giriş qaydası və ya ikinci xəttin qarşısındakı operator cihazının portu atması deməkdir. Səhv kimliklə bitən əl sıxma isə adətən başqa etibarnamə nöqtəsi, standart virtual host və ya kimliyi düzəltmədən əsasdan köçürülmüş konfiqurasiya deməkdir.
Cavabı izləyin, yalnız sorğunu deyil
İkinci WAN adətən geri yolda pozulur. Sorğu B provayderinə gəlir, cihaz cavab verir və cavab A provayderindəki standart marşrutla, müştərinin heç vaxt istəmədiyi mənbə ünvanı ilə çıxır. Vəziyyətli çevirmə işi daha da pisləşdirir: əgər xəritə əsas interfeys üçün qurulubsa, qayıdan paket çevirməni buraxır və ya müştərinin firewallunun atdığı mənbə daşıyır. Provayderlər də sizə verdikləri xəttə aid olmayan mənbə ünvanlarını atır, buna görə bu, təmiz protokol xətası deyil, birtərəfli qara dəlik kimi görünür.
İkinci girişdən qaynaqlanan trafik üçün marşrut qərarını yoxlayın. Cavab sorğunun gəldiyi interfeysdən çıxmalı, ya da ən azı uzaq tərəfin həmin yola aid kimi qəbul etdiyi ünvan daşımalıdır. Siyasət əsaslı marşrutlaşdırma platformalarında bu, daxil olan interfeysə və ya çevrilmiş mənbəyə bağlanmış qayda, üstəgəl hər xarici interfeysə bağlanmış çevirmə ifadəsi deməkdir. Müştəri qoşularkən eyni anda hər iki interfeysdə tutma aparın; B provayderinə gələn SYN və A provayderindən çıxan SYN-ACK məsələni bir gedişdə həll edir.
Müştəriyə ikinci girişi öyrənmək imkanı verin
Keçid müştəri tərəfində qərar olduğundan hər müştəri ailəsi alternativləri fərqli öyrənir. ASA-da ehtiyat server siyahısı qrup siyasətinin webvpn atributları ilə verilir, başqa müştərilər isə profilin içində siyahı və ya istifadəçinin seçdiyi əl ilə ikinci profil gözləyir. Cisco-nun bağlantı siyasəti təlimatı həm müştəridə konfiqurasiya olunmuş, həm də şlüz tərəfindən verilən ehtiyat məlumatını təsvir edir və həmin protokola xas təfərrüatlar hər müştəriyə və ya tunel rejiminə ümumiləşdirilməməlidir. İkinci girişi səhv mexanizm üzərində qurmazdan əvvəl yerləşdirilmiş müştərinin hansı mexanizmi tətbiq etdiyini təsdiqləyin.
Mexanizm nə olursa olsun, müştəri əsas yolu itirməzdən əvvəl alternativ adı həll edə bilməlidir. İnsanların qaçırdığı asılılıq budur: əgər ehtiyat adı yalnız təzəcə sıradan çıxmış tuneldən əlçatan həlledicinin cavablandırdığı haldırsa, geri çəkilmə ümumiyyətlə başlaya bilməz. İkinci adı yerli və ya internet üzərindən cavab verən həlledicidə dərc edin. Keçiddən sonra yeni autentifikasiya və yeni tətbiq sessiyası gözləyin, çünki müştəri keçidi vəziyyətli keçid deyil və uzunömürlü sessiyalar onu keçmir.
İki provayderdə bir ünvan başqa məhsuldur
Tək ümumi ünvanı hər iki xəttdən əlçatan saxlamaq marşrutlaşdırma xidmətidir, VPN-də işarələnən xana deyil. Bu, hər iki provayderin daşımağa razı olduğu ünvan fəzası, onların şəbəkələrinin qəbul etdiyi şəkildə elan olunmasını tələb edir və provayderdən asılı olmayan fəza ilə BGP-dən istifadə edən multihoming bunu təmin edir. A provayderinin ünvanını B interfeysinə təyin etmək bunu vermir; paket prefiksi heç vaxt elan etməmiş şəbəkəyə gəlir və yuxarıda atılır.
İki giriş dərc etmək üçün bunların heç birinə ehtiyacınız yoxdur. Müştəri iki ad saxlaya və aralarında keçə bilirsə, iki müstəqil giriş kifayətdir və siz AS nömrəsindən, peerinq razılaşmasından və hər yerdə qəbul edilməli prefiksdən yayınırsınız. Daşınan ünvan variantını yalnız müştərilərin dəyişdirilə bilməyəcəyi bir sabit giriş nöqtəsinə həqiqətən ehtiyacınız olduqda və ya TTL gecikməsi ilə DNS əsaslı keçid dizayn etdiyiniz fasilə üçün çox yavaş olduqda nəzərdən keçirin.
Bundan sonra nəyi yoxlamalı
Uğursuz girişdən xaricə doğru bu ardıcıllıqla işləyin: ikinci ünvan xaricdən cavab verirmi, müştərinin gözlədiyi kimliyi təqdim edirmi, cavab sorğunun gəldiyi yolla çıxırmı və müştəri ada ehtiyac duymazdan əvvəl onu öyrənə bilirmi. Cavab yoxdursa, həmin qatı düzəldin və sınaq hostu ilə deyil, yerləşdirilmiş profillə yenidən sınayın, çünki laboratoriyadan əl sıxma real müştəridən tamamlanmış bağlantıdan az sübut edir.
Hər WAN üçün ünvan, port, sonlandırıcı interfeys, sertifikat adı, geri dönüş yolu və çevirmə qaydası olan qısa qeyd saxlayın və xətt, NAT cihazı və ya müştəri versiyası dəyişdikcə onu yenidən yoxlayın. Boş ehtiyat yollar səssizcə çürüyür: heç kimin istifadə etmədiyi giriş barədə hamının ondan asılı olduğu günə qədər heç nə xəbərdarlıq etmir.