Başqa NAT əlavə etməzdən əvvəl özəl LAN-lar arasında marşrutlaşdırma

İki daxili firewall, bir özəl tranzit seqmenti və hər LAN-da bir neçə hostun digəri ilə danışmasına icazə verilməsi xahişi. Adətən ilk reaksiya VPN qurmaq və ya ikinci NAT qatı əlavə etmək olur, hər iki refleks isə problemin dəyərindən çox başa gəlir. Üç şərt yerinə yetirildikdə adi marşrutlaşdırma kifayətdir: ünvan diapazonları üst-üstə düşmür, hər iki tərəf digər LAN-a trafik qaytara bilir və tranzit seqmenti məlumat üçün kifayət qədər etibarlıdır. Hər hansı bir şey dizayn etməzdən əvvəl bu üçünü yoxlayın, çünki hər biri cavabı dəyişir.

Dizaynı təyin edən üç şərt

Birinci şərt ünvan məkanıdır. Hər iki LAN eyni RFC 1918 blokunu istifadə edirsə, marşrutlaşdırma onları ayıra bilmir və tərcümə seçim deyil, qaçılmaz olur. İkincisi qayıdış yoludur: A-dan B-yə marşrut, B də A-nın LAN-ına necə çatacağını bilmirsə faydasızdır və asimmetrik bilik marşrutlaşdırılmış dizaynın cavabları səssizcə atmasının ən çox görülən səbəbidir.

Üçüncüsü etibardır. Marşrutlaşdırma paketləri hərəkət etdirir; onları qorumur. Bir binanın içindəki özəl tranzit seqmenti provayder qovşağından və ya ortaq kampus magistralından keçən linkdən fərqli məsələdir. Seqment etibarlı deyilsə, cavab iki firewall arasında tuneldir və aşağıdakı marşrut planı onun içində də qüvvədə qalır.

Sadə dizayn yalnız hər üçü eyni istiqamətə işarə etdikdə qazanır. Onlardan biri pozulduqda həmin şərti tərcümə ilə ört-basdır etmək əvəzinə açıq şəkildə düzəldin, çünki NAT problemi həll etmir, sadəcə gizlədir.

Marşrut planını tranzit şəbəkəsi üzərində qurun

Hər firewall-a ortaq seqmentdə ünvan verin və hər uzaq LAN üçün bir konkret marşrut əlavə edin. Mövcud konfiqurasiyada başqa heç nə dəyişməməlidir və xüsusilə internet default marşrutu tam olduğu yerdə qalmalıdır. Default marşrutu qonşu firewall ilə əvəz etmək hər əlaqəsiz təyinatı tranzitdən keçirərdi ki, bu da tələb olunandan qat-qat böyük dəyişiklikdir. pfSense statik marşrutlaşdırma sənədləri həmin platforma üçün eyni marşrut-üstəgəl-şlüz modelini təsvir edir və ekvivalent idarəetmə faktiki işlətdiyiniz hər hansı firewall-da mövcuddur.

Firewall A 10.30.0.0/24, firewall B isə 10.40.0.0/24 şəbəkəsinə xidmət edir, iki tranzit ünvanı isə 192.0.2.0/24 üzərindədir. Hər LAN hostu öz yerli firewall-unu şlüz kimi saxlayır, ona görə yeganə yeni vəziyyət hər tərəfdə bir marşrutdur. Linux əsaslı firewall-da eyni plan belə görünür və yönləndirmə aktiv olmalıdır, əks halda marşrut həll olunacaq, paket isə atılacaq.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Filtrasiyanı tərcümədən ayrı saxlayın

Marşrutlaşdırma və siyasət fərqli idarəetmə vasitələridir və əksər marşrutlaşdırılmış dizaynlar məhz ikincisində uğursuz olur. Paketlərin həqiqətən keçdiyi giriş sərhədində konkret mənbələrə, təyinat və xidmətlərə icazə verin və yadda saxlayın ki, WAN kimi interfeys adı etibar haqqında bəyanat deyil, sadəcə addır. Özəl trafik daşıyan tranzit portunda özəl ünvan bloklaması hələ də susmaya görə aktiv ola bilər.

Sonra heç bir NAT baş vermədiyi qənaətinə gəlməzdən əvvəl giden tərcüməyə baxın. Avtomatik giden qaydalar heç vaxt tərcümə üçün nəzərdə tutulmamış trafiki yenidən yaza bilər ki, bu da qarşı tərəfin öz siyasəti və qeydləri üçün lazım olan mənbə ünvanlarını məhv edir. Seçilmiş axınların orijinal ünvanlarını saxladığını təsdiqləyin və hələ də ehtiyac duyan trafik üçün internet tərcümə qaydalarına toxunmayın.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

NAT-ın dürüst cavab olduğu hal

Tərcümə o zaman yerini qazanır ki, ünvan diapazonları həqiqətən üst-üstə düşür və yenidən nömrələmə mümkün deyil, ya da siyasət bir tərəfin subnet əvəzinə tək ünvan görməsini tələb edir. Belə hallarda qəsdən birə-bir və ya portla məhdudlaşdırılmış xəritələmə nəticələri bilinən dizayn qərarıdır, hiylə deyil.

Yüksək səslə deməli olan nəticə budur ki, qarşı tərəf artıq fərdi mənbələri görə və ya filtrləyə bilmir. Qeydlər tərcümə edən ünvana yığılır, hər host üzrə siyasət işləmir və nasazlıq axtarışı verilmiş anda hansı daxili hostun axına sahib olduğunu tapmağa çevrilir. Əgər bütün bunlar sözügedən trafik üçün əhəmiyyətli deyilsə, NAT yaxşıdır.

Tranzitin özünün səhv fərziyyə olduğu hal

Ortaq seqment provayderdən, ortaq kommutasiya toxumasından və ya başqa tərəfin trafiki oxuya biləcəyi hər hansı yoldan keçirsə, təkcə marşrutlaşdırma tam cavab deyil. İki firewall arasındakı tunel sizə məxfilik və qarşı tərəfin autentifikasiyasını verir və onun içindəki marşrut cədvəli tranzitdə yazacağınız cədvəlin eynisidir.

Buna birinci bölmədəki etibar sualından çıxış edərək qərar verin, VPN-lərin daha təhlükəsiz olması vərdişindən deyil. Artıq özəl olan seqment üzərində tunel heç bir fayda vermədən əməliyyat xərci və daha bir nasazlıq rejimi əlavə edir, etibarsız seqment üzərində marşrutlaşdırma isə məxfiliyi ödəyə bilməyəcəyiniz sadəliklə dəyişir. Seçimi üç şərtdən hansının idarə etdiyini yazın və növbəti mühəndis bunu yenidən müzakirə etməli olmayacaq.