Bir NIC, yoxsa iki? VPN serverinin interfeys sxemini seçmək

Bir fiziki adapter bir çox VPN serveri üçün kifayətdir və bu, həm də universal dizayn deyil. Şifrələnmiş bağlantı həmin adapterə gəlir, VPN prosesi onu deşifrə edir və daxili trafik virtual interfeysdən çıxır ki, sonra yerli xidmətə və ya marşrutlaşdırılmış LAN-a çatsın. Bunun işləyib-işləməməsi üç şərtdən asılıdır: təyinatın harada yerləşməsi, LAN-ın müştəri hovuzuna qayıdış yolu olub-olmaması və bir ortaq fiziki linkin iddia etdiyiniz izolyasiyanı verib-verməməsi. Bu üçünə cavab verin, adapter sayı özü ardınca gələcək.

Bunu həll edən üç şərt

Birinci şərt təyinatdır. VPN hostunun özündəki xidmətə yalnız tunel interfeysi vasitəsilə çatılır, LAN-dakı host isə yönləndirmə və qayıdış yolu tələb edir. İkinci şərt həmin qayıdış yoludur, çünki LAN cihazı müştəri hovuzuna necə çatacağını bilməlidir: ya marşrutla, ya da serverdə tərcümə ilə.

Üçüncü şərt ayrılıqdır. Bir adapter o deməkdir ki, hər paket, şifrələnmiş olsun ya olmasın, eyni linki və adətən eyni siyasət zəncirini paylaşır, buna görə ayrı aparata əsaslanan izolyasiya iddiasını tək interfeys təmin etmir. Bu, yol haqqında faktdır, əməliyyat sisteminin necə qurulduğu haqqında deyil. Siz yenə də tunel trafikini filtrləyə bilərsiniz, amma malik olmadığınız sərhədi iddia edə bilməzsiniz.

Üçündən heç biri korpusdakı portların sayı ilə bağlı deyil. Onlar marşrutlaşdırma, ünvan sahibliyi və dizaynın fiziki ayrılıqdan nə qədər asılı olması ilə bağlıdır.

Fiziki zonalar, ayrı uplink-lər, ötürmə qabiliyyəti və ya zolaqdan kənar bərpa yolu iki adapteri haqlı edəndə bu, qanuni seçim olaraq qalır. Bunlar konkret tələblərdir və kimsə aparat sifariş etməzdən əvvəl onları dilə gətirməyə dəyər.

Xidmət VPN hostunda işləyəndə

Ən sadə hal heç bir yönləndirmə tələb etmir. Demon müştərinin paketlərini tunel interfeysində qəbul edir və onları yerli soketə verir, cavab isə eyni interfeysdən geri qayıdır. Müştəri hovuzunun ünvanı host baxımından real yerli ünvandır.

Yenə də iki şey düzgün olmalıdır: xidmət tunelin çata biləcəyi ünvanda dinləməlidir və host firewall-u tunel interfeysinə gələn trafiki qəbul etməlidir. Hər ikisi aşağıdakı əmrlərdə görünür.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Xidməti yalnız ictimai ünvana bağlamaq və ya tunel interfeysini səhvən filtrləmək hosta çatan və sonra ölən bağlantı yaradır. Bu, VPN nasazlığı kimi görünür və adətən soket və ya firewall qərarıdır.

Təyinat LAN-da olanda

Tək adapterli dizaynın zəhmətli reputasiyasını qazandığı yer budur. Server müştərinin paketlərini LAN-a doğru yönləndirməlidir, LAN cihazı isə cavabları müştəri hovuzuna geri göndərməlidir. Ya həmin hovuzu LAN-da marşrut kimi daşıyırsınız, ya da cavablar serverin özünə qayıtsın deyə mənbə ünvanını serverdə tərcümə edirsiniz.

Hər iki cavab qanunidir və fərqli şəkildə uğursuz olur. Qayıdış marşrutu orijinal müştəri ünvanını təyinat üçün görünən saxlayır; bu, jurnallar üçün yaxşı, LAN ünvanlarını güman edən firewall qaydaları üçün pisdir. Tərcümə LAN-ı sadə saxlayır və müştərinin kimliyini təyinatdan gizlədir.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Asimmetrik yol klassik simptomdur: müştərinin sorğusu gəlir, cavab başqa marşrutlaşdırıcıdan çıxır və bağlantı hər iki tərəfdə xəta olmadan vaxt aşımına uğrayır. Tunel haqqında nə isə qənaətə gəlməzdən əvvəl hər iki tərəfdə tutun.

Niyə alias ikinci zona yaratmır

Eyni adapterə ikinci ünvan əlavə etmək və ya ikinci portu təqlid etmək üçün dummy interfeys yaratmaq çox az şey dəyişir. Paketlər yenə eyni fiziki linkdən, eyni kommutator portundan və adətən eyni firewall zəncirindən çıxır, buna görə aralarında yeni sərhəd yoxdur. Bu, konfiqurasiya rahatlığıdır, seqmentasiya deyil. Onu zona sərhədi kimi qəbul etmək izolyasiya iddiasının yalnız kağızda qalmasının yoludur.

Ayrı zona yolda həqiqi ayrılıq tələb edir və ikinci adapterin təmin etdiyi tələb budur. Əgər bir qayda VPN-ə baxan trafikin LAN-a baxan trafiklə heç vaxt yayım domenini paylaşmamasından asılıdırsa, host necə ünvanlanırsa ünvanlansın, bir kabel bu xassəni verə bilməz.

Məhsul müəyyən rejim üçün çoxinterfeysli topologiyanı sənədləşdirirsə, alternativ həll icad etmək əvəzinə həmin məhsulun sənədlərinə əməl edin. Vendorlar da buraxılışlar arasında dəstəklənən topologiyalarını dəyişir və bu, köhnə sehrbaz ekran görüntüsü yerinə cari bələdçini oxumaq üçün başqa bir səbəbdir.

Sxemi icazə verdiyiniz trafikə görə yoxlayın

Serverin daşıması gözlənilən trafik siniflərini sadalayın: müştəridən hosta, müştəridən LAN-a, hostdan LAN-a və şifrələnmiş xarici bağlantı. Hər sinfin mənbəyi, təyinatı və interfeysi var və sxem dördünü eyni anda təmin etməlidir. Onlardan üçünü həll edən dizayn adətən bilet yaradan dizayndır.

Sonra dizayn sənədindəki diaqramı deyil, faktiki interfeysləri və faktiki tutmanı təsdiqləyin. Aşağıdakı əmrlər hər iki görünüşü çap edir.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Əgər xarici tutma şifrələnmiş trafiki, daxili tutma isə tunel interfeysində deşifrə olunmuş trafiki göstərirsə və fiziki adapter hər ikisini daşıyırsa, bir NIC işi görür. Daxili tutma boşdursa, problem tuneldə və ya yönləndirmə qaydalarındadır, adapter sayında deyil. Topologiyanı həmin iki tutma və marşrut cədvəlindən həll edin, onda növbəti dəyişikliyin ölçüləcəyi bir şey olacaq.