VPN müştəri xidmətinə çatmaq: əks tunel, yoxsa DNAT

Hətta operator NAT-ı arxasındakı noutbuk da həmkarına xidmət göstərə bilər, bir şərtlə ki, VPN serveri görüş nöqtəsi olsun. Buna iki mexanizm gətirir: müştəri bayıra qoşulur və serverdən dinləmə portunu saxlamağı xahiş edir, ya da server portu yayımlayır və onu tunelə çevirir. Hər ikisi eyni əlçatanlıq problemini həll edir və nasazlıq, nəzarət və jurnal qeydləri zamanı fərqli davranır. Hansının sizin quruluşunuza aid olduğunu üç şərt müəyyən edir.

İki forma, bir görüş nöqtəsi

Birinci formada müştəri bayıra doğru SSH sessiyası açır və serverdən seçilmiş portda dinləməyi xahiş edir, hər bağlantını həmin sessiya ilə geri yönləndirir. Serverdə heç nə yönləndirilmir və paket çevrilməsi baş vermir, ona görə yeganə tələblər SSH hesabı, icazə verilmiş yönləndirmə və port üçün firewall qaydasıdır. Xidmət müştəridə loopback ünvanına bağlı qalır, bu da adətən istədiyinizdir.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

İkinci formada portun sahibi serverdir və hər bağlantını müştərinin tunel ünvanına doğru yenidən yazır. Bu, IP yönləndirməsinin aktiv olmasını, girişdə təyinat çevrilməsini və çıxışda mənbə çevrilməsini tələb edir və heç bir SSH sessiyası olmadıqda da işləməyə davam edir. Port sessiyaya deyil, serverə aiddir və real halların çoxunu məhz bu xassə həll edir.

Heç bir forma konstruksiyaya görə daha təhlükəsiz deyil. Hər ikisi bir xidmət portunu serverin ictimai ünvanına çata bilən hər kəsə açır və hər ikisi yenə də xidmətin öz autentifikasiyasından asılıdır.

Şərt bir: port sessiyadan çox yaşamalıdırmı

Əks yönləndirmə onu yaradan SSH sessiyası qədər yaşayır. Əlaqə kəsiləndə dinləyici yox olur və həmkar yavaş yol əvəzinə bağlantı rədd edildi görür. Komandanı systemd vahidi və yenidən başlatma siyasəti ilə nəzarət altında saxlamaq bunu aradan qaldırır və ExitOnForwardFailure=yes uğursuz bağlanmanı dərhal görünən edir, yönləndirməsiz işləyən sessiya qoymaq əvəzinə.

Çevrilmiş port qaydalar saxlanılırsa yenidən başlatmalara dözür, lakin müştərinin eyni tunel ünvanını saxlamasından asılıdır. Yenidən qoşulmadan sonra noutbuka başqa ünvan verən dinamik hovuz qaydanı səssizcə heç bir yerə yönəldir. Əvvəlcə tunel ünvanını ayırın, sonra qaydanı yazın və ikisini tək dəyişiklik kimi qəbul edin.

Xidmət gecə saat üçdə heç kim baxmadan cavab verməlidirsə, serverin yayımladığı port daha az hərəkətli hissəyə malik formadır, çünki ayaqda qalmalı olan yeganə proses tunelin özüdür.

Şərt iki: firewall və jurnallar kimə aiddir

Əks forma bütün siyasəti iki yerdə saxlayır. sshd uzaq yönləndirmələrə ümumiyyətlə icazə verilib-verilmədiyini AllowTcpForwarding vasitəsilə, GatewayPorts isə dinləyicinin loopback-ə və ya bütün ünvanlara bağlanmasını həll edir. Standart no dəyəri ilə serverdən kənardakı həmkar yönləndirmə uğurlu olsa da porta çata bilmir və bu, əslində bağlanma ünvanı olduğu halda qırıq tunel kimi görünür.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Çevrilmiş forma yönləndirmənin aktiv olmasını və iki qayda tələb edir, ikinci qayda isə reseptlərin çoxunun səhv getdiyi yerdir. Mənbə çevrilməsini conntrack DNAT vəziyyəti ilə məhdudlaşdırmaq yalnız təyinat qaydasının yaratdığı bağlantıların yenidən yazılması deməkdir, serverin tunelə göndərdiyi hər paketin əvəzinə.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Bu yenidən yazma həm də aidiyyəti məhv edir. Bundan sonra müştəri hər zəng edəni serverin tunel ünvanı kimi görür, bu da hər ünvana düşən sürət limitini bir vedrəyə yığır və kimin nə göndərdiyini gizlədir. Aidiyyət vacibdirsə, bağlantını serverdə sonlandırın və ya icazə qərarını orada saxlayın və xidmətin etibar etdiyi başlıqda kimlik ötürün. Bu iki düzəliş arasında seçim xidmətin ümumiyyətlə proxy başlığı oxuyub-oxumamasından asılıdır.

Şərt üç: bir port, yoxsa çoxlu port və ad kimə aiddir

Bir portda bir xidmət əks yönləndirmənin səylə qalib gəldiyi haldır. Bir əmr, bir hesab və bir firewall qaydası lazımdır, təmizlik isə sessiyanı öldürməkdir. Eyni ictimai ünvanda çoxlu xidmət sizi serverin yayımladığı formaya dartır, çünki hər əks yönləndirmə öz server portunu tələb edir və çoxluq hər xidmətlə böyüyür.

Adlar işi daha da çətinləşdirir. Əks yönləndirmə SNI üzrə marşrutlaşdıran TCP proksisinin arxasında dura bilər, çevrilmiş port isə adətən hər xidmət üçün bir portdur. Xidmət TLS-i özü sonlandırır və orijinal host adına ehtiyac duyursa, proksi yanaşması onu saxlayır, DNAT yanaşması isə yalnız xidmət həmin portda həmin adı qəbul edərsə saxlayır.

Formanı üç şərtdən hansının həll etdiyini yazın. Əks halda ikinci xidməti əlavə edəcək növbəti şəxs eyni müqayisəni daha az kontekstlə yenidən açacaq.

Qərar verin, sonra kənardan sınaqdan keçirin

Yola noutbuka heç bir marşrutu olmayan şəbəkədən sınaqdan keçirin və sorğu icra olunarkən serverdəki sayğacları izləyin. Serverdən öz ictimai ünvanına sınaq heç nə sübut etmir, çünki paket yerli olaraq yaradılır və gələn çevrilmə qarmağına heç vaxt çatmır, beləliklə sınaq keçə bilər, real yol isə qırıq ola bilər.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Düz qalan sayğaclar paketin qaydaya heç vaxt çatmadığını bildirir, bu da provayderə və ya host firewalluna işarə edir. Xidmət imtina edərkən hərəkət edən sayğaclar müştərinin öz firewalluna və ya xidmətin dinlədiyi ünvana işarə edir. Paketi daşıyıb heç nə qaytarmayan tunel marşrut və ya əks yol problemidir, və bu üç nəticədən heç biri müştəri adapterini redaktə etməklə aradan qaldırılmamalıdır. Nəyisə dəyişməzdən əvvəl hansı sayğacın hərəkət etdiyini yazın, çünki növbəti sınaq həmin baza xəttinə ehtiyac duyur.

Forma işlədikdən sonra portu, sahibini və nəzarət üsulunu tunel konfiqurasiyasının yanında qeyd edin. Yalnız kiminsə shell tarixçəsində mövcud olan əlçatanlıq düzəlişi tək yenidən başlatma ilə təkrarlanan hadisəyə çevrilə bilər.