Ofis VPN-inə qoşulursunuz, nişan işarəsi yaşıl olur, intranet açılır və iki metr aralıdakı printer cavab verməyi dayandırır. Bu səhər işləyən paylaşım həmin maşında vaxt aşımına uğrayır, heç bir jurnalda printerdən söz düşmür. İlk refleks DNS-dir, çünki həll olunmayan ad mövcud olmayan ada bənzəyir, amma problem ünvandadır: indi iki adapter 192.168.1.0/24 üzərində iddia edir və bu prefiksi yalnız bir marşrut qazana bilər. Bu ardıcıllıqla izləyin və heç nəyi dəyişməzdən əvvəl hansı adapterin onu aldığını görəcəksiniz.

Simptomdan başlayın, tuneldən deyil

İpucu əhatə dairəsidir. İntranet işləyirsə və bütün yerli cihazlar uğursuz olursa, tunel sağlamdır, yerli yol deyil. Yerli cihazlar işləyirsə və intranet uğursuz olursa, əksi doğrudur. Bir hostdan başqa hər şey işləyirsə, iki tərəfdə də mövcud olan bir ünvanla üz-üzəsiniz.

Hər hansı parametrə toxunmazdan əvvəl bir yerli və bir uzaq ünvanı yazın. “Printer” yoxlanıla bilən deyil; 192.168.1.40 yoxlanıla biləndir. Bu bir addım bu problemdə ən çox itirilən saatın qarşısını alır: marşrut qərarı üçün DNS parametrlərini yenidən yazmaq.

Addım 1: prefiksi iddia edən hər iki adapteri görün

Şəbəkə Bağlantıları-nı (ncpa.cpl) açın və iki adapteri yan-yana oxuyun. Ethernet adapteri 192.168.1.50/24 ünvanını 192.168.1.1 şlüzü ilə göstərir. VPN adapteri server tərəfindən ötürülən 192.168.1.201/24 ünvanını göstərir. Hər ikisi qanunidir, hər ikisi prefiksin on-link olduğuna inanır və stek onun üçün tək marşrut saxlayacaq.

Get-NetIPAddress -AddressFamily IPv4 ünvanları sadalayır, Get-NetIPInterface | Sort-Object InterfaceMetric isə stekin onlardan hansı sıra ilə istifadə edəcəyini göstərir. Həmin metrik sütunu oxumaq üzrə olduğunuz qərardır, ona görə rəqəmləri yadda saxlamağa çalışmaq əvəzinə qeyd edin.

DNS nəzəriyyəsinin yanlış olduğunu ucuz yolla sübut edin: Resolve-DnsName printer.office.lan dünən qaytardığı ünvanı qaytarır. Ad həll olundu; paket sonra səhv adapterdən çıxdı. Burada iki dəqiqə resolver parametrlərində bir gün yarısına qənaət edir.

Addım 2: həqiqətən qazanan marşrutu oxuyun

Find-NetRoute -RemoteIPAddress 192.168.1.40 stekin həmin ünvan üçün istifadə edəcəyi interfeysi, növbəti hoppu və mənbəni çap edir. Bu çıxışı işarə kimi deyil, cavab kimi qəbul edin. Hansı qeydin uduzduğunu və nə qədər uduzduğunu görmək istədikdə route print -4 bütün cədvəli verir.

Dəqiqlik niyyəti üstələyir. Ötürülən 192.168.0.0/25 yerli 192.168.0.0/24-ü məğlub edir, çünki prefiks daha uzundur, ona görə 192.168.0.0-dan 192.168.0.127-yə qədər tuneldən çıxır, yuxarı yarısı isə yerli qalır. Bir LAN yarısının xəta mesajı olmadan yox olması həmin cədvəl üçün düzgün davranışdır.

tracert -d 192.168.1.40 bunu cədvəldən kənardan təsdiqləyir: əgər ilk hopp öz routeriniz əvəzinə tunel ünvanıdırsa, marşrut bütün hekayədir. Linuxda eyni sual ip route get 192.168.1.40-dır və mənbə ünvanını cihazla bir sətirdə çap edir. Cavab tun0 adlandırdıqda brauzerə baxmağı dayandırın.

Addım 3: müştərini günahlandırmazdan əvvəl geri dönüş yolunu yoxlayın

Düzgün irəli marşrut uzaq tərəf cavab verə bilmirsə yenə də uğursuz olur. Müştəri LAN-ına tuneldən çatıldıqda, LAN şlüzü tunel hovuzunun harada olduğunu bilməlidir: həmin routerdə ip route add 10.8.0.0/24 via 192.168.1.12, və müştərilər əksi bilsin deyə serverdən push “route 192.168.1.0 255.255.255.0”.

Birinci qeyd olmadan cavab hədəfi standart şlüzünə doğru tərk edir, o da xüsusi ünvanı provayderə ötürüb atır. Simptom birtərəflidir və asanlıqla səhv oxunur: sorğular tun0-da görünür, cavablar heç vaxt.

VPN hostunda masquerade qaydası o statik marşruta ehtiyacı aradan qaldırır: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. O, həm də əsl mənbə ünvanlarını gizlədir və bu, hər sonrakı jurnal sualını çətinləşdirir. Səhv standart şlüzü olan hədəf host eyni sükutu yaradır: ən yaxşı halda ICMP yönləndirməsi, normal halda qara dəlik, buna görə də tutma hər iki tərəfdə aparılmalıdır.

