bypass-dhcp OpenVPN marşrut planına əslində nə əlavə edir
Bu bayraq tuneldən kənarda olan DHCP serverinə bir host marşrutu quraşdırır. Bu, internet yönləndirməsi, DNS siyasəti, IPv6 əhatəsi və ya mobil şəbəkə düzəlişi deyil.
redirect-gateway def1 bypass-dhcp daşıyan profil IPv4 defoltunun dəyişdirilməsini bir dar istisna ilə birləşdirir. İnsanlar son sözü oxuyub mobil bağlantılar üçün ümumi həll gözləyir, sonra bayrağın heç vaxt dəstəkləmədiyi DHCP nəzəriyyəsi üzərində bir günorta keçirirlər. Hər hissə bir iş görür və istisna öz reputasiyasından qat-qat kiçikdir.
Yalnız mobil şəbəkədə baş verən nasazlığı ünvan təyinetməsinə bağlamazdan əvvəl bayraqları ayrı-ayrılıqda nəzərdən keçirin. Bu sətrin iki yarısının bir-biri ilə heç bir əlaqəsi yoxdur.
İki bayraq, iki əlaqəsiz iş
def1 ilə klient artıq mövcud olan defoltu dəyişdirmək əvəzinə iki IPv4 yarımdefoltu əlavə edir. 0.0.0.0/1 ünvan fəzasının aşağı yarısını, 128.0.0.0/1 isə yuxarı yarısını əhatə edir, buna görə birlikdə hər təyinat yerinə çatırlar və hər biri 0.0.0.0/0-dan daha dəqiq qalır. Beləliklə, ilkin defolt həmin axtarışları qazanmadan cədvəldə qalır və bu, klientin açıq şəkildə marşrutlaşdırdığı hər şey üçün köhnə şlüzü əlçatan saxlayır. Həm də cədvəldə iki üst-üstə düşən defolt qalır, buna görə marşrut çıxarışı profilin təklif etdiyindən daha qəribə görünə bilər.
bypass-dhcp ayrıdır və defolta ümumiyyətlə toxunmur. OpenVPN 2.6 təlimatı onu yerli altşəbəkədə olmayan DHCP serverinə birbaşa marşrut əlavə etmə kimi sənədləşdirir, beləliklə icarə trafiki tuneldən kənara çıxır, və davranışın Windows klientlərində tətbiq olunduğunu, başqa yerdə mövcud olmaya biləcəyini qeyd edir.
Onun mövcudluğunun səbəbi mexanikidir. Yarımdefoltlar gedən trafiki tutduqdan sonra fiziki şəbəkədəki serverə yönəlmiş DHCP yenilənməsi, nə isə həmin ünvanı real interfeysə bağlamasa, tunelin içinə yönləndirilərdi. Bayraq onu bağlayır.
İstisnanın həqiqətən əhatə dairəsi
Uğurlu bağlantıdan sonra nümunəvi cədvəl formasını göstərir: tuneldən keçən iki yarımdefolt və fiziki şlüzdən keçən DHCP serveri üçün bir host marşrutu. Onu öz ünvanlarınız kimi deyil, forma kimi oxuyun.
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0
192.168.1.1/32 via 192.168.1.254 dev wlan0Üçüncü sətir bir təyinat yerini adlandırır. Bu, rezolver ayarı deyil, yerli şəbəkə üçün ümumi icazə deyil və serverdə çıxış qaydası deyil. Mobil daşıyıcıdakı telefonun klientin bu şəkildə müəyyən edə biləcəyi DHCP serveri olmaya bilər, buna görə bayraq orada heç nəyi dəyişmir.
Klientin həqiqətən nə quraşdırdığını yoxlayın
Profildə yazılmış seçimi, serverin təklif etdiyi seçimi və bağlantı sahibinin faktiki tətbiq etdiyi marşrutu fərqləndirin. Dəstəklənməyən bayrağı rədd edən klient konfiqurasiyanın qalan hissəsini saxlaya bilər, yəni tunel qalxır və istisna sadəcə yoxdur. Fayldakı sətrin qüvvəyə mindiyini güman etmək əvəzinə klientin öz jurnalını və nəticədə yaranan marşrut cədvəlini oxuyun. Bunlardan üçü eyni vaxtda doğru ola bilər və yalnız sonuncusu paketlərin həqiqətən hara getdiyini dəyişir.
Eyni zamanda VPN son nöqtəsinə marşrutu işlək saxlayın. Bu son nöqtə istisnası DHCP istisnasından fərqli bir tələbdir və onsuz tunel onu saxlayan nəqliyyatı tuta bilər.
Tətbiq təyinatı üçün uğursuzluq baş verən kontekstdə effektiv axtarışı yoxlayın. Daha dəqiq yerli marşrutlar, siyasət marşrutlaşdırması və hər tətbiq üzrə istisnalar cavabı dəyişir, buna görə iki yarımdefoltun olması hər axının siyahısı deyil.
Yolun qalan hissəsi bu bayraqda deyil
Server hələ də klientin internet trafikini yönləndirmək üçün icazəyə və onu geri qaytara bilən çıxış təşkilinə ehtiyac duyur. Klient tərəfindəki heç bir marşrut serverdə çatışmayan yönləndirmə və ya mənbə çevrilməsi yaratmır və heç bir bayraq işlək qayıdış yolunu əvəz etmir.
Ad həlli və IPv6 hər biri öz siyasətinə ehtiyac duyur. IPv4 dəyişdirməsi rezolveri tunel tərəfindəki serverə yönəltmir və IPv6 əhatəsi yaratmır; yalnız v4-ü yönləndirən klient v6 yolunu toxunulmaz qoyur.
Profil və təyinat sabit qalmaqla bir icazəli zərərsiz sorğunu işlək və nasaz giriş yolu üzərində müqayisə edin. Fərqin ad həllində, tunelin qurulmasında, marşrut seçimində yoxsa yönləndirilmiş trafikdə olduğunu qeyd edin və cavabı profillə birlikdə saxlayın. Bu qeyd növbəti şəxsin DHCP-ni çata bilmədiyi problemdə günahlandırmasının qarşısını alan şeydir.