Bir host xidməti internetə fiziki yuxarı kanal üzərindən cavab verməli, maşındakı hər şey isə tuneldən istifadə etməyə davam etməlidir. Siyasət əsaslı marşrutlaşdırmanın bu yükü daşıya biləcəyini üç şərt həll edir və hər birini qayda yazmadan əvvəl yoxlamaq ucuzdur. Xidmət DNAT və ya yönləndirilmiş port arxasında deyil, bu hostda sonlanmalıdır, VPN-in öz qaydaları istisnaya icazə verməlidir və siz sorğunu deyil, cavabı uyğunlaşdırmalısınız. Üçündən hər hansı biri uğursuz olarsa, aşağıdakı əmrlər təmiz yüklənər, amma faydalı heç nə etməz.

Qayda yazmadan əvvəl üç şərti yoxlayın

Portu DNAT ilə dərc edən konteyner və ya port yönləndirməsinin arxasındakı server bu hostda yaranmayan paketlər istehsal edir. Bu paketlər yönləndirilir, ona görə də hostun lokal girişinə bağlanan qayda onları heç vaxt görmür və trafik defolt marşrutu tutmağa davam edir. Davam etməzdən əvvəl xidmətin həqiqətən harada işlədiyini təsdiqləyin, çünki bu, insanların ən çox səhv saldığı şərtdir.

İkinci şərt mexanika deyil, siyasətdir. Tuneli yan keçən istənilən marşrut tunelin məqsədinə istisnadır və idarə olunan hostda bu qərar siyasətin sahibinə aiddir, taym-autu ayıklayan şəxsə deyil.

Cavabı uyğunlaşdırın, müştərinin təyinat portunu yox

TCP 443-də dinləyən serverin cavabı hostdan mənbə portu 443 ilə çıxır. Eyni hostdakı brauzer uzaq HTTPS saytına qoşularkən qısamüddətli mənbə portu və təyinat portu 443 göndərir. Hər ikisi port 443 trafikidir və yalnız biri WAN cədvəlini tutmalıdır, buna görə təyinat portuna uyğunlaşdırma yanlış yarısını tutardı.

Fərqləndirə biləcəyiniz şey cavab istiqamətidir. Mənbə portunu uyğunlaşdırın, qaydanı lokaldə yaranan paketlərlə məhdudlaşdırın və qayda brauzerin sorğularına toxunmadan xidmətin öz cavablarını əhatə edir.

Qayda ora yönəlməzdən əvvəl tam qaytarma cədvəli qurun

Boş cədvəl marşrut yox deməkdir, bu da pozulmuş siyasət deyil, pozulmuş xidmət kimi görünür. Əvvəlcə onu doldurun, hostda başqa heç nəyin iddia etmədiyi cədvəl nömrəsi və prioritetlə:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Rəqəmləri köçürmək əvəzinə canlı hostdan oxuyun. ip -4 rule show hansı prioritetlərin tutulduğunu göstərir və artıq mövcud olan prioritetə qayda əlavə etmək təkbaşına düzgün görünən iki qaydanın sırasını səssizcə dəyişir.

Burada əsl işi iki seçici görür. iif lo nüvənin hostun özünün yaratdığı paketləri necə bildirməsidir, ona görə qayda kənardan gələn yönləndirilmiş trafiki təsadüfən tuta bilməz. ipproto tcp sport 443 bunu bir nəqliyyat və bir porta daraldır ki, bu da tələbin icazə verdiyi qədər sıxdır. Protokol seçicisini çıxarsanız, qayda UDP 443-ü də tutur, bu isə fərqli davranışlı fərqli xidmətdir.

Şəxsi cavabları tunelin içində saxlayın

Eyni dinləyici şəxsi tərəfdəki müştərilərə də cavab verirsə, 100-cü cədvəldəki hər şeyi tutan WAN defoltu həmin cavabları yuxarı kanaldan qaytarmağa çalışacaq. WAN defoltuna tabe olmamalı olan şəxsi prefiksləri əlavə edin və ya onların növbəti siyasət qaydasına düşməsinə imkan verin:

ip -4 route add table 100 throw 10.90.0.0/24

Throw marşrutu bu cədvəldə axtarışı bitirir və paketi qayda siyahısına qaytarır, beləliklə ardınca gələn VPN siyasəti öz şansını alır. Özü tunelə heç nə yönləndirmir və əgər sonrakı heç bir qaydada uyğun marşrut yoxdursa, paket yenə də uğursuz olur; throw-un düzəliş olduğunu fərz etmək əvəzinə növbəti siyasəti yoxlayın.

Əks yol filtrləmə və host firewall qaydaları gələn sorğuya hələ də tətbiq olunur. Doğrulamanı yumşaltmazdan əvvəl onların real qərarlarına baxın, çünki marşrut istisnası rp_filter parametrinin mümkün saymadığı qaytarma yolunu qəbul etməsinə səbəb olmur.

Əvvəlcə TCP, sonra QUIC, sonra yenidən başlatma yoxlayın

Səlahiyyətli xarici müştəridən bir, şəxsi tərəfdən bir bağlantı açın, sonra cavab axtarışını real ünvanlar və portlarla yoxlayın. Xarici cavab 100-cü cədvəli tutursa, şəxsi cavab tutmursa, siyasət istədiyinizi edir.

HTTP/3 UDP üzərindən verilir və TCP qaydası ilə uyğunlaşdırılmayacaq, ona görə QUIC dinləyicisi öz seçicisinə ehtiyac duyur, əks halda HTTPS işləyərkən tuneldən istifadə etməyə davam edəcək. Hansı qaydalarda qərarlaşsanız, onları interfeysin sahibi olan komponentlə saxlayın və yenidən qoşulma və ya DHCP yenilənməsindən sonra təsdiqləyin. Rəqib bir menecer yenidən başlatmadan sonra işlək marşrutu silsə, bu, mənbədə həll edilməli sahiblik problemidir, üstünə daha geniş NAT qaydaları əlavə etmək üçün səbəb deyil.

Əlaqəli məqalələr