OpenVPN üzərindən iki lövhə arasında təcrid olunmuş TAP körpüsü
Körpü kadrları üzv portlar arasında ötürür, host ünvanı isə körpünün özünə aiddir. İdarəetməni ifşa etmədən stend portlarını qoşun.
İki inkişaf lövhəsi bir Ethernet seqmentini paylaşmalıdır, halbuki onların stendləri fərqli binalarda yerləşir. Tunel artıq mövcuddur və artıq Ethernet daşıyır, ona görə qalan iş üç əmrdən ibarət görünür və heç də elə deyil. Hostun körpülənmiş kadrla nə etdiyi, kompüterin öz ünvanının hara aid olduğu və körpünün yaratmadığı sərhədin hansı olduğu üç ayrı faktdır, ikincisini səhv etmək isə laboratoriyanın fasilələrlə işləməsinin və idarəetmə girişinin səssizcə pisləşməsinin adi səbəbidir. Bu üç faktın heç biri topologiya diaqramında görünmür.
Aşağıdakı yol iki Linux kompüteri arasında autentifikasiya olunmuş TAP bağlantısını, hər stend üçün bir ayrılmış kabel portunu və eksperimentin hissəsi olmayan idarəetmə interfeysini nəzərdə tutur. Sıra vacibdir: əvvəlcə kadrlar, sonra ünvanlar, ən sonda sərhəd.
Körpü əslində nə daşıyır
Körpü proqram təminatında həyata keçirilmiş kommutatordur. Hansı MAC ünvanının hansı üzv portun arxasında göründüyünü öyrənir və IP marşrutlaşdırma cədvəlinə baxmadan kadrları üzvlər arasında ötürür. Bu təsvirdə heç bir alt şəbəkə, gateway və ya defolt marşrut yoxdur, buna görə IP ötürmənin aktivləşdirilməsi bu qoşulmanı yaratmır və buna görə ping uğurlu ola bilər, digər trafik isə yenə də uğursuz olur. Lövhə heç bir defolt marşrut qurulmadan öz həmkarına çata bilər, bu da ikinci qatın üçüncü qat kimi davranmasını gözləyənləri təəccübləndirir.
Hər kompüter körpüyə bir kabel portu və TAP cihazını eyni körpüyə verir, beləliklə lövhədən gələn kadr yerli porta daxil olur, TAP cihazına ötürülür, tuneli keçir, həmkarın TAP cihazına çatır və həmkarın lövhəsinə ötürülür. Tunel hər hansı digər üzv port kimidir və körpü arxasında VPN olduğunu bilmir və buna əhəmiyyət vermir. Bu simmetriya nümunəni asan düşünülən edir: hər tərəfin bir laboratoriyaya baxan portu və bir tunel portu var, heç bir tərəf xüsusi deyil.
Board A -- bench0 -- br-test -- tap-bench
| OpenVPN TAP
Board B -- bench0 -- br-test -- tap-benchHər iki kompüterdəki eyni adlar yerli adlardır, ortaq obyektlər deyil. Stendlər arasında bir Ethernet yolu var, ikinci kabel və dövrəni bağlayan ikinci tunel yoxdur; eyni MAC-ın iki porta gəldiyini görən körpü məmnuniyyətlə dairələrlə ötürəcək.
Körpünü ünvanlayın, onun üzv portlarını deyil
Kompüterin laboratoriya seqmentindəki kimliyi körpü cihazına aiddir. Üzv portlar ünvansız qalır, çünki port ötürücü üzvdür və üzərindəki ünvan eyni seqmentin ikinci, rəqib sahibini yaradar. Əl ilə yazılmış reseptlərin çoxunun səhv etdiyi düzəliş budur: onlar TAP cihazını və körpünü ünvanlayır, sonra həmkarın əslində hansına çatdığını soruşurlar.
ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test upHəmkar fərqli host ünvanı ilə eyni formanı istifadə edir, lövhələr isə ehtiyac olduqda kompüterin körpü ünvanını növbəti hop kimi götürərək eyni diapazonda ünvanlar alır. Plan razılaşdırılana qədər sənədləşdirmə diapazonlarından istifadə edin və diapazonu rezerv edin ki, ofisin artıq marşrutlaşdırdığı heç nə ilə toqquşmasın. Hər hansı birini işə salmazdan əvvəl təsdiqləyin ki, üzv portlarda qalıq ünvan, DHCP müştərisi və başqa körpüdə üzvlük yoxdur, və TAP cihazının ünvanlanmasını tunel konfiqurasiyasına sahib olan vasitə ilə uyğunlaşdırın ki, sonradan ünvanı bərpa etməsin.
Niyə hər stend üçün bir ayrılmış port
Ayrılmış kabel portu eksperimentin ofis miqyaslı dəyişikliyə çevrilməsinin qarşısını alan şeydir. İdarəetmə interfeysi SSH, defolt marşrut və xarici VPN bağlantısını daşıyır və bunların heç biri məqsədi laboratoriya kadrlarını daşımaq olan körpüyə aid deyil.
İdarəetmə adapterini qoşmaq ofis LAN-ını bir ötürmə qərarı məsafəsində inkişaf lövhəsindən uzaqlaşdırır və ikinci qatda pis davranan lövhə məhz o seqmentdə istəmədiyiniz cür cihazdır. Wi-Fi adapteri daha pisdir: simsiz interfeysi infrastruktur rejimində körpüləmək Ethernet körpüləməsi kimi davranmır və uğursuzluq təmiz deyil, çaşdırıcıdır.
Laboratoriya diapazonunu istənilən istehsal DHCP əhatəsindən kənarda saxlayın. Əgər lövhələr sonradan dinamik ünvanlama tələb edərsə, bir səlahiyyətli paylayıcının bir hovuzla işləməsi proqnozlaşdırıla bilən qalan yeganə tənzimdir; iki saytın adi marşrutlaşdırıcılarının eyni seqmentdə cavab verməsi heç kimin izah edə bilmədiyi ünvanlar yaradır.
Körpünün yaratmadığı sərhəd
Körpüləmə marşrutlaşdırma deyil və o, həmçinin təcrid deyil. Körpünü keçən kadrlar hələ də hostun filtrləmə qarmaqlarına çata bilər, bu quraşdırılmış körpü-netfilter yolundan asılıdır, ona görə effektiv siyasət fərz edilməməli, yoxlanmalıdır. Bir kadr itdiyi üçün firewall-u söndürmək konkret xətanı ümumi xəta ilə dəyişir.
Körpü ilə hər idarəetmə və ya yuxarı bağlantı interfeysi arasında IP ötürmə söndürülməli və ya açıq şəkildə rədd edilməlidir və bu, körpü üzvlüyündən ayrı bir nəzarətdir. Kompüterin laboratoriya ünvanını gateway kimi seçən lövhə məhz bunu sınaqdan keçirir: əgər idarəetmə tranziti uğurludursa, nəzərdə tutduğunuz sərhəd heç vaxt orada olmayıb.
Daha iki ailə açıq qərarə layiqdir. Ünvan planı körpünü yalnız IPv4 etmir, ona görə IPv6 və digər EtherType-lar öz planına və ya filtrinə ehtiyac duyur. Uğurlu ping isə lövhənin kəşf yayımlarının, multicast qruplarının və ya jumbo kadrlarının yoldan keçib-keçməyəcəyi barədə heç nə demir, çünki bunlar fərqli defoltlara malik fərqli trafik sinifləridir.
Nəhayət, nəql və məxfilik fərqli alışlardır. TAP Ethernet daşıyır; OpenVPN xidməti ətrafındakı qorumayı təmin edir. VXLAN örtüyü də Ethernet daşıyır və öz-özlüyündə heç bir məxfilik təmin etmir, ona görə birini digəri ilə əvəz etmək topologiya diaqramı eyni görünsə belə təhlükəsizlik xassələrini dəyişir.
Davamlılıq və bunu sübut edən testlər
Qoşulduqdan sonra bir dəfə yazılan əmr konfiqurasiya deyil. Körpünü, port üzvlüyünü və tək host ünvanını kompüterin mövcud şəbəkə meneceri vasitəsilə davamlı edin və qoşulmanı TAP cihazının görünməsinə bağlayın ki, yenidən qoşulma üzvü yoxa çıxmış körpü qoymasın.
bridge link show
ip -d link show br-test
bridge fdb show br br-test | headSonra lövhələrin hər iki istiqamətdə həqiqətən nəyə ehtiyacı olduğunu sınayın, tuneli yenidən qoşun və bir kompüteri təsdiqlənmiş bərpa planı ilə yenidən başladın. Sonra üç şeyi təsdiqləyin: idarəetmə girişi hələ də müstəqil işləyir, təkrar laboratoriya ünvanı görünmür və gözlənilməz istehsal interfeysi körpüyə qoşulmayıb. Bu birləşmə eksperimentin öz stendində qaldığının sübutudur.