Noodskakelaar blokkeer net IPv4: waarom IPv6 steeds ontsnap

’n Versameling firewallreëls vir IPv4 sê niks oor IPv6 nie. Op ’n dubbelstapel-toestel kan die tonnel wegval terwyl ’n toepassing ’n werkende pad daaromheen hou.

Die tonnel val weg, die noodskakelaar rapporteer dat dit ingeskakel het, en ’n aflaai hou aan loop. Niks is fout met die IPv4-reëls nie. Die toepassing het bloot na ’n roete geskuif waarvoor daardie reëls nooit geskryf is nie.

Dubbelstapel-toestelle het twee onafhanklike uitweë. ’n Blok op een van hulle is ’n halwe blok.

Twee reëlversamelings, twee verstekke

Op Linux is iptables en ip6tables aparte tabelle met aparte beleide. Om die INPUT- en OUTPUT-kettings van die IPv4-tabel op DROP te stel, verander niks in die IPv6-tabel nie, waar die verstek gewoonlik ACCEPT is. Dieselfde verdeling bestaan in nftables, waar jy ’n familie kan ondersoek en vind dat net een van hulle jou reëls dra. Daardie asimmetrie is normaal, en dit is die hele probleem.

Dit is hoekom ’n noodskakelaar deeglik kan lyk en gedeeltelik kan optree. Die skrip wat die IPv4-reëls geskryf het, het geloop, die tellers verhoog, die logreël verskyn, en ’n IPv6-pakket verlaat die fisiese koppelvlak heeltemal onaangeraak.

Lees wat jou kliënt werklik installeer eerder as wat die bemarkingsblad belowe. Sommige kliënte stuur IPv6 in die tonnel in, sommige blokkeer dit doelbewus, en sommige laat dit alleen terwyl ’n platformvlak-afsluiting ’n ander reël afdwing. Die verskaffer se dokumentasie is die enigste bron wat hier werd is om te vertrou.

Wat die koppelvlakkonfigurasie jou vertel

wg-quick se handleiding sluit IPv6-reëls in sy voorbeeldkonfigurasie in, en die rede is presies hierdie gaping. Die voorbeeld is nie versiering nie. Dit bestaan omdat die IPv4-reëls alleen die tweede familie oop sou laat.

Om die helfte van ’n voorbeeld te kopieer, lewer die helfte van ’n beleid. Dit is die mees algemene oorsprong van hierdie lek. ’n Blogpos het die voorbeeld vir lengte ingekort. Die ingekorte weergawe het toe die sjabloon geword wat almal hergebruik het.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

As die tweede opdrag ’n toelatende beleid druk terwyl die eerste DROP druk, het jy die antwoord gevind sonder om aan die kliënt te raak. Daardie asimmetrie is die fout.

Waarom een opsoek nie die hele storie is nie

’n Enkele naam kan beide ’n A-rekord en ’n AAAA-rekord terugstuur, en toepassings kies nie almal dieselfde manier nie. ’n Blaaier kan IPv6 verkies wanneer die netwerk dit bied en by mislukking terugval, terwyl ’n agtergrondsinkronisering of ’n opdatering sy eie oplosser en sy eie voorkeur gebruik. Een suksesvolle toets oor IPv4 bewys dus een roete, nie die beleid nie.

Netwerkoorgange verander ook die antwoord. Om by ’n ander Wi-Fi-netwerk aan te sluit, uit die slaap te hervat of na sellulêr oor te skakel, kan die toestel ’n nuwe IPv6-voorvoegsel gee, en die beleid wat op die kantoor-LAN voldoende gelyk het, dek dit dalk nie.

Toets die toestand waarin die tonnel af is

Om terwyl jy gekoppel is te toets, sê vir jou die tonnel werk. Die interessante toets is die onbeskikbare toestand, want dit is wanneer die noodskakelaar veronderstel is om te hou. Stop die tonnel doelbewus, en probeer dan die bestemmings wat saak maak vanuit die toepassing wat jy beskerm.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Albei families behoort geslote te faal. As die IPv4-versoek uitloop en die IPv6-versoek ’n statuskode terugstuur, is die beleid onvolledig, en geen hoeveelheid hertoetsing van die tonnel sal dit verander nie.

Hou ook die gedokumenteerde uitsonderings in daardie toets. Plaaslike netwerkontdekking, ’n DHCP-hernuwing of die bootstrap-pad na die VPN-eindpunt kan bereikbaar moet bly, en daardie uitsonderings behoort in die beleid genoem te word eerder as tydens ’n onderbreking ontdek te word. ’n Lektoets wat misluk omdat die tonnel nie weer kan opkom nie, is nie ’n sekuriteitsbevinding nie, dit is ’n verbindingsbevinding.

Verwante artikels