Failover tam konfiqurasiya edildiyi kimi işlədi və problem də elə bu idi. Əsas tunel düşəndə marşrutlaşdırıcı standart marşrutu kabel modemə keçirdi, noutbuklar internetdə gəzməyə davam etdi və heç kim zəng etmədi. İki gün sonra kimsə maliyyə paylaşımının altı saat ərzində açıq internet yolu ilə əlçatan olduğunu gördü. Marşrutlaşdırıcıdakı VPN failover siyasəti marşrutlaşdırma hiyləsi deyil; üstün yol getdikdə trafikin nə etməli olduğuna dair qərardır və bu qərar yol yox olmamışdan əvvəl mövcud olmalıdır.

Detektoru seçməzdən əvvəl nəticəni müəyyən edin

Adətən üç nəticə müzakirə olunur: təsirlənən müştəriləri ehtiyat tuneldən keçirmək, onlara adi WAN-dan istifadə etməyə icazə vermək və ya onları tamamilə bloklamaq. Hansının hansı VLAN, SSID və ya cihaz sinfinə aid olduğunu yazın. Tək düz “WAN-a keç” qaydası yuxarıdakı maliyyə paylaşımının açıq yola düşməsinin səbəbidir.

Bu üçü bir-birini əvəz etmir. WAN-a keçid dəstək masasının telefonlara cavab verməsini saxlayır, amma daxili adları yerli həll ediciyə açır. Ehtiyat tunel siyasəti qoruyur, lakin qarşı tərəfin qəbul etmədiyi çıxış ünvanına düşə bilər. Bloklama əməkhaqqı VLAN-ı üçün düzgün, tuneldən heç vaxt istifadə etməmiş qonaq şəbəkəsi üçün isə səhvdir.

NəticəNə üçün uyğundurNə pozulur
Ehtiyat tunelSiyasət qorunmalıdır, uzaqdan giriş tələb olunurYeni çıxış ünvanı, geri marşrut, daha yavaş açar yeniləmə
Adi WANQonaq və ya yalnız publik trafikDaxili adlar, DNS və IPv6 ifşası
BloklamaƏməkhaqqı, admin, yalnız VPN olan hər şeyİstifadəçilər bütün girişi itirir və sizə zəng edir

Detektoru əsl qorxduğunuz nasazlığa uyğunlaşdırın

Handshake vəziyyəti, interfeys vəziyyəti və istifadə oluna bilən yönləndirmə üç fərqli siqnaldır və istifadəçi üçün yalnız sonuncusu vacibdir. WireGuard peer provayderin yuxarı axını paketləri qara dəliyə atarkən təzə handshake göstərə bilər. OpenVPN müştərisi itələdiyi marşrut həll olunmağı dayandırdıqdan sonra “qoşulub” vəziyyətində qala bilər.

pfSense-də praktik quruluş dpinger ilə qidalanan şlüz qrupudur; dpinger monitorinq ünvanını yoxlayır və itki və ya gecikmə hədlərini aşanda şlüzü aşağı işarələyir. Bu monitoru tuneldən kənarda bir şeyə yönəldin, məsələn uzaq LAN-dakı hosta və ya onun vasitəsilə çatdığınız publik ünvana. Onu tunelin öz peer ünvanına yönəltmək artıq canlı olduğunu bildiyiniz hissəni ölçür.

Qrupu elə qurun ki, ehtiyat son çarə olsun

Düz üzv siyahısı yerinə pillələrdən istifadə edin. Əsas 1-ci pillədə, ehtiyat tunel 2-ci pillədə, WAN isə 3-cü pillədə yalnız siyasəti buna icazə verən VLAN-lar üçün. pfSense-də bu System > Routing > Gateway Groups altındadır: hər iki şlüzü əlavə edin, onlara fərqli pillələr verin, Trigger Level-i member down plus packet loss olaraq qoyun, saxlayın, sonra qrupu interfeys standartı kimi və ya ona ehtiyac duyan firewall qaydalarının Gateway sahəsində tətbiq edin.

