LAN-ınız niyə VPN müştərisindəki xidmətə çata bilmir
VPN müştərisi LAN-ın aça bilmədiyi xidməti yerləşdirə bilər. Çatışmayan adətən geri yoludur: bir marşrut, DNAT cütü və ya heç kimin əlavə etmədiyi SNAT sətri.
Tunnel işləyir, xidmət dinləyir, ofis LAN-ı isə hələ də heç nə qaytarmır. Heç kim VPN-i pozmayıb. LAN tərəfindən baxanda noutbukun tunnel ünvanı mövcud deyil, ta ki kimsə LAN-a ona necə çatmaq lazım olduğunu deyənə qədər, və cavab sorğunun getdiyi yolla geri qayıtmalıdır. Mən insanların cavab yoluna baxmazdan əvvəl tamamilə yaxşı bir tunnelı üç dəfə yenidən qurduğunu görmüşəm.
Xarab olan tunnel deyil
Hər iki tərəf şəxsi diapazonlarda oturur, bu normal haldır və səhv konfiqurasiya deyil. 10.8.0.6 kimi ünvan tunnelin içində realdır və başqa heç yerdə mövcud deyil, ona görə LAN-ın ona nəyisə göndərməsinə heç bir səbəb yoxdur. Marşrutlaşdırmaya toxunmazdan əvvəl xidmətin ümumiyyətlə tunnelin içindən əlçatan olduğunu təsdiqləyin: müştəridə ss -ltn dinləyicinin 127.0.0.1 ünvanına, LAN interfeysinə yoxsa tunnel ünvanına bağlandığını göstərir. Yalnız loopback-a bağlanmış demon özündən başqa heç kimə cavab vermir və heç bir marşrut, DNAT və ya port yönləndirməsi bunu dəyişmir.
80 və ya 443 portundakı proksi fərqli görünürlüyü olan fərqli bir alətdir. O, paketləri deyil, sorğuları hərəkət etdirir, yəni xam verilənlər bazası bağlantısı üçün yanlış təbəqədir, və ona əl atmaq bu problemin kimsə nəyisə ölçməzdən əvvəl üç alət dərinliyinə getməsinin yoludur.
Marşrut forması: LAN-a hovuzun harada olduğunu deyin
LAN şlüzündə statik marşrut LAN ilə tunnel hovuzu üst-üstə düşmədikdə ən təmiz cavabdır. Hovuzu tunnelı sonlandıran maşına yönəldin:
ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12 # Windows, persistent
Bu yalnız bir istiqaməti düzəldir, buna görə də bu dəyişikliyin yarımçıq variantları tərəqqi kimi görünür. Tunnel tərəfinə uyğun yarısı lazımdır, əks halda cavab müştərini öz standart marşrutu ilə tərk edir və yolda ölür:
push "route 192.168.1.0 255.255.255.0"
Bir müştərinin arxasında, serverin arxasında deyil, yerləşən alt şəbəkə üçün server həm sistem marşrutuna, həm də iroute girişinə ehtiyac duyur; bu giriş həmin müştərinin client-config-dir altındakı faylında olur. iroute olmadan OpenVPN prefiksin mövcud olduğunu bilir və hansı müştərinin ona sahib olduğunu bilmir: paketlər gəlir və demonun onları uyğunlaşdıracaq heç nəyi yoxdur.
Budur ad çəkməyə dəyər mif. Marşrut ünvanı əlçatan edir, amma qarşı tərəfi cavab verməyə həvəsli etmir. Saytlararası həmyaşıdlar üstünə başqa bir qat əlavə edir, çünki uzaq şlüz yalnız öz siyasətində sadalanan prefikslərin içindəki mənbələri qəbul edir və ev hovuzundan gələn noutbuk onların içində deyil.
NAT forması: içəri DNAT, və hamının atladığı SNAT sətri
LAN şlüzünə toxuna bilmədikdə və ya tam bir port dərc etmək istədikdə, VPN hostunda translasiya LAN-da heç bir marşrut olmadan işləyir. Portu dərc edin, yönləndirin və mənbəni tunnelə doğru yolda tərcümə edin:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1
Üçüncü sətir itən sətirdir. Onu atlayın və müştəri mənbə kimi orijinal LAN ünvanını görür, öz standart marşrutu ilə cavab verir və bu cavab LAN-a doğru deyil, tunnelə doğru gedir. Bağlantının sağ qalıb-qalmaması sonra heç planlaşdırmadığınız marşrutlaşdırmadan asılı olur. SNAT ilə müştəri serverin tunnel ünvanını görür, buna görə cavab translasiyanı ləğv edə bilən yeganə hosta qədər tunneldən geri qayıdır.
İstehlakçı firmware öz zəncir adlarından istifadə edir və həmin translasiyanı sizin üçün yaratmır. Tomato-da daxil olan qayda WANPREROUTING-a, sonra wanin kimi filtr zəncirinə düşür və tam görünən qayda dəsti hələ də əl ilə POSTROUTING sətri tələb edir. Bu firmware xətası deyil, bu yalnız daxil olan trafik üçün yazılmış qayda dəstidir.
Niyə düzgün görünən qayda paketi yenə də atır
Bu nasazlıqların çoxu baxdığınız qaydada deyil. Dörd şeyi bu ardıcıllıqla yoxlayın və yerinə yetməyən birincisində dayanın:
- Zəncir sırası.
iptables -Iyuxarıya daxil edir,-Aisə sona əlavə edir, yəni daha əvvəlki icazəverən və ya bloklayan qayda birinci qərar verir. - Səhv zəncir. Routerin özünə ünvanlanmış trafik INPUT-dan keçir, yönləndirilən trafik isə ona heç toxunmur. Bir xidmətin dərc edilməsi hər ikisində qayda tələb edə bilər.
- İstiqamət bayraqları.
-i tun0müştərilərdən gələn trafiki uyğunlaşdırır,-o tun0isə onlara doğru gedən trafiki. Səhv bayraqlı REJECT nəzərdə tutmadığınız bir şeyi bloklayır. - Mənbə məhdudiyyəti. Bir müştəri ünvanını qəbul edən yönləndirmə həmin müştəridən işləyir və hər başqa mənbəni bir söz demədən atır.
Paket sayğacı sıfır olan qayda ümumiyyətlə yolda deyil və sayğacları oxumaq səhv-zəncir problemini səhv-qayda problemindən ayırmağın ən sürətli yoludur.
LAN-da heç nə dəyişə bilmədikdə yerli yönləndirmə
SSH yerli yönləndirməsi bütün sualı kənardan keçir. LAN-da marşruta, müştərinin firewall-undan əməkdaşlığa və heç bir yerdə dərc edilmiş porta ehtiyac duymur:
ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host
Xidmət sonra tunnelı işlədən maşının localhost:3000 ünvanında görünür və başqa heç yerdə yox. Sərhəd budur: bir iş stansiyası, bir port və yönləndirmə sessiya ilə birlikdə ölür, məgər kimsə onu yenidən başlatmasa. Test verilənlər bazasını yoxlayan admin üçün düzgün alətdir. Başqa insanların çatmalı olduğu kamera və ya skaner üçün isə deyil, çünki hər istifadəçiyə öz yönləndirməsi lazım olardı.
Başqa qayda əlavə etməzdən əvvəl hər iki istiqaməti yoxlayın
Translasiya izlər buraxır və onları oxumaq təxmin etməkdən yaxşıdır. VPN hostunda conntrack -L translasiyanın ümumiyyətlə baş verib-vermədiyini, iptables -t nat -L -n -v sayğacların hərəkət edib-etmədiyini, tcpdump -ni any port 3000 isə hansı mənbə ünvanının həqiqətən gəldiyini göstərir. Müştəridə ss -ltn dinləyicinin tunnelın çata bildiyi ünvanda olduğunu təsdiqləyir.
Sonra saxlayacağınız formanı seçin. Bir dərc edilmiş port, bütün hovuz üçün marşrut və bir admin üçün yönləndirmə üç fərqli öhdəlikdir və onları qarışdırmaq işləyən quraşdırmanın altı ay sonra heç kimin izah edə bilmədiyi bir şeyə çevrilməsinin yoludur. Hansı ünvanın haradan əlçatan olduğunu yazın və bunu sazlamağa başlayan növbəti şəxs tunneldən deyil, cavabdan başlayır.