Tam tunel OpenVPN: server tərəfində internet çıxışı əlavə edin

Müştəri autentifikasiyadan keçir, hovuzdan ünvan alır və VPN hostundakı xidmətlərə çatır, lakin hər açıq təyinatın vaxtı bitir. Çıxışı olmayan tunel belə görünür və dörd ayrı şərt yerinə yetməyincə belə qalır. Müştəri defolt marşrutu qəbul etməlidir, server yönləndirməlidir, firewall keçişə icazə verməlidir və cavabların hovuza qayıtma yolu olmalıdır. Dörd nasazlığın hamısı eyni simptomu bölüşür, ona görə hər cəhddə bir elementi dəyişin və nəticəni qeyd edin.

Defolt marşrutu itələyin və müştərinin nə quraşdırdığını təsdiqləyin

Server tərəfindəki sətir qısadır və yalnız itələnmiş seçimləri qəbul edən müştərilərə təsir edir. def1 forması mövcud defoltu silmək əvəzinə iki yarım-defolt marşrut qurur, bu da cari bağlantını canlı saxlayarkən hər təyinatı tutur.

push "redirect-gateway def1"

Yenidən qoşulduqdan sonra profilə güvənmək əvəzinə müştərinin marşrut cədvəlini oxuyun. Linux-da iki /1 qeydi orijinal defoltun yanında görünür, Windows isə eyni cütü 0.0.0.0/1 və 128.0.0.0/1 kimi göstərir. İtələnmiş seçimləri nəzərə almayan və ya onları rədd etmək üçün konfiqurasiya edilmiş müştəri köhnə defoltunu saxlayır və heç vaxt internet trafikini tunelə göndərmir. Serverdə heç nəyi dəyişməzdən əvvəl bu sualı həll edin, çünki heç bir server tərəfi qaydası bunu kompensasiya edə bilməz.

Yönləndirmə VPN parametri deyil, server parametridir

Marşrutlaşdırmaya toxunmazdan əvvəl yönləndirmə bayrağını oxuyun. Oradakı sıfır kernelin müştəri paketini qəbul edib onu ötürməkdən imtina etdiyini bildirir ki, bu da uzaq tərəfdən firewall blokuna tam bənzəyir. Dəyəri sistemin konfiqurasiya kataloqu vasitəsilə təyin edin ki, yenidən başlatmadan sonra da qalsın.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Sonra hostun özünün internet çıxışına işlək marşrutu olduğunu təsdiqləyin. Serverin qabığından edilən sorğu yuxarı yolun işlək olduğunu sübut edir və müştəri paketinin yönləndirilməsi haqqında heç nə demir, ona görə bunları iki ayrı test kimi qiymətləndirin. Server təyinat nöqtəsinə çata bilmirsə, nə qədər yönləndirmə konfiqurasiyası olsa da kömək etməyəcək.

Nəzərdə tutduğunuz keçişə icazə verin, başqa heç nəyə

Yönləndirilmiş paketlər forward yolunu keçir; VPN hostunun özünə ünvanlanmış trafik input yolunu keçir. Bunlar fərqli qərarlardır və input yolunu açmaq maşından keçişə icazə vermir. Onları qarışdırmaq firewallun hər şeyə icazə verdiyi görünüb müştərilərin yenə də vaxt aşımına düşməsinin ən geniş yayılmış səbəbidir.

Minimal siyasət hovuzdan çıxış interfeysinə doğru yeni bağlantıları qəbul edir və qurulmuş axınlara aid cavabları qəbul edir. Onu distributivinizin istifadə etdiyi qayda dəstinin sahibinə yerləşdirin, hər açılışda təkrarlanan qayda əlavə etməyin; təkrarlanan qaydalar yığılır və sayğaclar mənasını itirir.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Bütün zəncirləri qəbula keçirmək testi keçirir və firewallun mövcudluq səbəbini aradan qaldırır. Əhatəni hovuz və çıxış interfeysi ilə məhdudlaşdırın, əlaqəsiz yönləndirməni toxunulmaz buraxın.

Cavablara gedəcək yer verin

Hovuz ünvanları şəxsidir, ona görə açıq server cavabı birbaşa onlara çatdıra bilməz. Ya VPN hostu çıxışda mənbə ünvanını çevirir, ya da yuxarıdakı cihaz hovuza geri marşrut saxlayır.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Tam olaraq bir çevirmə qatı əlavə edin. Daha yuxarıdakı ikinci NAT birincini gizlədir və sonradan nəsə pozulanda hər iki jurnalı demək olar ki, faydasız edir. Yuxarıdakı marşrutlaşdırıcı hovuzu artıq geri yönləndirirsə, hostda çevirmə əlavə etmək artıqdır və qayıtma yolu sonra sizin yox, həmin marşrutlaşdırıcının konfiqurasiyasından asılı olur.

Bulud instansları daha bir qapı əlavə edir, çünki bəzi platformalar mənbə ünvanı instansın özününkü olmayan paketləri bu yoxlama yumşaldılmadıqca atır. Bu parametr qonaqdan kənarda yerləşir və yerli test maşını işləyəndə onu unutmaq asandır.

Bunu server qabığından deyil, müştəridən sübut edin

Rəqəmsal IPv4 sorğusu ilə başlayın, sonra ad axtarışı, sonra tətbiq. ping yönləndirməni və çevirməni sübut edir;ad həllinə dair heç nə sübut etmir, çünki DNS seçimləri yalnız müştəri inteqrasiyası onları quraşdırdıqda qüvvəyə minir.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Dəyişiklikləri və geri qaytarma addımını işlədikcə qeyd edin ki, test uğursuz olanda çıxış siyasəti bir hərəkətlə geri qaytarıla bilsin. Bu resept yalnız IPv4-ü əhatə edir; yerləşdirmənin bütün trafiki daşıdığını iddia etməzdən əvvəl IPv6-nı ayrıca inventarlaşdırın.