Kill switch-ak VPN zerbitzaria blokeatzen du trafikoa hasi aurretik
Zein etapatan blokeatzen duen kill switch-ak: amaierako puntuaren bilaketa, kanpoko ibilbidea, itzulera-bidea eta pareen salbuespen zaharkituak — asmatu beharrean kontagailuekin.
Kill switch-ek ustekabeko norabidean huts egiten dute: tunela behera dagoen bitartean trafikoa blokeatzeko eraikiak daude, eta tunela eraikitzen duten paketeak trafiko dira berez. Hori da akats osoa. Tunelatik irteten ez den guztia botatzen duen arau-multzo batek tunela igoko lukeen esku-ematea ere botatzen du, beraz bezeroak begiztan berriro saiatzen da eta errorea lehenengo egiaztatzen den etapari egozten zaio. Suhorma zabaldu aurretik, jakin ezazu hiru etapetatik zein ukatzen den: izenaren bilaketa, parearekiko kanpoko paketea edo itzultzen den erantzuna.
Nola mendekotasun duten tuneleak eta bere garraioak elkarrengandik
Irakurri VPN bezeroa socket bide bat partekatzen duten bi sare-egoera gisa. Tunela existitu aurretik, bezeroak socket bat irekitzen du adaptagailu fisikoan eta marko zifratuak bidaltzen dizkio parearen helbide eta atakari. Truke hori lortzen denean soilik sortzen du tunel gailua eta instalatzen ditu ibilbideak. Kill switch bat bigarren egoerari buruzko politika da, hain zabal idatzia non biei aplikatzen zaien.
Interfazean oinarritutako arauak dira ohiko forma: onartu tun0 edo wg0 bidez irteten dena, baztertu irteera-bidearen gainerakoa. Formulazio horrek ezin du bezeroak zerbitzariarekin duen konexioa salbuetsi, beraz ezarpen zuzen batek salbuespen hori berariaz gehitzen du, eta zuk ere bai arauak eskuz idazten dituzunean. Windows eta macOS-en aplikazio bakoitzeko arauek horren zati bat saihesten dute interfazearen ordez prozesua bat etorraraziz, baina prozesuak oraindik irten behar du tunela existitu aurretik.
Hiru etapa, gertatzen diren ordenan
Lehen etapa ebazpena da. Profilak helbide literalaren ordez ostalari-izena gordetzen duenean, bezeroak DNS erantzun bat behar du ezer bidali aurretik. DNS tunelaren ebazleera bideratzen duen profilek blokeo bat sortzen du: ebazlea soilik da irisgarri bilaketak gaitu beharko lukeen tunelaren bidez. Tunelatik kanpo ebaztea, edo amaierako puntua helbide batera finkatzea, anbiguotasuna ezabatzen du.
Bigarren etapa kanpoko paketea da, ordena horretan bideratzea eta gero suhorma gainditu behar dituena. wireguard-tools-ek bideratzearen erdia egiten du WireGuard-entzat bere paketeak markatuz eta politika-arau bat gehituz, instalatu berri duen ibilbide lehenetsia saltatzeko; wg-quick-en eskuliburuko orria arau hori eta erabiltzen duen taula deskribatzen ditu. Berreraiki bideratze hori eskuz, edo utzi bigarren tresna bati arauak berridazten, eta markatutako paketeak sortu behar duten tunelera itzul daitezke.
Hirugarren etapa itzulera-bidea da. Erantzunik gabeko esku-ematea ez da irteerako baztertze baten froga; berdin bateragarria da zerbitzariaren sarrerako arau batekin edo mapaketa ahaztu duen NAT gailu batekin. Bereizi horiek bezeroa ukitu aurretik.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Bezeroek detektatzen duten sintoma erregistratzen dute, huts egin duen etapa ez, beraz taula normalean erregistroa baino azkarragoa da.
Kontagailuek erregistroek baino azkarrago erabakitzen dute
Linux-en, nft list ruleset edo iptables -vnL OUTPUT kontagailu bat inprimatzen du arau bakoitzeko. Konektatu behin, utzi huts egiten eta gero irakurri berriro kontagailuak. Kontagailua mugitu zaion araua esku-emateak jo duen araua da; inon ezer mugitu ez bada, paketea ez da inoiz suhormara iritsi. Arau-multzo batek bere esku-ematea bota zuela ikusi dut, eta kontagailuek soilik esan zuten.
Suhormara inoiz iritsi ez dena ostalariatik inoiz irten ez denetik bereizteko, begiratu interfazea bera. ip -s link show dev wlan0 bidalitako paketeen berri ematen du, eta tcpdump -ni wlan0 udp port 51820 markoak erakusten ditu. Bezeroa berriro saiatzen ari den bitartean laua geratzen bada, akatsa netfilterren gainetik dago: faltan den parearen ibilbidea, oraindik existitzen ez den gailu batera seinalatzen duen politika-araua, edo bezeroak irensten duen socket errore bat.
Probatu salbuespenak dokumentazio-helbideekin, adibidez 203.0.113.10, hutsegite batek beste norbaiten ostalaria miatu ez dezan.
Amaierako puntuaren salbuespen zaharkitu bat zerbitzariaren erorketa bezala irakurtzen da
Bertsio engainagarriena parearen helbidea aldatu ondoren agertzen da: helbide dinamikoen zerbitzu batek mugitu du, ostalaria berreraiki da, edo zure sarearen irteera-helbidea desberdina da. Salbuespenak oraindik helbide zaharra izendatzen du, beraz berrira doazen paketeak baztertze-arauan erortzen dira. Konfigurazio berak atzo funtzionatu zuen, eta horregatik jendea zerbitzariaren diagnostikoarekin hasten da.
Suhormaren arau baten barruko ostalari-izenak ez zaitu salbatzen. nftables-en izena arau-multzoa kargatzean ebazten da, beraz une horretan zegoen helbidea finkatzen du eta literal bat bezala zaharkitzen da. Konponbide iraunkorra amaierako puntua aldatzean salbuespena eguneratzea eta estua mantentzea da: pare-helbide bat, garraio-ata bat. Helbide-aldaketa bat bizirauteko bezain zabala den tartea ere nahikoa zabala da lotu gabeko trafikoa kanporatzeko.
Kill switch-a zerbitzariaren ostalarian exekutatzen denean
Mendekotasun bera dago beste muturrean, eta han errazagoa da ahaztea. Zure VPN zerbitzari gisa diharduen makinak kill switch-a duen mahaigaineko bezero bat edo eramangarri batetik kopiatutako suhorma-profil bat ere exekutatzen badu, bere baztertze-arauak tuneleak amaitzen dituen zerbitzuari aplikatzen zaizkio. Bezeroaren esku-emateari erantzunak baztertzen dira, beraz bezero guztiek ezin dute konektatu zerbitzaria osasuntsu agertzen den bitartean eta bere tunel-interfazea erabili gabe geratzen da.
Ostalari horrek hiru onarpen estu behar ditu baztertu aurretik: entzute-ata interfaze fisikoan, tunel-interfazea deskifratutako trafikorako, eta tuneletik bezeroek iritsi behar dutenerako birbidalketa. Irakurri instalatutako multzoa nft list ruleset, iptables -S, edo pfctl -sr erabiliz, ezer aldatu aurretik, eta gogoratu gordetako arau-multzo batek berrabiaraztea gainditzen duela, beraz hango hutsegite batek egin zuen prozesua gainditzen du.
Makina itxita mantentzen duen berreskuratze-ordena
Lan egin profiletik kanpora. Irakurri bezeroak erabiltzen duen parearen helbidea eta ataka, egiaztatu ostalari-izena tunelik gabe ebazten dela, eta gero gehitu helbide eta ataka horretarako salbuespen bat adaptagailu fisikoan soilik. Konektatu berriro eta begiratu bidalketa-kontagailua; osatutako esku-ematea bigarren etapa konpondu dela adierazten duen seinalea da.
Utzi baztertze-politikaren gainerakoa bere lekuan probatzen duzun bitartean. Egiaztapen kaltegabea da lotu gabeko dokumentazio-helbide batera konexioa saiatzea eta oraindik iraungitzen dela baieztatzea, eta horrek kill switch-a itzalita egon beharrean lanean ari dela erakusten du. Estutu salbuespena tunela egonkorra denean, eta ez utzi bezeroaren programarako betiko baimen osoa erosoa delako.
Tunela igotzen bada eta aplikazioak huts egiten jarraitzen badu, gainerako etapak ez dira hau: banatutako DNS, MTU eta aplikazio bakoitzeko bideratzeak bakoitzak tunel konektatu bat sortzen du trafiko hautsiekin, eta bakoitzak lehen egiaztapen desberdina du.