pfSense 2.5 və sonrakı versiyalarda OpenVPN müştəri instansiyası üçün instansiyanın Default Gateway parametri tunelin sistemin standart marşrutunu ümumiyyətlə əvəz edib-etmədiyini müəyyən edir. Qayda ilə siyasət marşrutlaşdırması yalnız güman etdiyiniz marşrut həqiqətən quraşdırıldıqda gözlədiyiniz kimi işləyir. Dəyişiklikdən sonra tunel statusu ikonuna güvənmək əvəzinə Status > Gateways yoxlayın.

Tərpənmələrin çoxuna iki parametr səbəb olur. Biri provayderin öz yenidən yığılmasından qısa yoxlama intervalıdır. Digəri əsas və ehtiyatın eyni pilləni paylaşdığı qrupdur, beləliklə hər ikisi hər zaman uyğun qalır. İstifadəçiləriniz keçidləri sizin yerinizə hiss etməzdən əvvəl itki və gecikmə hədləri ilə histerezis əlavə edin.

Tunelin heç vaxt sahib olmadığı yolları bağlayın

Əvvəlcə DNS sızmaları. Həll edici WAN-da cavab verməyə və oradan yönləndirməyə davam edir, buna görə trafik tunelə bərkidilmiş halda adlar ISP vasitəsilə həll olunur. Həll edicinin çıxış interfeyslərini məhdudlaşdırın, daxili həll edicini müştərilərə ötürün və yalnız VPN olan VLAN-larda 53 portunu qalan hər şey üçün bloklayın.

IPv6 öz qərarını tələb edir. İkili yığımlı LAN tuneli itirə və işlək qlobal IPv6 standart marşrutunu saxlaya bilər, buna görə brauzerlər IPv6-ya üstünlük verir və WAN-dan çıxır, IPv4 isə tamamilə qapalı görünür. Ya IPv6-nı tunelə yönəldin, ya da tunel aşağıda ikən qlobal prefiks elan etməyi dayandırın. Yarım siyasət heç olmamasından pisdir, çünki işləyirmiş kimi görünür.

Sonra geri yol. Ehtiyat çıxış fərqli mənbə ünvanı istifadə edirsə, qarşı tərəf trafiki ora necə geri göndərəcəyini bilməlidir və köhnə ünvana bağlanmış hər vəziyyət artıq ölüdür. Əsas düşəndə açıq olan sessiyalar miqrasiya etmir; vaxtları bitənə qədər dayanır və tətbiq bununla bağlı qərar verir.

Düşməni, tərpənməni və geri dönüş yolunu sınayın

Zərərsiz trafik işləyərkən əsası çıxarın, sonra dörd şey oxuyun: Status > Gateways qrupun üzv vəziyyətləri üçün, pfctl -ss hələ köhnə şlüzə bərkidilmiş vəziyyətlər üçün, çıxış yolu üçün müştəridən traceroute, və hansı serverin cavab verdiyini görmək üçün həll edici sorğusu.

İndi onu tərpədin. Əsası otuz saniyə qaldırın, otuz saniyə aşağı salın, iki dəfə. Trafik hər keçidi izləyirsə, hədlər çox sıxdır və ya pillələr səhvdir. Bunu öz cədvəlinizdə düzəldin, çünki əks halda provayder bunu öz cədvəlində edəcək.

Nəhayət, marşrutlaşdırıcını hələ də idarə edə bildiyinizi təsdiqləyin. Konsol kabeli, idarəetmə VLAN-ı və ya mobil modem kimi zolaqdan kənar yol saxlayın. Sizi kilidləyən failover testi bitirə bilmədiyiniz testdir və əlçatmaz marşrutlaşdırıcı özü geri qayıda bilməz.

Siyasəti bitmiş adlandırmazdan əvvəl terminal açmadan dörd suala cavab verə bilməlisiniz: tunel aşağıda ikən hansı VLAN-lar WAN-dan istifadə edə bilər, detektor nəyi izləyir və nə qədər gözləyir, hansı ad serverləri və IPv6 marşrutları yolla birlikdə hərəkət edir, və ehtiyat da sıradan çıxsa necə geri qayıdırsınız. Əgər hər hansı cavab “standart nə idisə” olarsa, siyasət hələ də sizə deyil, marşrutlaşdırıcıya aiddir.

Əlaqəli məqalələr