İki VPN hovuzu üçün mənbə marşrutlaşdırması: qaydanız nəyi qaçırır
from qaydası SNAT onu yenidən yazmazdan əvvəl müştəri ünvanına uyğun gəlir, şlüzdən edilən sınaq isə heç birinə uyğun gəlmir. Axtarışı hər hovuz üçün aparın və əvəzində prioritetləri oxuyun.
İki müştəri hovuzu, bir şlüz və plan sadə görünür: bir qayda birinci hovuzu sürətli yuxarı kanaldan çıxarır, digəri ikinci hovuzu tərəfdaş tunelindən keçirir. Sonra qaydalar yerindədir və ikinci hovuz hələ də defolt marşrutla çıxır. Qayda pozulmayıb. Paketin mənbəyi axtarışın baş verdiyi anda müəllifin gözlədiyi şey deyil, çünki tərcümə və axtarış eyni paketin səyahətinin fərqli nöqtələrində baş verir və sıra çoxlarının çəkdiyi zehni diaqramın tərsidir.
Axtarış mənbə yenidən yazılmazdan əvvəl baş verir
VPN müştərisindən yönləndirilən paket üçün nüvə sabit ardıcıllıq icra edir. Paket tunel interfeysinə gəlir, conntrack və DNAT-ın yerləşdiyi prerouting mərhələsindən keçir, sonra marşrut qərarı verilir, sonra yönləndirmə, sonra SNAT-ın ən sonda tətbiq olunduğu postrouting mərhələsi. from formalı qayda həmin marşrut qərarı zamanı nəzərə alınır, yəni müştərinin tərcümə olunmuş deyil, orijinal ünvanını görür.
Beləliklə, masquerade qaydası əlavə etmək çıxan axına hansı siyasətin uyğun gəldiyini dəyişmir. Dəyişdiyi şey qarşı tərəfin gördüyü və buna görə hansı qayıdış yolunun mövcud olduğudur. Bunlar iki fərqli nəticədir və dəyişiklik icmalları onları daim qarışdırır. Onları ayırsanız, dizayn adətən bir dəqiqə içində aydınlaşır.
Tərcümə olunmuş ünvan qaydalarda cavab istiqamətində görünür. Şlüzə qayıdan paket tərcümə olunmuş ünvana ünvanlanıb və əgər təyinat və ya gəldiyi interfeys üzrə siyasət qaydalarınız varsa, uyğunlaşdıracağınız dəyər budur. Eyni bağlantı, hər istiqamətdə fərqli həqiqət mənbəyi.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Fərqli mənbələri olan iki hovuz həqiqətən fərqli cədvəllərə ehtiyac duyur və dizayn düzgündür. Yuxarıdakı cədvəlin istisna etdiyi şey, uzaq saytın nə aldığına baxıb qaydanı ondan çıxarmaqla sazlamaq qısayoludur.
Şlüzdən edilən sınaq hovuzun sınağı deyil
Şlüzün özünün yaratdığı trafik heç vaxt prerouting mərhələsindən keçmir, çünki interfeysə gəlməyib. O, çıxış yolunda şlüzün öz ünvanı mənbə olmaqla marşrutlaşdırılır və müştəri aralığına bağlanmış from qaydası uyğun gəlməyəcək. Bu sahədəki hər bilet ki qutudan işləyir, müştəridən işləmir, həmin faktın təkrarıdır.
Müştərini təxmin etmək əvəzinə onu simulyasiya edin. Marşrut axtarışını mənbə və giriş interfeysi verməklə birbaşa soruşmaq olar:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201Hər hovuz üçün bir dəfə işlədin. Əgər iki əmr eyni interfeysi qaytarırsa, qaydalar hovuzları ayırmır və səbəb ya çatışmayan qayda, ya da hər ikisinə uyğun gələn daha yüksək prioritetli qaydadır. Əgər fərqli interfeyslər qaytarır, amma müştəri yenə uğursuz olursa, nasazlıq axtarışdan sonrakı mərhələdədir və qaydalara baxmağı dayandıra bilərsiniz.
Prioritet, fayldakı mövqe deyil
Qaydalar prioritetin artan sırası ilə qiymətləndirilir və əhəmiyyətli olan rəqəmdir, onları yazdığınız sıra deyil. local cədvəli 0 prioritetində, main cədvəli 32766-da, defolt qayda isə 32767-dədir, buna görə defolt prioritetlə əlavə edilmiş qayda siyahının sonuna yaxın düşür və demək olar ki, hər şeyə uduzur.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Açıq prioritet nəzərdə tutulan sıranı həm faylda, həm də icmalda görünən edir. O, həmçinin sonradan edilən əlavənin mövcud qaydanın qabağına səssizcə keçməsinin qarşısını alır, bu da işləyən siyasətin əlaqəsiz dəyişiklikdən sonra işləməsini dayandırmasının ən çox rast gəlinən səbəbidir.
Natamam cədvələ işarə edən uyğun qayda digər tələdir. Əgər 201 cədvəlində defolt marşrut var, amma təyinat üçün marşrut yoxdursa, paket atılır və ya yanlış yerə göndərilir, qayda isə təkbaşına tamamilə düzgün görünür. Qaydanı deyil, cədvəli oxuyun. Qayda göstəricidir, boş cədvəl isə heç yerə göstəricidir.
Qayıdış yolu yenə də mövcud olmalıdır
Mənbə siyasəti çıxış seçir. O, qayıdış yolu yaratmır. Əgər ikinci hovuz tərəfdaş tunelindən çıxırsa, tərəfdaş 172.31.8.0/24 ünvanına necə çatacağını bilməlidir, ya şlüzə geri marşrutla, ya da artıq tanıdığı tərcümə olunmuş ünvanları qəbul etməklə.
Bunlar arasında seçim görünən nəticələri olan dizayn qərarıdır. Müştəri aralığını geri marşrutlamaq tərəfdaşda hər müştərinin kimliyini qoruyur və onların sizin prefiksinizi qəbul etməsini tələb edir. Tərcümə isə hovuzu bir ünvanın arxasında gizlədir və tərəfdaşın yalnız o ünvanı qəbul etməsini tələb edir, bunun qiyməti sizin və onların jurnallarının artıq kimin qoşulduğu barədə razılaşmamasıdır.
Nə seçsəniz də, onu hovuz tərifinin yanında yazın. Yalnız kiminsə yaddaşında mövcud olan qayıdış marşrutu məhz tərəfdaş firewall-u dəyişənə qədər yaşayan və sonra bərpası bir gün çəkən şeydir.
Şlüzün öz tunelini siyasətə salmayın
Müştərilər üçün yazdığınız qaydalar, istisna etməsəniz, şlüzün yaratdığı trafikə də tətbiq olunur. Marka və ya çıxış interfeysinə bağlanmış geniş qayda şlüzün tərəfdaşla öz bağlantısını tuta bilər və onda siyasəti daşıyan tunel siyasətlə marşrutlaşdırılır. Bu, provayder nasazlığına bənzəyən dövrə və ya kəsinti yaradır.
Hər qaydanı dizaynın imkan verdiyi qədər dar çərçivəyə salın: mənbə prefiksi, giriş interfeysi və dəstəkləndiyi yerdə yalnız müştəri paketlərinin daşıdığı marka. Sonra hər qayda dəyişikliyindən sonra şlüzün öz bağlantısını yoxlayın, çünki nasazlıq özünə istinad edir və müştəri sınağında görünmür.
ip-rule təlimat səhifəsi seçici və prioritet semantikasını sənədləşdirir. Onu hər hovuz üçün axtarış sınağı ilə birləşdirin və dizayn yoxlanıla bilən olur, bir il yaşayan siyasət marşrutlaşdırması ilə hamının toxunmağa qorxduğu siyasət marşrutlaşdırması arasındakı fərq budur.