AWS Client VPN son nöqtəsi DNS: həll olunmuş IP-ni bərkitmək niyə alınmır

Keçən həftə dig +short sizə AWS Client VPN profilinizdəki son nöqtə adı üçün bir ünvan verdi və tunel qoşuldu. Bu həftə həmin profil noutbukunuzda 'Connecting' vəziyyətində qalır, həmkarınızın toxunulmamış surəti isə hələ də işləyir. Heç nə bloklanmadı və sertifikatın müddəti bitmədi. Kimsə son nöqtə host adını həmin həll olunmuş ünvanla əvəz etdi və xidmət artıq orada cavab vermir. İxrac edilmiş ad bu dəyişikliyə tab gətirmək üçün qurulmuş hissədir.

Profilinizdəki ad sorğulanan ad olmaya bilər

Client VPN-dən ixrac edilən profillər adətən remote-random-hostname daşıyır. Bu seçim aktiv olduqda müştəri birdəfəlik etiket yaradır, onu nöqtə ilə son nöqtə adına birləşdirir və birləşmiş adı həll edir. Son nöqtənin zonasındakı wildcard qeydi istənilən etiketə cavab verir; buna görə uydurulmuş prefiks də həll olunur və sorğunu əl ilə təkrarlamağa çalışdığınızda bu hiylə görünməz qalır.

Beləliklə, son nöqtə adını terminala yapışdırıb cavab aldığınızda, müştərinin qoşulma anında istifadə etdiyi addan fərqli bir adı həll etmisiniz. Bu uyğunsuzluq profildə düzəldilməli qüsur deyil. Etiket qəsdən yenidən yaradılır: seçim keşlərin köhnəlmiş cavabı saxlamasının qarşısını alır və o, heç vaxt maşınınızı və ya sessiyanızı identifikasiya etmir.

Müştərinin seçimi tamamilə görməzdən gəldiyi uyğunluq halı ilə rastlaşmışam. AWS bunun həllini sənədləşdirir: həqiqi son nöqtə adını saxlayın və qarşısına təsadüfi sətir və nöqtə əlavə edin, buna yapışdırılacaq dəyər kimi deyil, adlandırma nümunəsi kimi baxın. Bunu köhnə müştəriyə tətbiq etmək məqbuldur; prefiksli sətri son nöqtə kimi kodla bərkitmək isə deyil.

Niyə saxlanmış cavab düzgün qala bilməz

Client VPN son nöqtə ünvanları AWS tərəfindən idarə olunur və zamanla dəyişir; ən yaxşı təcrübələr sənədi bunu açıq deyir. Tutulmuş cavab bir həllin anlıq şəklidir. Onu kodla bərkidən profil, xidmət köçən kimi istismardan çıxarılmış hosta tuşlanmış profilə çevrilir və nasazlıq nadir hallarda DNS kimi görünür: qoşulma zaman aşımı və ya dayanmış handshake alırsınız, ona görə insanlar marşrut və sertifikatların ardınca qaçır.

/etc/hosts içindəki eyni cavab eyni bitmə tarixini əlavə problemlə birlikdə miras alır. hosts qeydi yenidən başlatmalardan, yenidən ixracdan və 'müştərini yenidən quraşdır' düzəlişlərindən sağ çıxır, ona görə ünvan hər dəfə köçəndə nasazlıq qayıdır. Birinin həftələrlə zərərsiz qaldığını, sonra onu daşıyan bütün maşınları sıradan çıxardığını, yeni quraşdırmaların isə normal qoşulduğunu görmüşəm. Bu bölünmə, eyni hesabda bir qrupun uğursuz olması və digərinin yaxşı olması, əldə edəcəyiniz ən ucuz ipucudur.

Təsadüfiləşdirmənin əhatəsini də düzgün müəyyən edin. O, hər qoşulma cəhdi üçün baş verir. Qurulmuş tunel son nöqtəsini yenidən həll etmir, sessiya ortasında server dəyişmir və ayrı-ayrı tətbiq sorğuları hər dəfə yeni VPN hostu seçmir. Yalnız növbəti cəhd yenidən həll edir; buna görə bütün gün işləyən sessiya sabah səhər haqqında heç nə demir.

Tunel qalxanda xidmət nəyi yoxlayır

Client VPN qoşulduğunuz ünvanın son nöqtənin DNS adı üçün həll olunmuş ünvanla uyğun gəlməsini tələb edir. Bu bir tələb əlaqəsiz görünən bir neçə nasazlığı izah edir: başqa yerə yönələn fərdi DNS qeydi, həqiqi son nöqtə ünvanına yönləndirən fərdi frontend və xam ünvana yenidən yazılmış profil. AWS fərdi qeyd və yönləndirmə quruluşunu son AWS müştəriləri ilə nasazlıq kimi sənədləşdirir. Yoxlama dardır; hər ləqəbin qadağan olunduğuna dair hökm deyil.

