Access Server müştəriləri LAN-dan niyə əlçatmazdır

Noutbuk qoşulur, tunel qalxır və daxili xidmətə sorğular qoşulma mərhələsində donur. Xidmətin özündə sorğu 10.90.0.25 kimi bir ünvandan gəlir, cavab defolt şlüzə doğru çıxır və heç nə geri qayıtmır, çünki o şlüz 10.90.0.25-in harada olduğunu bilmir. Digər tərəfdən eyni nasazlıq qoşulmuş müştəriyə ping göndərə bilməyən daxili host kimi görünür. Hər ikisi bir itkin obyektdir: VPN müştəri hovuzuna geri marşrut, onu yalnız özəl şəbəkə əlavə edə bilər.

Xidmətin gördüyü mənbə ünvanını oxuyun

Bu tək sahə qalan hər şeyi müəyyən edir. Daxili xidmət hovuz ünvanını görürsə, Access Server müştəri trafikini gizlətməkdən çox yönləndirir və hər cavab hovuza geri yönləndirilməlidir. Əgər bunun yerinə serverin öz özəl ünvanını görürsə, server maskalanma edir və cavab yolu artıq işləyir, lakin xidmətin jurnallarında və giriş qaydalarında hər müştəriyə aid kimlik itir.

Nəyisə dəyişməzdən əvvəl hər iki ucu müqayisə edin. Serverdə tunel interfeyslərini və onların ünvanlarını sadalayın; müştəridə onlardan hansını həqiqətən saxladığını təsdiqləyin; daxili hostda canlı bağlantıya baxın.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Son əmr pozulmuş halda uğursuz olan əmrdir: ya tunel prefiksini əlçatmaz kimi bildirir, ya da daha pisi, defolt şlüzünüzü qaytarır, cavabların internetə düşməsi belə olur.

Bir hovuz olduğunu güman etməyin. Serverin dinamik diapazonu və hər istifadəçi üçün statik xəritələmələri ola bilər və statik ünvan dinamik prefiksdən tamamilə kənarda yerləşə bilər. Yalnız xatırladığınız diapazonu yönləndirsəniz, sabit ünvanlı istifadəçilər nasaz qalır, qalan hər kəs isə problemi həll olunmuş kimi bildirir.

Marşrutu cavabın həll olunduğu yerə əlavə edin

Marşrut daxili xidmətin artıq istifadə etdiyi şlüzə aiddir, xidmətə yox, əgər o öz trafikini yönləndirmirsə. Onu Access Server-in əlçatan özəl ünvanına yönəldin, bu müştərinin saxladığı tunel ünvanından fərqli bir dəyərdir.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Bulud şəbəkəsində eyni ifadə hədəfi serveri işlədən instansiya və ya şəbəkə interfeysi olan, həmin interfeysdə mənbə və təyinat yoxlaması söndürülmüş marşrut cədvəli qeydinə çevrilir. Bu qeydin nə etmədiyinə diqqət yetirin: marşrut giriş icazəsi deyil, ona görə təhlükəsizlik qrupları, şəbəkə ACL-ləri və host firewall-u trafikə hələ də icazə verməlidir.

Onu davamlı edin və hovuz ölçülərini dürüst saxlayın. Bir-birinə bitişik olmayan iki hovuz iki marşrut tələb edir və konfiqurasiya edilmiş prefiksindən kənara böyüyən hovuz səssizcə cavabları heç yerə getməyən müştərilər yaradır. Hovuz diapazonlarına nəzarət edirsinizsə, bir dəfə yönləndirib tək qoya biləcəyiniz xülasə seçin.

Yönləndirmə və filtrlər marşrutla razılaşmalıdır

Yönləndirmə yolun yalnız yarısıdır. Serverə tunel ilə özəl interfeys arasında yönləndirməyə icazə verilməlidir, Linux-da bu net.ipv4.ip_forward və interfeys cütünə icazə verən yönləndirmə zənciri deməkdir, sərtləşdirilmiş hostda isə adətən hər istiqamət üçün açıq qayda.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Vəziyyətli filtrləmə insanları yanlış yola salan bir simptomu izah edir. Qurulmuş axın daxilindəki cavab yeni daxil olan qayda tələb etmir, ona görə SYN-ACK-dən sonra donan bağlantı çatışmayan qəbul qaydası ilə bloklanmır; o, atılır və ya səhv yönləndirilir. Bu fərqi saxlayın, çünki o, marşrut dəyişikliyini firewall dəyişikliyindən ayırır.

