AWS Client VPN DNS: subnet deyil, VPC resolverindən istifadə edin
AWS Client VPN endpointi üçün resolver əsas VPC diapazonu üstəgəl ikidir, hər subnet üstəgəl iki deyil. Onu təyin edin, marşrutlaşdırın, sonra klienti yoxlayın.
Endpoint 10.0.8.0/24 şəbəkəsindədir, deməli resolver 10.0.8.2 olmalıdır. Ən çox eşitdiyim məntiq budur və iki dəfə səhvdir. Route 53 Resolver əsas VPC IPv4 diapazonu üstəgəl iki ünvanında cavab verir; 10.0.0.0/16 VPC üçün bu, endpointin hansı subnetworkdən istifadə etməsindən asılı olmayaraq 10.0.0.2 ünvanıdır. İkinci səhv daha səssizdir: düzgün ünvanı endpointə yazmaq, klientin əməliyyat sisteminin ondan heç nə soruşduğu demək deyil. Hər iki səhv eyni simptomu verir: ad həlli bəzi klientlərdə işləyir, digərlərində uğursuz olur.
Mif subnet assosiasiyasından başlayır
Assosiasiya klient bağlantıları üçün elastik şəbəkə interfeyslərinin harada yerləşdiyi ilə bağlıdır, hansı resolver ünvanının mövcud olması ilə deyil. Endpointin subnetworkləri klientlərə VPC daxilində ünvan verir və onların hər biri öz resolverini daşımır.
Bu iki fikri ayırdıqdan sonra hesablamalar sirli olmaqdan çıxır və problem axtarışı klientə keçir, bu halların çoxu da məhz orada bitir.
Ünvanı əsas VPC diapazonundan hesablayın
VPC-nin əsas IPv4 CIDR-ini götürün və şəbəkə ünvanına iki əlavə edin. 10.0.0.0/16 10.0.0.2 verir, 172.31.0.0/16 172.31.0.2 verir, ikincil diapazonu olan VPC-də isə resolver əsas diapazonda qalır. Həmin VPC daxilindəki 10.0.8.0/24 subnetworki onu dəyişmir. Endpointə toxunmazdan əvvəl ünvanı VPC ID-nin yanına yazın, çünki bu rəqəm əlaqənin deyil, VPC-nin xassəsidir.
VPC həmçinin link-local 169.254.169.253 ünvanında cavab verir. Bu ünvan VPC daxilindən əlçatandır, amma tunelin o biri tərəfindəki noutbuk üçün ümumi marşrutlaşdırılan hədəf deyil.
Yəni iki etibarlı resolver ünvanı var və heç biri subnet üstəgəl iki deyil.
Endpoint parametrinin nə edib nə etmədiyi
Client VPN endpointinin DNS server sahələri var, konsol VPC resolver seçimi təqdim edəndə eyni fikri doldurur. Onları təyin etmək xidmətin bağlantı qurularkən klientlərə verdiyi dəyəri dəyişir. Bu, idarə olunmayan OpenVPN klientinin həmin dəyərlə nə etdiyini dəyişmir, çünki klient onu hələ də əməliyyat sisteminə tətbiq etməlidir. «Mac-də işləyir, Linux qutusunda işləmir» ifadəsi bu boşluqdan yaranır.
Linux-da resolver inteqrasiyası istifadəçinin deyil, bağlantı menecerinin mülkiyyətidir. /etc/resolv.conf faylını əl ilə redaktə etmək ünvanın bir sessiya üçün işlədiyini sübut edir, sonra yenidən qoşulmada yox olur; buna görə düzəldilmiş bir çox hal növbəti səhər geri qayıdır.
Qoşulduqdan sonra endpointin konfiqurasiya səhifəsini deyil, klientdə aktiv resolveri yoxlayın.
Split tunneling düzgün resolveri məğlub edə bilər
Split tunneling ilə yalnız tunelə ötürülən marşrutlar istifadə olunur. Resolver ünvanı marşrutla əhatə olunmayıbsa, sorğu yerli interfeysdən çıxır və ev marşrutlaşdırıcınız cavab verir. Endpointdəki ünvan yenə düzgündür, axtarış yenə uğursuzdur. Resolver üçün marşrut əlavə edin, sonra yenidən sınayın.
Üst-üstə düşən yerli diapazonlar eyni nəticəni daha pis şəkildə verir: sorğuya cavab verilir, sadəcə səhv server tərəfindən.
Amazon DNS ünvanı üçün təhlükəsizlik qruplarını açmayın
Axtarışlar vaxt aşımına uğrayanda instinkt resolver ünvanına UDP 53 icazə verən qayda əlavə etməkdir. AWS sənədləşdirir ki, təhlükəsizlik qrupları və şəbəkə ACL-ləri Amazon DNS trafikini fərdi DNS instansiyasına gedən trafik kimi filtrləmir. Bu qaydaları açmaq VPC resolveri üçün heç nəyi dəyişmir və sərhədi səbəbsiz genişləndirir. Özünüz idarə etdiyiniz resolver başqa haldır və həqiqətən öz qaydalarına ehtiyac duyur.
Dizaynınızda hər ikisi varsa, hər hansı qaydanı redaktə etməzdən əvvəl klientin hansına yönəldiyini yoxlayın.
Yolu yoxlayın, sonra başqa bir şey ölçün
Açıq adı həll edin, VPC ilə assosiasiya olunmuş fərdi host zona daxilində qeydiyyatdan keçmiş fərdi adı həll edin və ikisi arasında klientin aktiv resolverini oxuyun. Bu ardıcıllıq «resolver ünvanı səhvdir» halını «zona assosiasiya olunmayıb» və «klient parametri nəzərə almadı» hallarından ayırır. Hər birinin fərqli düzəlişi var və heç biri ötürmə qabiliyyəti problemi deyil.
Uğurlu axtarış davamlı ötürmə sürəti haqqında heç nə demir, ona görə hesabat verərkən bu iki söhbəti ayrı saxlayın.