Bu, VPN protokolları haqqında ümumi qayda da deyil. Rəqəmsal remote adi OpenVPN yerləşdirməsində tamamilə etibarlıdır və çoxu belə işləyir. Məhdudiyyət idarə olunan quruluşdan gəlir, altındakı protokoldan deyil.

Bu da sertifikat yoxlamasını yumşaltmağı yanlış refleks edir. Ünvan dəyişikliyindən sonra profil uğursuz olursa, server yoxlamasını söndürmək həlli və ya ünvan uyğunluğu tələbini düzəltmək əvəzinə xətanın yerini dəyişir və hər şeyə güvənən müştəri qoyub gedir. İxrac edilmiş CA-nı, server yoxlamasını və qarşılıqlı autentifikasiya parametrlərini gəldiyi kimi saxlayın.

İcazə siyahıları, çıxış və şəxsi DNS üç ayrı problemdir

Noutbuk qoşulmazdan əvvəl təyinatı icazəli etməli olan firewall qaydası xarici listenerə aiddir. Şəbəkə sahibinə son nöqtə adını, nəqliyyatı və konfiqurasiya olunmuş portu verin, sonra onların nəzarətinin xidmətin DNS davranışını izləyə bilib-bilmədiyini soruşun. Bir tutulmuş ünvanı saxlayan qayda yazılmamış bitmə tarixi olan anlıq şəkildir. Əgər nəzarət yalnız dəyişməz təyinatları qəbul edirsə, cavabı sakitcə kodla bərkitmək əvəzinə bu boşluğu yerləşdirmədən əvvəl həll edin.

Tunel qurulduqdan sonra edilən sorğular üçün sabit mənbə ünvanına ehtiyacı olan tərəfdaşın fərqli tələbi var: çıxış. Veb saytın gördüyü şey tətbiq marşrutundan və split-tunnel siyasətindən asılıdır, müştərinin qoşulduğu ünvandan deyil. Split-tunnel trafiki AWS-ə heç vaxt toxunmaya bilər.

Tunel daxilində şəxsi DNS üçüncü qatdır. Müştərilərə verilən resolver qoşulmadan sonra daxili adlara cavab verir; tunel mövcud olmazdan əvvəl o, ictimai son nöqtəni həll edə bilməz. Son nöqtə həlli nasazlığı ilə daxili tətbiq həlli nasazlığı müxtəlif mərhələlərdə baş verir və onları qarışdırmaq sizi səhv jurnala göndərir.

Ünvan ailəsi də eyni siyahıya aiddir. IPv4 cavabı IPv6 və ya ikili stack son nöqtənin icazəli yolu haqqında heç nə demir, ona görə bir ailədə götürülmüş anlıq şəkil digəri üçün sübut deyil.

Heç nəyi bərkitmədən bağlantını yoxlayın

İxrac edildiyi kimi profildən başlayın və onun həqiqətən nə istədiyini oxuyun:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Sonra üç şeyi müqayisə edin: profilin saxladığı son nöqtə adı, müştərinin yeni cəhd üçün bildirdiyi ünvan və adın indi həll olunduğu yer. Həll olunan ad yalnız qeydin cavab verdiyini sübut edir; nəqliyyat və autentifikasiya ayrıdır və son nöqtə ping-ə cavab vermək məcburiyyətində deyil. Ortadakı element üçün yeganə mənbə müştərinin öz jurnalıdır, ona görə onu cəhddən sonra deyil, cəhd zamanı yazın.

Bu gün cavab verən ünvan bu gün haqqında sübutdur; ad xidmətin etibarlı saxladığı şeydir. Müşahidəni qeyd edin, son nöqtənin sahibinə göndərin və profili ada yönəldilmiş saxlayın.

İki vərdişdən əl çəkin: dayanmış handshake-dən keçmək üçün sertifikat yoxlamalarını söndürmək və birinin yapışacağına ümid edərək son nöqtə adının qarşısına etiketlər yığmaq. Etiket wildcard qeydi vasitəsilə həll olunur, əks halda problem başqa yerdədir. Düzgün konfiqurasiya edilmiş profil yenə də uğursuz olursa, daha uzun host adı deyil, dəqiq sorğunu və qoşulma hadisəsini göndərin.

Bağlamazdan əvvəl: profil hələ də ixrac edilmiş son nöqtə adını daşıyır, heç bir hosts faylı ünvanı bərkitmir, müştəri jurnalındakı remote cari həllə uyğundur və firewall qaydası ünvanı deyil, son nöqtəni adlandırır. Bu, növbəti şəxsə verməli olduğunuz vəziyyətdir.