Asimmetrik geri yollar eyni problemin daha sakit versiyasıdır. Hovuza iki marşrut çatırsa və cavab sorğunun gəldiyi interfeysdən fərqli interfeysdən çıxanı seçirsə, sərt tərs yol filtri onu atır və axın yalnız bəzi müştərilər üçün uğursuz olur.

Yönləndirilmiş və ya maskalanmış: qəsdən seçin

Yönləndirilmiş rejim müştərinin hovuz ünvanını xidmətdə saxlayır, bu hər müştəri üzrə jurnal və hər müştəri üzrə siyasət imkanı verir və əvəzində müştəriyə cavab verməli hər daxili şəbəkə hovuz marşrutuna ehtiyac duyur. Maskalanmış rejim bu tələbi aradan qaldırır, çünki cavablar serverə qayıdır, lakin xidmət artıq bir müştərini digərindən ayıra bilmir və konkret müştəriyə doğru heç nə başlada bilmir.

Canlı serverdə bu davranışı dəyişmək mövcud sessiyaları kəsir, ona görə əvvəlcə bir müştəri və bir axınla sınaqdan keçirin. Keçid düzgün cavabdırsa, bu serverdə konfiqurasiya qərarıdır, lazımsız olacaq marşrutlar əlavə etməklə yan keçiləcək bir şey deyil.

Müştərinin arxasındakı alt şəbəkə ayrı bir vəzifədir

Noutbukun öz LAN-ındakı cihaza çatmaq noutbukun tunel ünvanına çatmaqla eyni deyil. Bu, müştərinin alt şəbəkə şlüzü kimi çıxış etməsini tələb edir: elan edilmiş müştəri tərəfi şəbəkəsi, müştərinin əməliyyat sistemində yönləndirmənin aktivləşdirilməsi və həmin LAN-da müştəriyə geri marşrut. Noutbukun ev diapazonu üçün özəl şəbəkə marşrutu əlavə etmək bunu etmir və iki istifadəçinin eyni ev diapazonu olduqda toqquşmalar yaradır.

İstiqamət də siyasət məsələsidir. Müştəriyə daxili xidmətə bağlantı açmaq icazəsi avtomatik olaraq daxili hosta həmin müştəriyə bağlantı açmaq icazəsi vermir. Yolun pozulduğu qənaətinə gəlməzdən əvvəl serverin giriş siyasətini və müştərinin host firewall-unu yoxlayın.

Bir axın və bir tutma ilə yoxlayın

Yolu ümumi əlçatarlıq testi yerinə tək bağlantı ilə sübut edin. Eyni axını hər iki uçda izləyin: xidmətə çatan sorğu və onu tərk edən cavab.

tcpdump -ni any host 10.90.0.25 and port 443

Düzəlişdən əvvəl tutma cavabın onu yönləndirməyəcək şlüzə doğru çıxdığını göstərir. Düzəlişdən sonra cavab serverə doğru çıxır və axın tamamlanır. Sonra şlüzün ikinci müştəri ünvanı üçün istifadə edəcəyi marşrutu təsdiqləyin ki, əhatə etmədiyiniz hovuz bir həftə sonra deyil, indi görünsün.

Bu işi bağlayan dörd yoxlama ilə bitirin: xidmətdəki mənbə ünvanı nəzərdə tutduğunuz rejimə uyğundur, şlüzün istifadədə olan hər hovuza marşrutu var, yönləndirmə və filtrlər hər iki istiqamətə icazə verir və bir real axın başdan sona tamamlanır. Access Server marşrutlaşdırma FAQ quraşdırılmış buraxılış üçün eyni prinsipi bildirir, onun dəstəklənən konfiqurasiya interfeysi köhnə təlimatlardan fərqli ola bilər.