Marşrutlanmış və ya körpülənmiş VPN: müştərinin nəyə çatmalı olduğuna görə seçin

Eyni gündə iki bilet gəlir: bir istifadəçiyə daxili veb tətbiq lazımdır, bir mühəndisə isə stend cihazının sanki eyni Ethernet seqmentində oturmuş kimi davranması lazımdır. Hər ikisinə onları VPN-ə qoyun cavabı verilir və bəla da burada başlayır. Marşrutlanmış tunel ilə körpülənmiş tunel fərqli münasibətlər uzadır və hər sorğuya yalnız biri uyğun gəlir. Topologiyanı seçmək giriş qərarıdır, kriptoqrafiya ayarı deyil.

Bilet masasında eyni görünən iki sorğu

İşçinin tələbi sizin nəzarət etmədiyiniz cihazdan IP üzərindən çatılan xidmətdir. Mühəndisin tələbi isə kanal səviyyəsindədir: cihaz Ethernet kadrlarını və yayım kəşfini görməyi gözləyir, və bəlkə də özünü üzərində sandığı seqmentdən DHCP gözləyir.

Bunlar fərqli suallardır və hər ikisinə körpü ilə cavab vermək işçinin girişini heç bir səbəb olmadan bütün ofis LAN-ına genişləndirir.

Seçim etməzdən əvvəl tələbi bir cümlə kimi yazın: hansı təyinatlar, hansı protokollar və hansı həmkarlar yerli görünməlidir. Cavab host və portdursa, marşrutlaşdırma bunu ödəyir. Cavab yalnız yayımla danışan cihazlarla kadr səviyyəsində münasibətdirsə, körpü yeganə variant ola bilər. Arada qalan hər şey istehsal LAN-ı əvəzinə sınaq seqmentinə layiqdir.

Marşrut LAN üzvlüyündən dardır

Marşrutlanmış müştəri tunel alt şəbəkəsində ünvan və seçdiyiniz prefikslər üçün marşrutlar alır. Siyasət belə deyirsə, tətbiq serverinə çatır və başqa heç nəyə çatmır. Şlüz tətbiq nöqtəsinə çevrilir, bir şərtlə ki, hər aidiyyəti yol ondan keçsin.

Marşrutu icazə ilə qarışdırmayın. Müştəriyə alt şəbəkəyə necə çatacağını demək onu başqa təyinatı sınamaqdan saxlamır.

Giriş nəzarətini axını həqiqətən tətbiq edə biləcəyi yerdə tətbiq edin və tətbiqin öz icazələrini yerində saxlayın. Geniş yönləndirmə qaydası və ya unudulmuş ikinci interfeys diaqramın göstərdiyindən çox icazə verə bilər. Nəzərdə tutulan qaydaları deyil, qüvvədə olan qaydaları oxuyun. Sonra uğursuz olmalı olan təyinatı sınayın, çünki heç kimin pozmağa cəhd etmədiyi siyasət yalnız fərziyyədir.

Körpü qəbul sualını dəyişir

Körpüləmə fiziki interfeysi və TAP cihazını proqram kommutatorunda birləşdirir, beləliklə uzaq cihazlar eyni yayım domeninə qoşulur. Bu real imkandır və real riskdir: uzaq cihaz artıq marşrutlanmış qonaq deyil, iştirakçıdır.

Hansı cihazların qoşula biləcəyinə, hansı kadr növlərinin keçməli olduğuna və arzuolunmaz qarşılıqlı təsirin harada bloklanacağına qərar verin. Ünvanlama və DHCP səlahiyyəti ortaq şəbəkənin hissəsinə çevrilir və bir seqmentdə iki DHCP server məhz gözlədiyiniz qarışıqlığı yaradır.

Cihaz üçün xüsusi sınaq seqmenti adətən ofis LAN-ından daha uyğundur. İdarəetmə girişini təcrübədən kənarda saxlayın və iş bitdikdə müvəqqəti iştirakçının necə çıxarılacağını müəyyənləşdirin.

Filtrasiya hər iki topologiyada mövcuddur

Körpü təbiətcə filtrsiz deyil və marşrut təbiətcə təhlükəsiz deyil. Linux körpü filtrləməsinin öz qarmaqları və öz qayda sintaksisi var və marşrutlanmış IP yönləndirməsi üçün yazılmış qayda körpülənmiş kadrlara avtomatik tətbiq olunmur.

Sərhəd vəd etməzdən əvvəl platformanın həqiqətən nəyi dəstəklədiyini yoxlayın:

bridge link show
nft list ruleset

TUN və TAP şifrəni deyil, interfeysin trafikini təsvir edir. İnterfeysləri dəyişmək bunların heç birini düzəltmir: həmkar autentifikasiyası, oğurlanmış açar və köhnəlmiş kriptoqrafik siyasət dəyişiklikdən sonra da qalır. Hər iki tərəf hələ də uyğun və hələ də dəstəklənən ayarlara ehtiyac duyur.

Sərhədi üç cəhdlə sübut edin

Qəbul üç müşahidədir, diaqram icmalı deyil. Tələb olunan əməliyyat işləməlidir, əlaqəsiz təyinat uğursuz olmalıdır və şlüzün öz idarəetmə xidmətləri əlçatan olmamalıdır.

İcazə verilən və rədd edilən yolları eyni müştəridən işə salın və hər ikisini qeyd edin:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Körpü üçün kanal səviyyəli yoxlamaları əlavə edin: icazə verilən kəşf trafiki keçirmi, ünvanlama nəzərdə tutulan səlahiyyətdən gəlirmi və müvəqqəti iştirakçı çıxarıldıqdan sonra yox olubmu. Adi marşrutlanmış IP tələbi artıq ödəyirsə, ofis Ethernet seqmentinə qoşulmaq ayrıca əsaslandırma tələb edir və bu, dəyişiklikdən əvvəl yazılmalıdır.