RRAS VPN müştərilərinə öz IPv4 hovuzu və geri yol lazımdır

VPN müştərisi qoşulur və ünvan alır, lakin ona lazım olan LAN hostu yenə də cavab verə bilmir. Windows Routing and Remote Access-də VPN müştəriləri üçün daxili ünvan serverin LAN adapterindən ayrıca konfiqurasiya olunan hovuzdan gəlir və LAN tərəfinə həmin hovuza geri marşrut lazımdır. İki dəyişiklik, bir deyil, və onlar fərqli şəkildə sıradan çıxır. Köhnə aralıqlar istifadədən çıxarılmazdan əvvəl ünvan planı və geri yol sübut olunsun deyə onları ardıcıllıqla işləyin.

Konsolu açmazdan əvvəl aralığı ayırın

LAN ilə, digər VPN aralıqları ilə və sayta marşrutlanan hər şeylə üst-üstə düşməyən prefiks seçin. /24 test üçün əlverişli ölçüdür və ilk istifadə oluna bilən hissə müştərilərə verilə, qalanı isə artım üçün sərbəst qala bilər. Konsola yazmazdan əvvəl onu məqsədi və sahibi ilə birlikdə qeyd edin. Sonrakı bölünmə yenidən nömrələməni məcbur etməsin deyə blokun hər iki ucunda yer saxlayın.

Yalnız konsolda yaşayan ünvan planı bir yenidənqurma qədər toqquşmadan uzaqdır. O, həm də böyüməyə meyllidir: kimsə sonra ikinci aralıq əlavə edir və heç kim birincisini yoxlamır. Planı server sənədlərinin yanında saxlayın, söhbət zəncirində deyil.

Serverin LAN adapteri bu hovuzu təyin etmir. İctimai dinləyicini dəyişmək və ya LAN-a adapter əlavə etmək tamamilə başqa bir şey edir. Buna görə müştərilər qoşula və yenə də səhv yerdən ünvan ala bilərlər. Hovuz serverin IPv4 xassələrində yaşayır, adapter siyahısında deyil.

Metodu dəyişmək aralıq əlavə etmək deyil

RRAS-ın təyinetmə metodu və aralıqlar dəsti var. DHCP-dən statik hovuza keçmək metod dəyişikliyidir. Statik hovuz artıq aktivkən başqa blok əlavə etmək aralıq dəyişikliyidir.

Hər ikisini işə salmazdan əvvəl önizləyin və hansının serverin cari vəziyyətinə uyğun olduğunu oxuyun:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Server hələ DHCP təyinatındadırsa, ikinci cmdlet uğursuz olur və ya yararsız hovuz yaradır. Birincisi mövcud hovuzu genişləndirmək əvəzinə metodu əvəz edir. Heç bir önizləmə heç nə tətbiq etmir, ona görə uyğun olanı işə salın, sonra yaranan hovuzu konsolda təsdiqləyin. Serverin hansı vəziyyətdə olduğuna əmin deyilsinizsə, IPv4 xassələri səhifəsində təyinetmə metodunu oxuyun və konfiqurasiya edilmiş aralıqları siyahıya alın:

Get-VpnIPAddressRange

DHCP metodu və boş aralıq siyahısı birinci önizləmənin tətbiq olunduğunu bildirir. Mövcud aralığı olan statik ünvan hovuzu ikincinin tətbiq olunduğunu bildirir.

Parametrin tələb edə biləcəyi xidmət yenidən başlamasını nəzərə alın və qoşulmuş müştərilərin dərhal yenidən nömrələndiyini güman etməyin. Yenidən qoşulana qədər köhnə ünvanını saxlayan müştəri normal davranır. Dəyişikliyi yenidən qoşulmanın məqbul olduğu pəncərə üçün planlaşdırın.

LAN-a geri marşrut lazımdır

Tutaq ki, LAN 10.60.0.0/24, RRAS serveri isə onun üzərində 10.60.0.10-dur. Həmin LAN-dakı və 10.250.50.0/24-dəki müştəriyə cavab verən hostun RRAS serveri vasitəsilə hovuza yol lazımdır. Bu yol olmadan sorğu çatır və cavab ölür.

Hostun standart şlüzü başqa routersə, həmin routersə VPN prefiksi üçün geri marşrut lazımdır. RRAS serverində statik marşrut burada kömək etmir; geri yol LAN şlüzünə sahib cihazda mövcud olmalıdır, ona görə onu marşrut cədvəlinə və ya dinamik marşrutlaşdırma prosesinə əlavə edin, sayt hansını istifadə edirsə.

Hostun firewall və istənilən şəbəkə giriş qaydalarını yeni mənbə aralığına qarşı da yoxlayın. Köhnə müştəri aralığı üçün yazılmış qaydalar təyinat uğurlu olsa da yenini rədd edir. Müştəri marşrutları LAN-a doğru və DNS həlli ayrı tələblərdir və tunel sağlam görünərkən hər ikisi sıradan çıxa bilər. Hər birini ayrıca sınayın.

Köhnəni istifadədən çıxarmazdan əvvəl yeni hovuzu bir cihazda sübut edin

Nəzarət etdiyiniz bir avtorizasiya götürün, yenidən qoşulun və müştərinin aldığı hovuz ünvanını oxuyun. Həmin tək rəqəm ayırmanı marşrutlaşdırmadan ayırır. Sonra adlı tətbiqi işə salın, geri trafiki izləyin və rədd olunmalı qalan hədəfi sınayın. Üç müşahidə, üç fərqli nasazlıq rejimi.

Ad həlli öz testini haqq edir: IP ilə giriş işləyə bilər, halbuki müştərinin DNS-i hələ çata bilmədiyi rezolverə işarə edir. LAN-dakı DNS serverinə yalnız müştərinin ona marşrutu varsa və server yeni aralıqdan sorğuları qəbul edirsə çatmaq olar. Hovuz köçəndə hər ikisi tez-tez buraxılan məqamlardır.

Köhnə aralıqları və istisnalarını yalnız aktiv sessiyaları və texniki xidmət prosesini nəzərə aldıqdan sonra istifadədən çıxarın. Yeni ünvanı olan qoşulmuş müştəri ayırmanı sübut edir, giriş siyasətini deyil. Köhnə aralığı ondan istifadə edən son sessiya bitənə qədər sənədləşdirin.

Nəticəni üç müşahidə ilə yoxlayın

Qəbul üç fakt tələb edir: müştərinin yeni hovuzdan ünvanı var, LAN hostu ona çata və cavab ala bilir, rədd edilən hədəf hələ də rədd olunur. Hər birinin öz yoxlaması var, ona görə nasazlıq ayırmaya, marşrutlaşdırmaya və ya siyasətə işarə edir. Onları bu ardıcıllıqla işlədin.

Müştəridən ünvanı və bir LAN hostuna marşrutu təsdiqləyin:

ipconfig | findstr /i "IPv4"
route print -4

LAN hostundan cavab yolunu və siyasəti bir keçiddə təsdiqləyin. Ping uğursuz olur, amma tətbiq işləyirsə, çatışmayan hissə çox güman marşrut deyil, ICMP qaydasıdır. Hər ikisi uğursuz olursa, VPN-i redaktə etməzdən əvvəl hostdakı marşrutu oxuyun. Üç nəticəni dəyişiklik bilettinə yazın ki, növbəti şəxs sübutdan başlasın.