NAT VPN serverində, yoxsa routerdə? Hər ikisi işləyə bilər

Laptopda bağlantını defolt marşrut kimi qeyd etmək hamının xatırladığı addımdır və elə şlüzda heç nəyi dəyişməyən addımdır. Müştəri artıq internet sorğularını tunelə göndərir; onların binadan çıxıb-çıxmaması yönləndirmədən, tərcümə nöqtəsindən və müştərinin özəl ünvanına çatan qayıdış yolundan asılıdır. İki təşkilat hər üçünü təmin edə bilər, onlar işi müxtəlif yerlərə qoyur və heç kim cavab istiqamətinə sahib olmadıqda hər ikisi eyni səssiz şəkildə uğursuz olur. Aralarında seçim etmək müştəri hovuzunu kimin görməli olduğuna dair bir sualdır.

Mif: müştəri marşrutu çıxış yaradır

Məcburi tunelleşdirmə müştəri tərəfindəki siyasətdir: trafikin fiziki adapterə deyil, VPN adapterinə getdiyinə qərar verir. Microsoft-un VPN marşrutlaşdırma sənədləri bu ayrılma və məcbur etmə davranışını təsvir edir və bu, müştərinin marşrut cədvəli haqqında, serverin yönləndirmə qaydaları haqqında deyil, bir ifadədir. Müştərinin baxışından tunel internetin yaşadığı yerdir; şlüzün baxışından isə paket yuxarıda heç kimin eşitmədiyi bir ünvandan gəlib. Heç bir tərəf tək başına səhv konfiqurasiya edilməyib, buna görə də laptopun yanındaki adam üçün nasazlıq sınıq server kimi görünür.

Bu uyğunsuzluq məqalənin qalan hissəsinin həll etdiyi bütün problemdir. Nə isə müştərinin özəl ünvanını qaytarıla bilən etməlidir və seçim harada olduğundadır.

Əvvəlcə cavab yolunu çəkin

Heç bir sazlamağına toxunmazdan əvvəl yolu real ünvanlarla yazın və üzərində iki namizəd tərcümə nöqtəsini qeyd edin. Bu laboratoriya 10.70.0.0/24 VPN hovuzundan, 10.70.0.37 ünvanında bir müştəridən, serverin 172.16.40.10 LAN ünvanından, 172.16.40.1 ünvanında bir routerdən və 203.0.113.40 ünvanında ictimai çıxışdan istifadə edir.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Serverin artıq internetə baxması yalnız öz yolunu sübut edir. Müştəri adından yönləndirilən paket fərqli bir qərardır, həmin maşında yönləndirmə siyasəti ilə verilir və adətən çatışmayan da elə budur. Diaqramda üç qərar nöqtəsini qeyd etmək söhbəti hər dəfə onlardan biri haqqında saxlayır.

Seçim A: VPN serverində tərcümə

Burada server paketi routerə verməzdən əvvəl müştərinin mənbəyini öz LAN ünvanına tərcümə edir, router isə çıxışda adi tərcüməsini tətbiq edir. Cavabda routerin xəritələməsi server ünvanını, serverin xəritələməsi isə müştəri ünvanını bərpa edir. Ardıcıl iki vəziyyət saxlayan tərcümə normal və işləkdir, bir şərtlə ki, hər ikisi qeydə alınsın; routerin hovuza marşruta heç vaxt ehtiyacı olmur və bu təşkilatın cəlbediciliyi də budur.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Bu oxumalardan NAT-ın mövcud olduğunu fərz etmək əvəzinə serverin artıq nəyə sahib olduğunu görmək üçün istifadə edin. Bloqdan kopyalanmış Linux masquerade qaydası Windows konfiqurasiyası deyil və VPN dinləyicisi üçün host firewall icazəsi müştərinin sorğusunu irəli yönləndirmə icazəsi ilə eyni siyasət deyil. Serverin yönləndirmə rolunu öz idarəetmə interfeysindən təsdiqləyin, sonra tərcüməyə ayrıca baxın, çünki ikisi çox vaxt yerləşdirmənin müxtəlif hissələri tərəfindən aktivləşdirilir.

Seçim B: hovuzu routerə daşımaq

İkinci təşkilatda server müştərinin həqiqi mənbə ünvanını yönləndirir və router onu tərcümə edir. Bu, müştəri hovuzunu kənarda görünən saxlayır, bu da routerin trafik siyasətinin, jurnalın və ya yoxlamanın yaşadığı yer olduğu halda kömək edir. Bu həm də o deməkdir ki, routerin 10.70.0.0/24 üçün 172.16.40.10 ünvanına işarə edən qayıdış marşrutuna, üstəlik həmin prefiksi həqiqətən əhatə edən internet siyasətinə ehtiyacı var; LAN alt şəbəkəsi üçün yazılmış qayda hovuza səssizcə uzanmır.

Bunu kənar cihaz nəzərdə tutulan siyasət sahibi olduqda və marşrut və tərcümə cədvəllərində başqa bir prefiksi qəbul edə bildikdə seçin. Hovuzun yuxarıda görünməz qalması lazım olduqda və routeri eyni komanda idarə etmədikdə server tərəfində tərcüməni seçin. Heç bir seçim müştəridəki hər hansı işarələmə qutusundan irəli gəlmir və heç biri ümumiyyətlə daha təhlükəsiz deyil; onlar görünürlüyü və texniki xidməti müxtəlif yerlərə qoyur.

DNS, IPv6 və qəbulu açıq edin

Ünvan tərcüməsi ad həllini düzəltmir. Müştəri VPN profili ilə verilən həlledicidən, müəyyən ad məkanları üçün özəl həlledicidən və ya təsdiqlənmiş ictimai həlledicidən istifadə edə bilər və həmin siyasət altında əlçatmaz həlledici marşrutlaşdırma işlədikdən sonra da uğursuz olmağa davam edəcək. Adı və ünvanı ayrı-ayrılıqda yoxlayın ki, iki nasazlıq heç vaxt bir hesabatda birləşməsin.

IPv6 dizaynda öz abzasına ehtiyac duyur. İşləyən IPv4 tərcüməsi IPv6 müştərilərinin marşrutu, etibarlı ictimai mənbəyi və ya tunel düşdükdə onları bloklayan siyasəti olub-olmadığı barədə heç nə demir. Bunu deyilməmiş qoymaq müştərilərin yarısının şlüzü səssizcə yan keçməsi, digər yarısının isə işləməsi deməkdir.

Qəbul üçün icazə verilən bir müştəri sorğusunu və onun cavabını hər iki sərhəd boyunca izləyin və hər sərhədin o anda görməli olduğu ünvanı yazın. Məhz bu qeyd növbəti hovuz dəyişikliyini itkin qayıdış marşrutuna kimin sahib olduğu barədə mübahisə əvəzinə beş dəqiqəlik düzəlişə çevirir. Qeydi bilet yerinə müştəri profili ilə saxlayın, çünki növbəti mühəndisin ilk tapacağı şey profildir.