LAN ünvanlı VPN klienti LAN-da deyil
VPN klientinə LAN ünvanı vermək onu həmin seqmentə qoymur. Yerli hostlar qonşu sorğusu göndərir, ona görə şlüz cavab verməlidir, əks halda cavab heç vaxt çatmaz.
Klient qoşulur, 10.50.0.200 alır və hər iki nömrə eyni /24-də olsa da, 10.50.0.20-dəki serverə çata bilmir. Bu konfiqurasiyanın arxasındakı inam budur ki, LAN prefiksindən götürülmüş ünvan klienti LAN-ın bir hissəsi edir. Etmir. Klient nöqtədən-nöqtəyə keçid üzərindədir, server təyinatı yerli hesab edir və çatışmayan hissə heç kimin göndərmədiyi qonşu cavabıdır.
Mif: eyni prefiks eyni seqment deməkdir
Ünvan prefiksi hosta hansı təyinatların birbaşa çatıla bildiyini və hansıların marşrutlaşdırıcı tələb etdiyini bildirir. O, hosta təyinatın fiziki olaraq necə qoşulduğunu demir və təyinatın kanal qatı sorğusuna cavab verə biləcəyinə heç bir zəmanət vermir. Bunlar hostdakı müxtəlif cədvəllərin cavab verdiyi fərqli suallardır. Mask birinciyə, qonşular cədvəli ikinciyə cavab verir və yalnız birincisi VPN tərəfindən sizin nəzarətinizdədir.
Server 10.50.0.200-ə göndərəndə təyinatı öz maskası ilə müqayisə edir, ünvanı on-link hesab edir və yerli seqmentdən ona məxsus aparat ünvanını soruşur. Bu sorğu Ethernet interfeysindən çıxır və VPN klienti onu eşitmək üçün orada deyil.
Klientin konfiqurasiyasında heç nə bunu öz tərəfindən düzəldə bilməz. Cavab yolu LAN-da olan bir cihazın klient adından cavab verməsindən və ya klientin serverin yerli hesab etmədiyi bir ünvana sahib olmasından asılıdır.
Yerli host ünvanla həqiqətən nə edir
Davranışı müşahidə etmək asandır və nəyisə dəyişməzdən əvvəl buna baxmağa dəyər. LAN hostunda klientə çatmağa cəhd etdikdən sonra qonşular cədvəlinə baxın: natamam və ya uğursuz qeyd bir sətirdə bütün diaqnozdur. Həmin sətir sizə nasazlığın tunelin içində deyil, seqmentin yerində olduğunu da deyir.
ip neigh show 10.50.0.200 ip route get 10.50.0.200 arping -I eth0 -c 3 10.50.0.200
Marşrut axtarışı təyinatı Ethernet interfeysi vasitəsilə on-link kimi göstərəcək və problem məhz budur. VPN sessiyası işləyərkən qonşu qeydi natamam qalırsa, siz çatışmayan hissənin marşrutlaşdırma və ya firewall siyasəti deyil, kanal qatı həlli olduğunu təsdiqləmisiniz.
Eyni yoxlamanı başqa subunetdəki hostdan aparın və müqayisə edin. Klientə marşrutlaşdırıcı vasitəsilə çatan hostun qonşu qeydinə ümumiyyətlə ehtiyacı yoxdur və bu fərq dizayn qərarının kiçik ölçüdə ifadəsidir.
Proxy ARP növbəti hopu necə təmin edir
Proxy ARP şlüzün başqa interfeys vasitəsilə çata bildiyi təyinat adından kanal qatı sorğusuna cavab verməsini təmin edir. LAN hostu aparat ünvanı alır, kadrı şlüzə göndərir və şlüz paketi VPN sessiyasına ötürür. Hostun baxışından klient sadəcə şlüzün arxasında görünür. Klientin konfiqurasiyasında heç nə dəyişmir.
MikroTik-in RouterOS ARP sənədləri qoşulmuş LAN-ın ünvan məkanını borc alan dial-in klientlər üçün bu istifadəni təsvir edir. Mexanizm qonşu həllinin düzəlişidir və işləyir, çünki şlüz həqiqətən hər iki yoldadır.
Bu, klienti LAN-a körpüləməklə eyni şey deyil. Şlüz hələ də paketi düzgün aktiv sessiyaya ötürməlidir və onun marşrutlaşdırma və firewall siyasəti hələ də xidmətə icazə verməlidir. Proxy ARP qonşu sorğusuna kimin cavab verdiyini dəyişir, kimin danışmağa icazəli olduğunu yox.
Platformanın rejim adlarını diqqətlə oxuyun. RouterOS proxy-arp ilə local-proxy-arp-i ayırır və ikincisi eyni interfeysə girən və ondan çıxan trafiki idarə edir. Bunlar bir-birini əvəz edən yazılışlar deyil və hər ikisini fərq qoymadan aktivləşdirmək qısa yol deyil.
Proxy ARP sizə nə vermir
O, broadcast və ya multicast kəşfini təmin etmir. Xidməti broadcast ilə tapmalı olan klient yenə də uğursuz olacaq, çünki şlüz unicast-ı sessiyaya ötürür və klienti LAN-ın broadcast domeninin üzvü etmir. Broadcast-a güvənən kəşf protokolları borc alınmış ünvan dizaynlarında «bir şey üçün işləyir, digəri üçün yox» hesabatlarının adi mənbəyidir.
O, ünvanı rezerv etmir. Əgər borc alınan nömrə həm də DHCP hovuzunda və ya statik təyinatda varsa, iki cihaz eyni ünvanla qala bilər və nəticədə davranış vaxtdan asılı olur. Uğurlu giriş rezervasiya deyil.
Və o, LAN-ın sahibi ilə koordinasiya ehtiyacını aradan qaldırmır. Ünvan planının sahibini təəccübləndirən Proxy ARP qeydi sakit həftə gözləyən dəstək hadisəsidir.
Ayrıca marşrutlanan hovuzla müqayisə
Alternativ VPN klientlərinə öz prefikslərini vermək və LAN hostlarının ora marşrutlaşdırmasına imkan verməkdir. Sonra server öz şlüzünə off-link cavablar göndərir, şlüz prefiksi VPN son nöqtəsinə marşrutlaşdırır və LAN seqmentində qonşu həllinə heç ehtiyac qalmır. Bu, borc alınmış ünvan üstəgəl proxy cavabından daha az hərəkət edən hissədir.
Bu dizayn haqqında düşünmək və audit etmək daha asandır, çünki klient diapazonu LAN diapazonundan görünən şəkildə ayrıdır. O, bir marşrut, bir qayıdış yolu və bir giriş qaydası bahasına başa gəlir — proxy ARP dizaynının daha az aydın yerdə ehtiyac duyduğu eyni şeylər.
Modellər arasında təsadüfən deyil, qəsdən seçim edin. Proxy ARP bir konkret əlaqəni təmir edir; marşrutlanan hovuz bu təmirə ehtiyacı aradan qaldırır. Hansını seçdiyinizi və niyə seçdiyinizi yazın, qoy növbəti adam bunu uğursuz qonşu qeydindən yenidən kəşf etməli olmasın.