FORWARD, OUTPUT və IPv6-nı əhatə edən router kill switch

Routerə daxil olursunuz, forum yazısından kill-switch qaydalar dəstini yapışdırırsınız və tunel düşən anda LAN-da gəzinti dayanır. İki gün sonra router hələ də dinamik DNS qeydini adi WAN üzərindən yeniləyir, qonaq laptopu isə hələ də IPv6 saytlarına çatır. Hər iki davranış normaldır, çünki yapışdırılmış qaydalar bir zənciri və bir ünvan ailəsini əhatə edirdi və bunların heç biri bütün router deyil. Paket yollarını sıra ilə gəzmək nəyin buraxıldığını dəqiq göstərir.

Laptopdan deyil, routerdən başlayın

Router səviyyəsində siyasət kiçik ofis üçün cəlbedicidir, çünki arxasındakı hər cihaz eyni davranışı miras alır və heç kim müştəri açarını yandırmağı unuda bilməz. O, həm də hər firmware yeniləməsindən sonra sınaq üçün bir yer verir. Vermədiyi şey routerin öz trafikinin və ya ikinci ünvan ailəsinin avtomatik əhatəsidir və uğursuz yerləşdirmələrin çoxunun arxasındakı iki boşluq məhz budur.

Nəyisə redaktə etməzdən əvvəl üç faktı kağıza yazın: WAN interfeysinin adı, LAN körpüsünün adı və VPN son nöqtəsinin ünvanı və portu. Qaydalarda üçünə də ehtiyacınız olacaq və interfeys adlarını təxmin etmək düzgün görünən qaydalar dəstinin heç nə etməməsinin ən çox yayılmış səbəbidir.

Paketin keçə biləcəyi üç yolu gəzin

Laptopdan internetə trafik yönləndirilir, ona görə də FORWARD zəncirindən keçir. Routerin özünün yaratdığı trafik, məsələn DNS yönləndirməsi, NTP sorğuları, DDNS yeniləmələri və VPN idarə kanalı, OUTPUT-dan keçir. Routerə ünvanlanmış idarəetmə trafiki INPUT-dan gəlir.

Buna görə yalnız FORWARD-da qurulmuş kill switch müştəriləri qoruyur, başqa heç nəyi yox. Cədvəl açılış səhnəsindəki sızmanın sirli deyil, proqnozlaşdırıla bilən olduğunu göstərir.

Əksər dizaynlarda INPUT-da kill switch lazım deyil, amma tunel düşdüyü zaman idarəetmə girişini işlək saxlamaq lazımdır. Əks halda VPN ilk dəfə sıradan çıxanda konsol kabeli ilə ofisə sürürsünüz.

Qaydaları tunel yenə qalxa biləcək şəkildə sıralayın

İşlək kill switch reject ilə bitən icazə siyahısıdır və onu kərpicdən fərqləndirən şey sıralamadır. Əvvəlcə loopback, VPN son nöqtəsi, mövcud axınlar üçün cavablar və tunel interfeysinə icazə verin; qalanı sonuncu olaraq rədd edin.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Son nöqtə bu mərhələdə host adı deyil, ünvan olmalıdır. Son reject DNS-i blokladıqdan sonra provayderin host adını göstərən qayda artıq həll oluna bilməz və tunel yenidən yükləmədən sonra bir daha başlamaz. Provayder son nöqtələri rotasiya edirsə, siyasət tətbiq olunmadan əvvəl adı həll edin və həmin qaydayı eyni skriptdən yeniləyin.

Müştəri trafiki üçün forması FORWARD-da təkrarlayın və reject-in üstünə açıq idarəetmə qaydası qoyun. Bu idarəetmə qaydasını dar, lakin əlçatan saxlayın və birinci SSH sessiyasını bağlamazdan əvvəl ikinci sessiya açaraq onu təsdiqləyin. Kill-switch dəyişikliyi zamanı özünüzü kilidləmək planlaşdırılacaq qədər adi haldır. WireGuard işlədən routerdə peer-in allowed-ips dəyərləri tunelə nəyin girdiyini, bu qaydalar isə onsuz nəyə icazə verildiyini həll edir.

IPv6-nın öz qapısı lazımdır

Yuxarıdakıların hamısı IPv4-dür. Əgər LAN-ınızda işlək IPv6 varsa və tunel yalnız IPv4 daşıyırsa, əhatə olunmuş hər cihazın hələ də yeni qaydalarınızın heç vaxt görmədiyi birbaşa internet marşrutu var. İkili stekli laptop onu məmnuniyyətlə üstün tutacaq və kill switch yalnız IPv4 ilə sınaqdan keçirən adama sınıq görünəcək.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Burada da sıra vacibdir: loopback icazəsi WAN rəddindən əvvəl gəlməlidir, əks halda routerdəki yerli xidmətlər qəribə şəkildə sıradan çıxmağa başlayır. Əgər şəbəkə ümumiyyətlə IPv6 işlətmir, onu WAN və LAN-da söndürmək daha sadədir və unudulacaq heç nə qoymur.

Bəzi VPN müştəriləri yalnız IPv4 üçün standart marşrut quraşdırır və mövcud IPv6 standartını toxunulmaz qoyur. Tunel qoşulduqdan sonra müştərinin bunu həll etdiyini fərz etmək əvəzinə marşrut cədvəlini yoxlayın.

Tunel bağlı ikən bunu sübut edin

Tuneli routerdən dayandırın və üç yerdən bu sıra ilə sınaqdan keçirin:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Marşrut axtarışı paketin hara gedəcəyini, sayğaclar isə qaydalarınızın heç uyğun gəlib-gəlmədiyini göstərir. Uğursuz sınaqdan sonra sıfır paketli qayda heç nəyi qorumur və adi səbəb yazdığınızdan fərqli interfeys adıdır. Router tərəfindən yaradılan trafiki açıq şəkildə sınayın, çünki LAN tərəfindən edilən sınaq OUTPUT-u işə sala bilməz.

Uğursuzluq rejimini ona ehtiyac duymazdan əvvəl qərarlaşdırın. Fail-closed tunel qayıdana qədər müştəriləri oflayn saxlayır; fail-open adi WAN girişini bərpa edir və əhəmiyyət verdiyiniz trafik üçün məqsədi puça çıxarır. Yüksək metrikli VPN hovuzuna blackhole marşrutu fail-closed dizaynlar üçün faydalı ikinci təbəqədir, çünki standart marşruta düşmək əvəzinə tunel marşrutu yox olduqda da qalır.

Qurulumu yalnız LAN müştərisi, router tərəfindən yaradılan sorğu və IPv6 sorğusu tunel bağlı ikən hamısı uğursuz olduqda və tunel qalxdıqdan sonra üçü də yenə işlədikdə qəbul edin.