Maršrutētāja kill switch, kas aptver FORWARD, OUTPUT un IPv6

Jūs piesakāties maršrutētājā, ielīmējat kill switch noteikumu kopu no foruma ziņas, un LAN pārstāj pārlūkot tajā mirklī, kad tunelis nokrīt. Divas dienas vēlāk maršrutētājs joprojām atjaunina savu dinamisko DNS ierakstu pa parasto WAN, un viesu portatīvais joprojām sasniedz IPv6 vietnes. Abas uzvedības ir normālas, jo ielīmētie noteikumi aptvēra vienu ķēdi un vienu adrešu saimi, un neviens no tiem nav viss maršrutētājs. Pakešu ceļu iziešana secībā precīzi parāda, kas tika izlaists.

Sāciet pie maršrutētāja, nevis pie portatīvā

Politika maršrutētāja līmenī ir pievilcīga mazam birojam, jo katra ierīce aiz tā pārmanto vienu un to pašu uzvedību un neviens nevar aizmirst ieslēgt klienta slēdzi. Tā arī dod vienu vietu pārbaudei pēc katras programmaparatūras atjaunināšanas. Ko tā nedod, ir automātisks maršrutētāja paša datplūsmas vai otras adrešu saimes pārklājums, un tie ir divi trūkumi aiz lielākās daļas neveiksmīgo ieviešanu.

Pirms kaut ko maināt, pierakstiet uz papīra trīs faktus: WAN saskarnes nosaukumu, LAN tilta nosaukumu un VPN galapunkta adresi un portu. Visi trīs būs vajadzīgi noteikumos, un saskarņu nosaukumu minēšana ir visizplatītākais iemesls, kāpēc pareizi izskatošs noteikumu kopums neko nedara.

Izejiet cauri trim ceļiem, kurus pakete var iet

Datplūsma no portatīvā uz internetu tiek pārsūtīta, tāpēc tā iet caur FORWARD ķēdi. Datplūsma, ko maršrutētājs ģenerē pats, piemēram, DNS pārsūtīšana, NTP vaicājumi, DDNS atjauninājumi un VPN vadības kanāls, iet caur OUTPUT. Maršrutētājam adresētā pārvaldības datplūsma nāk caur INPUT.

Tātad kill switch, kas uzbūvēts tikai FORWARD, aizsargā klientus un neko citu. Tabula parāda, kāpēc noplūde sākuma ainā ir paredzama, nevis noslēpumaina.

Lielākajā daļā projektējumu jums nav vajadzīgs kill switch uz INPUT, bet jums ir jāuztur pārvaldības piekļuve darbībā, kamēr tunelis ir izslēgts. Citādi pirmajā VPN atteices reizē jūs brauksiet uz biroju ar konsoles kabeli.

Sakārtojiet noteikumus tā, lai tunelis vēl varētu pacelties

Strādājošs kill switch ir atļauju saraksts, kas beidzas ar noraidīšanu, un secība padara to par kill switch, nevis ķieģeli. Vispirms atļaujiet loopback, VPN galapunktu, atbildes jau izveidotām plūsmām un tuneļa saskarni; pārējo noraidiet pēdējo.

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

Galapunktam šajā vietā jābūt adresei, nevis resursdatora nosaukumam. Kad galīgā noraidīšana bloķē DNS, noteikumu, kurā nosaukts pakalpojumu sniedzēja resursdatora nosaukums, vairs nevar atrisināt, un tunelis pēc pārstartēšanas vairs nekad neieslēdzas. Ja sniedzējs maina galapunktus, atrisiniet nosaukumu pirms politikas piemērošanas un atsvaidziniet šo noteikumu no tā paša skripta.

Atkārtojiet formu FORWARD klientu datplūsmai un novietojiet skaidru pārvaldības noteikumu virs noraidīšanas. Turiet šo pārvaldības noteikumu šauru, bet sasniedzamu, un apstipriniet to, atverot otru SSH sesiju pirms pirmās aizvēršanas. Aizslēgšanās kill switch maiņas laikā ir pietiekami izplatīta, lai to plānotu. Maršrutētājā ar WireGuard vienaudža allowed-ips nosaka, kas nonāk tunelī, bet šie noteikumi nosaka, kam atļauts iziet bez tā.

IPv6 vajadzīgas savas durvis

Viss iepriekš minētais ir IPv4. Ja jūsu LAN darbojas IPv6 un tunelis pārvadā tikai IPv4, katrai pārklātajai ierīcei joprojām ir tiešs maršruts uz internetu, ko jūsu jaunie noteikumi nekad neredz. Divu protokolu portatīvais to labprāt izvēlēsies, un kill switch izskatīsies salūzis tikai tam, kurš pārbauda ar IPv4.

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

Arī šeit svarīga ir secība: loopback atļaujai jābūt pirms WAN noraidīšanas, citādi vietējie pakalpojumi maršrutētājā sāks dīvaini sabojāties. Ja tīkls vispār neizmanto IPv6, to izslēgt WAN un LAN ir vienkāršāk, un nekas nepaliek aizmirstams.

Daži VPN klienti instalē noklusējuma maršrutu tikai IPv4 un atstāj esošo IPv6 noklusējuma maršrutu neskartu. Pārbaudiet maršrutēšanas tabulu pēc tam, kad tunelis ir izveidojis savienojumu, nevis pieņemiet, ka klients to ir atrisinājis.

Pierādiet to ar izslēgtu tuneli

Apturiet tuneli no maršrutētāja un pārbaudiet no trim vietām šādā secībā:

# 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šruta meklēšana parāda, kur pakete dotos, un skaitītāji parāda, vai jūsu noteikumi kādreiz ir saskanējuši. Noteikums ar nulli pakešu pēc neveiksmīgas pārbaudes neko neaizsargā, un parastais iemesls ir saskarnes nosaukums, kas atšķiras no ievadītā. Pārbaudiet maršrutētāja ģenerēto datplūsmu skaidri, jo pārbaude no LAN puses nevar iedarbināt OUTPUT.

Izlemiet atteices režīmu pirms tā jums vajadzīgs. Fail-closed tur klientus bezsaistē, līdz tunelis atgriežas; fail-open atjauno parasto WAN piekļuvi un iznīcina mērķi tai datplūsmai, kas jums rūpēja. Blackhole maršruts uz VPN baseinu ar augstu metrikas vērtību ir noderīgs otrais slānis fail-closed projektiem, jo tas izdzīvo, kad tuneļa maršruts pazūd, nevis atkrīt uz noklusējuma.

Pieņemiet iestatījumu tikai tad, kad LAN klients, maršrutētāja ģenerēts pieprasījums un IPv6 pieprasījums visi neizdodas ar izslēgtu tuneli, un visi trīs atkal darbojas, kad tas ir ieslēgts.