Kill switch bloķē VPN serveri, pirms plūst jebkurš trafiks
Kuru posmu bloķē kill switch: galapunkta meklēšanu, ārējo maršrutu, atgriešanās ceļu un novecojušus pāra izņēmumus — ar skaitītājiem, nevis minējumiem.
Kill switch neizdodas virzienā, ko cilvēki negaida: tie ir būvēti, lai bloķētu trafiku, kamēr tunelis ir izslēgts, un paketes, kas būvē tuneli, pašas ir trafiks. Tā ir visa kļūda. Noteikumu kopums, kas izmet visu, kas neiziet caur tuneli, izmet arī to roku saspišanu, kam tas būtu jāpaceļ, tāpēc klients atkārto cilpā, un kļūda tiek attiecināta uz to posmu, kas tiek pārbaudīts pirmais. Pirms paplašināt ugunsmūri, noskaidrojiet, kurš no trim posmiem tiek noraidīts: vārda meklēšana, ārējā pakete uz pāri vai atbilde, kas atgriežas.
Kā tunelis un tā paša transports ir atkarīgi viens no otra
Lasiet VPN klientu kā divus tīkla stāvokļus, kas dala vienu ligzdas ceļu. Pirms tuneļa pastāvēšanas klients atver ligzdu fiziskajā adapterī un sūta šifrētus kadrus uz pāra adresi un portu. Tikai pēc tam, kad šī apmaiņa izdodas, tas izveido tuneļa ierīci un instalē maršrutus. Kill switch ir politika par otro stāvokli, uzrakstīta tik plaši, ka attiecas uz abiem.
Noteikumi, kuru pamatā ir saskarne, ir ierastā forma: pieņemiet to, kas iziet caur tun0 vai wg0, izmetiet pārējo izejas ceļu. Šāds formulējums nevar atbrīvot paša klienta savienojumu ar serveri, tāpēc pareiza ieviešana šo izņēmumu pievieno skaidri, un arī jūs, kad rakstāt noteikumus ar roku. Noteikumi katrai lietotnei operētājsistēmās Windows un macOS apiet daļu no tā, saskaņojot procesu, nevis saskarni, bet procesam tomēr jātiek ārā, pirms tunelis pastāv.
Trīs posmi tādā secībā, kādā tie notiek
Pirmais posms ir atrisināšana. Kad profils glabā resursdatora vārdu, nevis burtisku adresi, klientam pirms kaut kā sūtīšanas ir vajadzīga DNS atbilde. Profils, kas novirza DNS uz tuneļa atrisinātāju, rada strupceļu: atrisinātājs ir pieejams tikai caur tuneli, kuru meklēšanai būtu jāiespējo. Atrisināšana ārpus tuneļa vai galapunkta piesaistīšana adresei novērš šo neskaidrību.
Otrais posms ir ārējā pakete, kurai šajā secībā vispirms jāiztur maršrutēšana un pēc tam ugunsmūris. wireguard-tools veic maršrutēšanas pusi WireGuard labā, atzīmējot savas paketes un pievienojot politikas noteikumu, lai tās izlaistu tikko instalēto noklusējuma maršrutu; wg-quick rokasgrāmatas lapa apraksta šo noteikumu un tabulu, ko tas izmanto. Atjaunojiet šo maršrutēšanu ar roku vai ļaujiet otram rīkam pārrakstīt noteikumus, un atzīmētās paketes var tikt nosūtītas atpakaļ tunelī, ko tām būtu jāizveido.
Trešais posms ir atgriešanās ceļš. Roku saspišana bez atbildes nav izmešanas izejā pierādījums; tā vienlīdz saskan ar servera ienākošo noteikumu vai NAT ierīci, kas aizmirsa kartējumu. Atdaliet to, pirms aiztiekat klientu.
| 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 |
Klienti reģistrē konstatēto simptomu, nevis neizdevušos posmu, tāpēc tabula parasti ir ātrāka par žurnālu.
Skaitītāji izlemj ātrāk nekā žurnāli
Linux, nft list ruleset vai iptables -vnL OUTPUT izdrukā pakešu skaitītāju katrai noteikumu rindai. Pieslēdzieties vienreiz, ļaujiet tam neizdoties, pēc tam vēlreiz nolasiet skaitītājus. Noteikums, kura skaitītājs ir pārvietojies, ir noteikums, kurā trāpīja roku saspišana; ja nekur nekas nav pārvietojies, pakete nekad nav sasniegusi ugunsmūri. Esmu redzējis noteikumu kopumu izmetam savu paša roku saspišanu, un to pateica tikai skaitītāji.
Lai atšķirtu nekad nesasniedza ugunsmūri no nekad neizgāja no resursdatora, vērojiet pašu saskarni. ip -s link show dev wlan0 ziņo par nosūtītajām paketēm, un tcpdump -ni wlan0 udp port 51820 parāda kadrus. Ja tas paliek plakans, kamēr klients atkārto, kļūme ir virs netfilter: trūkst pāra maršruta, politikas noteikums norāda uz ierīci, kas vēl neeksistē, vai ligzdas kļūda, ko klients norij.
Pārbaudiet izņēmumus ar dokumentācijas adresēm, piemēram, 203.0.113.10, lai pārskatīšanās nevarētu zondēt kāda cita resursdatoru.
Novecojis galapunkta izņēmums tiek lasīts kā servera kļūme
Visvairāk maldinošā versija parādās pēc tam, kad mainījusies pāra adrese: dinamisko adrešu serviss to pārvietoja, resursdators tika pārbūvēts vai jūsu tīkla izejas adrese ir cita. Izņēmums joprojām nosauc veco adresi, tāpēc paketes uz jauno trāpa izmešanas noteikumā. Tā pati konfigurācija vakar strādāja, tāpēc cilvēki sāk ar servera diagnostiku.
Resursdatora vārds ugunsmūra noteikumā jūs neglābj. nftables gadījumā vārds tiek atrisināts, ielādējot noteikumu kopumu, tāpēc tas fiksē to adresi, kas tajā brīdī pastāvēja, un noveco kā burtisks. Ilgstošs risinājums ir atjaunināt izņēmumu, kad mainās galapunkts, un turēt to šauru: viena pāra adrese, viens transporta ports. Diapazons, kas ir pietiekami plats, lai izturētu adreses maiņu, ir pietiekami plats arī nesaistīta trafika izlaišanai.
Kad kill switch darbojas servera resursdatorā
Tā pati atkarība ir otrā galā, un tur to ir vieglāk palaist garām. Ja mašīna, kas darbojas kā jūsu VPN serveris, arī izpilda galddatora klientu ar kill switch vai ugunsmūra profilu, kas nokopēts no portatīvā datora, tās izmešanas noteikumi attiecas uz servisu, kas pabeidz tuneļus. Atbildes uz klienta roku saspišanu tiek izmestas, tāpēc katrs klients nevar savienoties, kamēr serveris izskatās vesels un tā tuneļa saskarne stāv neizmantota.
Šim resursdatoram pirms izmešanas vajag trīs šaurus pieņemšanas gadījumus: klausīšanās portu fiziskajā saskarnē, tuneļa saskarni atšifrētam trafikam un pāradresāciju no tuneļa uz to, kam klientiem jāpiekļūst. Nolasiet instalēto kopumu ar nft list ruleset, iptables -S, vai pfctl -sr , pirms kaut ko maināt, un atcerieties, ka saglabāts noteikumu kopums pārdzīvo pārstartēšanu, tāpēc kļūda tur pārdzīvo procesu, kas to izveidoja.
Atjaunošanas secība, kas tur mašīnu aizvērtu
Strādājiet no profila uz āru. Nolasiet pāra adresi un portu, ko izmanto klients, apstipriniet, ka resursdatora vārds tiek atrisināts bez tuneļa, pēc tam pievienojiet vienu izņēmumu šai adresei un portam tikai fiziskajā adapterī. Pieslēdzieties vēlreiz un vērojiet sūtīšanas skaitītāju; pabeigta roku saspišana ir signāls, ka otrais posms ir salabots.
Testēšanas laikā atstājiet pārējo izmešanas politiku savā vietā. Nekaitīga pārbaude ir mēģināt savienojumu ar nesaistītu dokumentācijas adresi un apstiprināt, ka tas joprojām beidzas ar taimautu, kas parāda, ka kill switch darbojas, nevis ir izslēgts. Savelciet izņēmumu, kad tunelis ir stabils, un neatstājiet pastāvīgu visu atļauju klienta programmai tikai tāpēc, ka tas ir ērti.
Ja tunelis paceļas un lietotne joprojām neizdodas, atlikušie posmi nav šis: sadalītais DNS, MTU un maršrutēšana katrai lietotnei katrs rada savienotu tuneli ar salauztu trafiku, un katram ir cita pirmā pārbaude.