Addım 4: birlikdə yaşaya biləcəyiniz bir təmir seçin

Bunun üçün beş təmir istifadə olunur və onlar bir-birini əvəz etmir. Hansı komandanın ən qısa olduğuna görə deyil, eyni vaxtda nəyin əlçatan qalmalı olduğuna görə seçin.

RepairWhat it fixesWhat it costs
Flip interface metricsAlternating access: office now, home later, never bothGet-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it
Renumber one sideEvery host reachable in both directionsDHCP reservations, printer queues, firewall rules and hard-coded addresses all move
Narrow the advertised prefixRemote hosts really live in the upper halfBreaks the day someone adds a host below the cut
Translate with client-natBoth address plans stay untouchedStateless per-client mapping, unreadable logs, anything embedding addresses breaks
Publish one service with DNATOne service on the VPN host reachable from the LANBoth address plans stay; source addresses and reverse lookups stop being meaningful

Metriklər ucuz variantdır və insanların ilk əl atdığı yoldur. Dəyişiklik interfeysə aiddir, ona görə tunel açıqkən işləyir və unudacağınız bir shell-də deyil, müştərinin yanındakı skriptdə yer almalıdır. O, iki şəbəkədə eyni ünvana eyni vaxtda giriş verə bilmir və başqalarını cədvəlin aşağısına göndərən hədd məhz budur.

Ev LAN-ının yenidən nömrələnməsi 10.10.0.0/24-ə təmiz həlldir: bir DHCP icarəsinin yenilənməsi üstəgəl köhnə aralığı qeyd edən rezervasiyalar, printer növbələri və sərt kodlanmış ünvanlar. Ofis tərəfinin yenidən nömrələnməsi adətən sizin qərarınız deyil. IPv6 hər iki şəbəkə daşıdıqda toqquşmanı tamamilə aradan qaldırır, yadda qalan bir şey əvəzinə fd00::/8-dən unikal yerli prefiks istifadə edir, amma tətbiqi ping ilə deyil, TCP üzərində sınayın, çünki xidmət işləməyəndə ICMP işləyə bilər.

OpenVPN-in öz tərcümə seçimi son çarədir və serverdən müştəriyə xas qovluq qeydinə ötürülür. Seçim adından sonra dörd parametr alır — istiqamət, şəbəkə, netmask və ləqəb — və ləqəb məcburidir: push "route 192.168.2.0 255.255.255.0" və push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Şəbəkə və netmask müştərinin gördüyü aralıqdır (192.168.2.0/24), ləqəb server tərəfindəki əsl ofis aralığıdır (192.168.1.0/24), ötürülən marşrut isə həmin görünən aralığı əlçatan edən şeydir. Sonra ofis həmin müştəriyə 192.168.2.x altında görünür. Xəritələməni profildə sənədləşdirin, yoxsa növbəti şəxs onu marşrut xətası kimi araşdıracaq.

Tək xidmətin yayımlanması tərcümənin dar variantıdır və OpenVPN seçiminə heç ehtiyac duymur. VPN hostundakı DNAT qaydası bir portu yenidən yayımlayır, beləliklə LAN ünvanlarını saxlayır və xidmətə artıq bildiyi host ünvanı ilə çatır. Xərc adi biridir: xidmət mənbə kimi VPN hostunu görür, ona görə müştəri üzrə jurnallar və əks axtarışlar mənasını itirir. Bu, bir printer növbəsini və ya bir idarə səhifəsini əhatə edir, iki tərəfdəki hostların bir-birinə çatmasını yox.

Hələ də işləməyəcək şeylər və nəyi qeyd etmək lazımdır

Yayım (broadcast) marşrutlanmış tuneldən keçmir. DLNA, UPnP, NetBIOS gəzintisi və Wake-on-LAN tun cihazının daşımadığı yayıma və ya multicast-a bağlıdır, ona görə heç bir marşrut kəşfi düzəltmir. dev tap ilə körpüləmə seqmenti, onunla birlikdə DHCP yayımlarını, ARP-ni və hər digər kəşf paketini genişləndirir; uzaq routerin LAN tərəfi ünvanı üçün route 192.168.2.1 255.255.255.255 kimi unicast host marşrutuna üstünlük verin.

Eyni yolda 192.168.1.1 istifadə edən iki router eyni problem ailəsinə aiddir: yerli ünvan həmişə qazanır, ona görə bir LAN köçənə qədər uzaq routerin səhifəsi əlçatmaz qalır. İkinci adapter əlavə etmək hər iki halda heç nəyi dəyişmir.

Nəyisə redaktə etməzdən əvvəl sübutları qeyd edin: ip route get və ya Find-NetRoute, sözügedən ünvana ping -c 3, traceroute, və müştəridə tcpdump -ni tun0 icmp, sonra serverdə marşrut cədvəli və NAT sayğacları. Bir istiqamətdə işləyib digərində ölən ping tunelə deyil, geri dönüş yoluna işarə edir və məhz bu fərq yuxarıdakı təmirlərdən hansına həqiqətən ehtiyacınız olduğunu müəyyən edir.

Əlaqəli məqalələr