VPN är ansluten men brandväggen blockerar fortfarande: så avgör du vilken

Tunneln är uppe och en port misslyckas fortfarande. Läs vägen, sedan policyn på varje lager, och ändra den snävaste regeln i stället för att stänga av någon av de två kontrollerna.

Klienten säger ansluten, resursen vägrar fortfarande, och nästa vanliga steg är att stänga av något. De två kontrollerna i den meningen gör olika jobb: VPN bygger en väg för den täckta trafiken, och en brandvägg avgör per anslutning om trafiken får passera. En fungerande tunnel med en avvisande policy ser exakt ut som en trasig tunnel från användarens stol, så uppgiften är att ta reda på vilket lager som svarar. Här är ordningen jag följer, med läsningen som säger åt dig att stanna.

Separera vägen från policyn

Börja med felets form, för det är gratis information. Ett tappat paket ger timeout: klienten försöker igen, inget kommer tillbaka och kommandot hänger tills det ger upp. En avvisning ger en nekning eller en reset: något svarade och sa nej. En tjänst som inte lyssnar avvisar på själva värden, helt utan brandvägg.

Dessa tre utfall pekar på olika lager. Timeout betyder att en policy någonstans tyst kastar, eller att vägen aldrig lämnar maskinen. Avvisad betyder att du nådde värden och att dess stack eller lokala brandvägg sa nej. Fullständig tystnad, med tunnelns gränssnitt uppe och ingen väg till målet, betyder att vägen är fel och ingen brandväggsregel rättar det.

Läs vägen i en enda genomgång

Bekräfta att tunneln täcker målet innan du tittar på en enda regel. En delad tunnel som bara bär kontorets subnät kommer inte att routa en begäran till ett annat intervall, och då ser felet ut som en brandväggsblockering som inte är det:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Rututskriften namnger gränssnittet paketet lämnar via och källadressen det bär. Om det gränssnittet är ditt fysiska nätverkskort och inte tunneln, ligger problemet i routningen eller i tunnelns tillåtna intervall, och det hör till VPN-konfigurationen och inte brandväggen.

En VPN-specifik fälla förtjänar sin egen kontroll. I WireGuard är AllowedIPs för en peer både en rutt och ett kryptografiskt filter: ett paket vars källadress inte passar peerens tillåtna mängd kastas innan någon brandväggsregel konsulteras. Så en helt korrekt värdbrandvägg kan stå bakom en tyst kastning som ser ut som en policy, och rättelsen är en konfigurationsrad för nyckeln, inte en regel.

Läs policyn på det lager som svarar

När vägen är rätt, gå igenom policyn från värden och utåt och håll koll på det enda lager vars räknare rör sig:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Den lyssnande socketen svarar på en annan fråga än reglerna. Om inget lyssnar på porten avvisas anslutningen av kärnan och ingen inkommande regel är relevant. Om socketen finns och anslutningen från en fjärrklient löper ut sker en kastning någonstans på vägen, och reglernas räknare säger om det sker här.

Slå på loggning för profilen eller kedjan du misstänker i stället för att gissa utifrån. En loggad kastning som namnger källa, mål och port identifierar lagret och regeln, och den bevisar också att paketet kom fram, vilket ingen test på klientsidan kan fastställa.

Läs gatewayens beslut när tunneln slutar där

På en gateway för plats-till-plats eller fjärråtkomst autentiserar VPN en användare och policyn auktoriserar en resurs, och det är separata tilldelningar. En användare som släpps in i tunneln släpps inte automatiskt in på varje intern värd, och avvisningen kommer ofta från en vidarebefordringsregel medan själva tunneln är frisk. Samma uppdelning finns i IPsec, där säkerhetspolicyn som väljer trafik skiljer sig från filtret som släpper in den, och därför är de två dokumenterade som olika mekanismer i RFC 4301.

Kontrollera returvägen lika noggrant som den utgående. Stateful filtrering måste se svaret, så asymmetrisk routning genom tunneln i en riktning och runt den i den andra ger kastningar som verkar slumpmässiga och bara upprepas från vissa klienter. Om trafiken når gatewayen och stannar, läs vidarebefordringsregeln och returvägen tillsammans innan du breddar något.

Gatewayen är också platsen där en NAT- eller maskeringsregel kan dölja den verkliga källan. Om interna värdar ser gatewayens adress i stället för klienten kommer deras värdbrandväggsregler som ska matcha klientpoolen aldrig att matcha, och rättelsen hör till gatewayen och inte till varje server.

Ändra det snävaste lagret och verifiera sedan

Motstå den breda reparationen. Att stänga av värdbrandväggen, lägga till en regel som tillåter allt eller tvinga varje gränssnitt in i en betrodd profil tar varje gång bort kontrollen som gjorde sitt jobb, och ändringen överlever incidenten. En regel begränsad till källintervallet och den aktuella porten är lättare att granska, lättare att ta bort och lämnar resten av maskinens policy intakt.

Verifiera med samma test som misslyckades, från samma klient, och sedan en gång till efter återanslutning, eftersom en regel som matchar innan tunneln förhandlar om kan sluta matcha efteråt:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Innan du stänger det:

  • Vägen till målet lämnar via tunnelns gränssnitt, och källadressen stämmer med vad policyn förväntar sig.
  • Något lyssnar på porten, och avvisningen eller timeouten tillskrivs en namngiven regel i stället för att antas.
  • Gatewayen vidarebefordrar i båda riktningarna, och målet ser den källa som dina regler skrevs för.
  • Ingen kontroll stängdes av för att testet skulle passera, och ändringen du gjorde namnger ett källintervall och en port.

Relaterade artiklar