Blackhole-rutt kontra VPN-killswitch: vad var och en gör
En blackhole-rutt kastar matchande trafik och tvingar fram en stängd väg vid fel. Jämför dess omfattning och blinda fläckar med en killswitch baserad på paketfiltrering.
Ett paket lämnar en bärbar dator, når aldrig VPN-gatewayen, och ingen brandväggsräknare rör sig. Routtabellen har redan avgjort paketets öde: en blackhole-post matchade det och kärnan kastade det innan något gränssnitt såg det. Det beteendet är användbart när en destination ska misslyckas stängt, men det är en routingåtgärd med smal omfattning. Att behandla den som en fullständig killswitch är där konstruktioner går fel.
Vad kaståtgärden egentligen matchar
En routsökning väljer en tabell och sedan det längsta matchande prefixet i den. En blackhole-rutt är en vanlig post vars åtgärd är att kasta, så den påverkar bara paket som skulle ha valt den posten efter hela beslutet. Ändra tabellen med en policyregel, eller lägg till ett mer specifikt prefix, och kastningen gäller inte längre.
Därför är en blackholes omfattning exakt och lätt att beskriva: den täcker prefixet, i tabellen, för den adressfamiljen. Den täcker inte en destination som en annan tabell skulle vinna, och den täcker inte IPv6 bara för att IPv4-prefixet kastas.
ip route get visar beslutet innan du driftsätter något, inklusive tabellen och ruttypen. Att läsa den utskriften är snabbare än att sluta sig till från en misslyckad begäran vilken regel eller vilket prefix som verkade.
Blackhole är inte samma sak som unreachable eller prohibit
Linux erbjuder tre kastliknande ruttyper, och de skiljer sig i vad avsändaren observerar. En blackhole släpper paketet utan svar, så klienten ser en timeout. En unreachable-rutt returnerar ett ICMP unreachable-meddelande, så anslutningen misslyckas snabbt med ett värd- eller nätverksfel. En prohibit-rutt returnerar ett administrativt spärrfel, vilket ligger närmare ett medvetet policyavslag.
Välj det beteende du vill att applikationen ska se. En tyst kastning passar när du inte vill avslöja policyn, och ett omedelbart fel är bättre när användare behöver förstå varför en destination inte är tillgänglig. Att blanda typerna i ett nätverk ger supportärenden som beskriver samma policy som tre olika fel.
Anta inte att varje kastpost är utbytbar när du diagnostiserar en anslutning. Feltexten, tidpunkten och paketfångsten skiljer sig, och ruttypen i tabellen talar om vilken du tittar på. ip-route-handboken listar typerna och deras felbeteende.
Hur den jämförs med en killswitch
En killswitch är paketfiltrering: en brandväggsregel som kastar utgående trafik som skulle lämna utanför tunneln. En blackhole-rutt är ett vidarebefordransbeslut som fattas tidigare i stacken. Båda kan stoppa trafik, men de ser olika saker och missar olika fall.
| Mechanism | What it blocks | What it misses | How failure looks |
|---|---|---|---|
| Blackhole route | Destinations matching the prefix and table | Other tables, other address families, traffic with a different route | Silent timeout |
| Firewall kill switch | Egress not bound to the tunnel interface | Rules that are too broad can break the endpoint or DHCP | Dropped packets with counters |
| WireGuard AllowedIPs | Destinations not routed into the interface | Traffic that never enters the interface at all | No tunnel route, direct egress |
Täckning är där jämförelsen spelar roll. En brandvägg kan matcha ägare, port eller gränssnitt och blockera en applikation medan slutpunkten förblir nåbar; en rutt kan inte. Omvänt kan en rutt skicka ett helt prefix till kastning utan att något paketfilter laddas, vilket är användbart på ett minimalt system.
WireGuards AllowedIPs är kryptonyckelrouting, inte en brandvägg. Det avgör vilka destinationsprefix som accepteras i gränssnittet, och en profil som bara listar tunnelns subnät lämnar helt enkelt andra destinationer till den vanliga standardrutten. Därför använder fulltunnelprofiler 0.0.0.0/0 och därför installerar wg-quick också brandväggsregler när den kan.
Håll tunnelns slutpunkt utanför kastningen
Slutpunktens yttre adress måste förbli nåbar via det fysiska gränssnittet. En kastning som också fångar den adressen hindrar handskakningen från att gå ut, och tunneln kommer aldrig upp, vilket ser ut som ett VPN-fel snarare än en routingpolicy. Kontrollera rutten till slutpunkten före och efter ändringen.
Administrativ åtkomst hör till samma granskning. Om den enda vägen till routern eller klienten är tunneln kan en alltför bred kastning låsa dig ute från maskinen som skulle låta dig ta bort den. Håll en dokumenterad out-of-band-rutt, en konsol eller en tidsbestämd återställning.
IPv6 behöver en egen post och en egen granskning. En konstruktion som kastar IPv4 i en blackhole medan IPv6 lämnas på standardrutten läcker precis den trafik som policyn skulle stoppa, och felet är osynligt i ett test med bara IPv4.
Inför det med en timer och en återställning
Tillämpa rutten med en kort automatisk borttagning så att ett fel inte överlever en omstart. Kommandona nedan använder ett dokumentationsintervall; ersätt det med det prefix som din konstruktion faktiskt kastar:
sudo ip route replace blackhole 10.0.0.0/8
ip route get 10.1.2.3
sudo systemd-run --on-active=60 /sbin/ip route del blackhole 10.0.0.0/8Det andra kommandot bör rapportera blackhole-rutten och tabellen den kom från. Det tredje schemalägger borttagning om en minut, vilket är tillräckligt med tid för att bekräfta policyn och kort nog att återhämta sig från ett fel på en fjärrvärd. När beteendet är bekräftat, gör posten permanent genom samma konfigurationshantering som äger de andra rutterna.
Avsluta ändringen genom att registrera prefixet, tabellen, adressfamiljen och återställningsmetoden. En kastning är ett medvetet undantag i routingkonstruktionen, och nästa ingenjör måste veta vilken trafik den skulle stoppa innan hen avgör om den fortfarande hör dit.