Tunel vasitəsilə uzaq /24 şəbəkəsinə çıxış: NETMAP, DNAT yoxsa marşrut?
Bütün prefiksi NETMAP ilə xəritələyin, hər host üçün DNAT qaydaları əlavə edin və ya real diapazonu marşrutlaşdırın; qərarı qarşı tərəfin nə görməli olduğuna və kimin trafik başlada biləcəyinə görə verin.
Tunel son nöqtəsinin arxasındakı alt şəbəkəyə üç yolla çatmaq olar və bir dəqiqəlik fakt toplama adətən ikisini istisna edir. Faktlar bunlardır: oradakı serverlər istifadəçiləri bir-birindən ayırmalıdırmı, oradan heç vaxt sizin diapazonunuza zəng ediləcəkmi və uzaq marşrutlaşdırıcını kim redaktə edə bilər. Bu üçünə cavab verin, dizayn özü seçiləcək. Qalan hissə son nöqtəni sizin idarə etdiyinizi və onun firewall-unu redaktə edə bildiyinizi fərz edir.
Üç variant və hər birinin həqiqətən nəyi dəyişdiyi
Prefiks xəritələmə, hər host üçün DNAT və marşrutlaşdırılmış prefiks hamısı paketləri eyni iki diapazon arasında hərəkət etdirir, lakin fərqli şeyləri dəyişir. Xəritələmə uydurma alias diapazonu yaradır və ünvanları uçuş zamanı arifmetik olaraq yenidən yazır. Hər host üçün qaydalar da yenidən yazır, sadəcə hər təyinat əl ilə adlandırılır. Marşrutlaşdırılmış prefiks heç nəyi yenidən yazmır: paketlər real ünvanları saxlayır və iki tərəf bu ünvanların harada yaşadığı barədə razılaşır.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Aradan qaldırmaya uzaq tərəfdən başlayın, çünki məhdudiyyətləri dəyişmək ən çətindir. Əgər oradakı server müştəri ünvanlarını loqlara yazırsa, onları icazə siyahısı ilə yoxlayırsa və ya başqa sistemə ötürürsə, mənbəyi tərcümə etmək onun yeganə identifikatorunu məhv edir. Əgər uzaq tərəf özü də zəng etməlidirsə, tərcümə tamamilə mümkünsüzdür, çünki orada heç kim aliasın mövcud olduğunu bilmir. Yalnız uzaq tərəf sadəcə sorğulara cavab verdikdə daha ucuz variantlar təhlükəsiz olur.
Prefiks cütləri və ölçülər niyə uyğun olmalıdır
NETMAP eyni uzunluqlu iki prefiks üzərində işləyən nat cədvəli hədəfidir. İçində hər ünvan üçün cədvəl yoxdur: prefiksi çıxarır, host bitlərini saxlayır və onları yeni prefiksə yenidən bağlayır; buna görə /24 /24-ə xəritələnir və heç vaxt /25-ə xəritələnmir. Mövqe istiqaməti müəyyən edir: PREROUTING-də təyinat uyğunluğu paketin hara getdiyini, POSTROUTING-də mənbə uyğunluğu isə haradan gəldiyini yenidən yazır.
192.168.2.17 ünvanındakı host müştərilərinizə 10.50.1.17 kimi görünür və son oktet dekorativ deyil — hər iki tərəfdə eyni rəqəmdir. Sabah 192.168.2.40 ünvanında bir host əlavə edin, aliası 10.50.1.40 olacaq və redaktə ediləcək heç bir qayda yoxdur.
Müştərilərə hələ də alias diapazonu üçün sizin qutunuza işarə edən marşrut lazımdır, əgər alias artıq çatdıqları alt şəbəkənin içində deyilsə. Şlüzə alias üçün marşrut lazım deyil, çünki təyinat tərcüməsi marşrut axtarışından əvvəl PREROUTING-də işləyir. Yönləndirmə də aktiv olmalıdır, əks halda nüvə paketi yenidən yazmadan sonra atır. Aşağıdakı üç əmr Debian tipli şlüzdə tam quraşdırmadır: müştərilər br0-də, alias 10.50.1.0/24-də və tunel tun0-dadır.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADECavab öz geri yolunu tapmalıdır
Təyinatı yenidən yazmaq yalnız paketin hara çatdırılacağını müəyyən edir. Uzaq tərəfin serveri hələ də çata bildiyi bir ünvana cavab verməlidir və bunu təşkil etməyin iki yolu var. Cavablar qutunuza qayıtsın deyə mənbəyi tərcümə edin, ya da mənbəyə toxunmayın və uzaq tərəfə müştəri diapazonu üçün marşrut verin.
Çıxışda maskalama daha qısa yoldur: POSTROUTING-də bir qayda və uzaq tərəf sizin tunel ünvanınızı görür, ona görə öz marşrutuna ehtiyac duymur. Xərc ondadır ki, hər istifadəçi bir ünvanda birləşir və istifadəçi üzrə loqlar mənasını itirir. Mənbəyi toxunulmaz saxlamaq bu məlumatı qoruyur, lakin uzaq sayt onda müştəri diapazonu üçün cavabları tuneldən geri göndərməlidir. Bir OpenVPN serverində bu, göndərilən push "route 10.50.9.0 255.255.255.0", üstəgəl bir route 192.168.2.0 255.255.255.0 sətri deməkdir.
Bahalı uğursuzluq hər ikisinin yarısını etməkdir. Bəzi trafiki maskalayır, eyni zamanda uzaq tərəf digər trafik üçün geri marşrut daşıyırsa, cavablar əlaqə izləmə qeydinin heç görülmədiyi interfeysə gəlir. Müştəri serverin xidmət göstərdiyi kimi qeyd etdiyi sorğu üçün fasilə bildirir. Axının hər iki istiqaməti eyni netfilter nüsxəsindən keçməlidir: bir şlüz tərcümə edir, sırayla iki firewall deyil.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nQeydi hər iki istiqamətdə oxuyun: orijinal dəst təyinatda aliasınızı saxlayır, cavab dəsti isə real ünvanı daşıyır. Cavab dəsti yoxdursa, problem qayda deyil, geri yoldur. PREROUTING sayğacları heç tərpənməyibsə, paket həmin qarmağa heç çatmayıb.
Toqquşmalar və ilk işləyən axtarış
İki fərqli diapazon toqquşa bilər və hər iki nasazlıq pis qayda kimi deyil, pozulmuş tunel kimi görünür. Uydurduğunuz alias bütün yol boyu istifadə olunmamış olmalıdır və real uzaq diapazon artıq şəbəkənizdə mövcud olmamalıdır. Dublikat arabir yanlış hosta trafik yaradır, bunu diaqnoz etmək rədd edilmiş bağlantıdan çətindir. Qayda əlavə etməzdən əvvəl marşrut cədvəlindən soruşun.
Şlüzdə ip route get 192.168.2.17 tunel cihazını adlandırmalıdır; yerli körpü uzaq diapazonun kölgələndiyini göstərir və heç bir nat qaydası bunu düzəltməyəcək. Öz şəbəkəniz artıq 192.168.2.0/24 istifadə edirsə, toqquşmanın üstünə xəritələmə yığmaq əvəzinə uzaq saytı yenidən nömrələyin.
Real müştəridən sınaqdan keçirin, sonra saxlayın
Sınağı aliası həqiqətən istifadə edəcək maşından edin, şlüzdən deyil, çünki yerli yaradılan trafik heç vaxt PREROUTING-dən eyni şəkildə keçmir. Aliaslı bir hosta bağlantı açın və sayğacların və conntrack qeydinin birlikdə görünməsini izləyin, sonra bağlayın və qeydin getdiyini təsdiqləyin. Köhnə qeyd yarım açıq bağlantıya işarə edir, bu da adətən cavabın heç qayıtmadığını bildirir.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17İki və ya üç uğurlu bağlantı arifmetikanı sübut edir, lakin davamlılıq və ya növbəti mühəndis haqqında heç nə demir. Qaydaları yükləmə prosesinin oxuduğu yerdə saxlayın; Debian və Ubuntu-da bu iptables-save > /etc/iptables/rules.v4 və netfilter-persistent aktiv deməkdir. Yenidən başlatmada yox olan xəritələmə heç olmamasından pisdir, çünki nasazlıq günahlandırılacaq yeni dəyişiklik olmadan gəlir.
Qaydaların yanında qeyd buraxın: alias diapazonu, real diapazon, cütün səbəbi və hansı tərəfin başlaya biləcəyi. Bu qeyd dizaynı heç kimin silməyə cəsarət etmədiyi qayda yığınından ayırır. O, həmçinin sonrakı sualı həll edir: uzaq sayt host əlavə edəndə və heç kimin konfiqurasiya etmədiyi ünvan cavab verəndə. Qeyd deyirsə ki, uzaq tərəfə geri marşrut lazımdır, növbəti şəxs maskalama qaydasını silməyin əlaqəni kəsdiyini bilir. Sənədləşmə burada ucuzdur; gecə saat üçdə NAT asılılığını yenidən kəşf etmək deyil.