Marşrutlaşdırılmış VPN müştərisi serverə çatır, LAN hostlarına çatmır

Tunel qalxır, müştəri VPN serverinə ping göndərir və bir addım aralıdakı maşındakı paylaşım heç vaxt cavab vermir. Müştəri konfiqurasiyasında bunu izah edən heç nə yoxdur, çünki sorğu müştəridən çıxıb və hədəfə çatıb. Uğursuz olan qayıdış yoludur və uğursuz olan cihaz adətən VPN hostu deyil, LAN şlüzüdür. Cavab paketinin izlənməsi bütün simptom sinfini izah edir.

Cavabı izləyin, sorğunu yox

VPN serveri müştəri paketinin şifrəsini açır və mənbə sahəsində müştəri ünvanı qalmaqla onu LAN-a yönləndirir. Hədəf host bu ünvana cavab verir və indi onun öz marşrut cədvəli hər şeyi həll edir. Onun standart şlüzü tunel hovuzu haqqında heç nə bilmir, ona görə cavab internet provayderinə doğru çıxır və o yolun harındasa atılır.

Müştəridə simptom səssiz fasilədir: nə imtina, nə sıfırlama, sadəcə heç nə. Paylaşımın baxışı donur, ping cavab olmadığını bildirir və server jurnalları sağlam görünür, çünki server öz işini görüb.

Qayıdış marşrutunu hostların baxdığı yerə qoyun

Hər LAN hostu öz standart şlüzünə müraciət edir, ona görə tunel hovuzunun harada olduğunu bilməli olan yeganə cihaz şlüzdür. Orada statik marşrut əlavə edin və hər host toxunulmadan düzgün yolu miras alacaq.

Şlüz öz ünvanını DHCP seçimi kimi paylaşırsa, marşrutu bu yolla yayın ki, yeni maşınlar onu avtomatik götürsün. Əks halda marşrut bir konfiqurasiya faylında yaşayır və növbəti yenidən qurmada yox olur.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Mənbə NAT-ı niyə problemi düzəldir kimi görünür

Müştəri hovuzunu VPN server ünvanının arxasında maskalamaq problemi paketdən müştəri ünvanını çıxarmaqla aradan qaldırır. Sonra cavablar artıq tunelə necə çatacağını bilən serverə qayıdır və hər şey işləyir. Qiyməti odur ki, daxili hostlar artıq müştərinin kim olduğunu görə bilmir və hər bağlantı bir maşından gələn kimi görünür.

Bu mübadilə bəzən düzgündür, məsələn, təchizatçı cihazına statik marşrut vermək mümkün olmadıqda. Qaydanı cari hovuzdan geniş etməyin, çünki /24 üçün yazılmış qayda hovuz /16-ya yenidən nömrələndiyi gün uyğunluğu dayandırır və ilk əlamət qoşulan, lakin heç nəyə çatmayan yeni müştərilər dəstəsidir.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Bulud yolu üç parametr tələb edir

VPC-də eyni boşluq başqa formada qayıdır, çünki subnetdə müştəri diapazonu üçün ümumiyyətlə marşrut yoxdur. Marşrut cədvəlinə tunel hovuzu üçün instansın şəbəkə interfeysini hədəfləyən giriş lazımdır və interfeysdə mənbə və təyinat yoxlaması söndürülməlidir ki, platforma mənbəyi öz ünvanı olmayan paketləri qəbul etsin. Təhlükəsizlik qrupları və şəbəkə ACL-ləri də hovuza hər iki istiqamətdə icazə verməlidir.

Hər buraxılış ayrıca qismən nasazlıq yaradır. Marşrut cədvəli girişini atlayın və şəxsi instanslar cavabı hovuza geri daşıya bilməyən subnetə cavab verəcək. Yoxlama hələ aktivkən platforma cavabı instans onu artıq göndərdikdən sonra atır. Təhlükəsizlik qrupu qaydası olmadan sorğunun özü heç vaxt çatmır və müştəri fasiləni bir qat əvvəl görür.

Yoxlamaları bu sıra ilə aparın

Marşrutlaşdırmanı günahlandırmazdan əvvəl yönləndirməni və filtr siyasətini təsdiqləyin, çünki yönləndirməyən host eyni səssiz şəkildə nasaz olur. Sonra tuneli daşıyan interfeysdə effektiv tərs yol parametrini oxuyun, çünki sərt filtr gözlənilməz istiqamətdən gələn cavabları ata bilər.

Müştəri ona ping göndərərkən LAN hostunda çəkilmiş tutma ilə bitirin. Uyğun cavabsız gələn sorğu qayıdış yolunu sübut edir, heç vaxt çatmayan sorğu isə nasazlığı serverə və ya tunelə qaytarır.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Mənbə və təyinat yoxlaması elastik şəbəkə interfeysi bələdçisində sənədləşdirilib. Onu tunel trafikini həqiqətən daşıyan interfeysdə qurun, eyni instansa qoşulmuş əlaqəsiz adapterdə yox.