VPN verbonden maar de firewall blokkeert nog: hoe u bepaalt welke

De client zegt verbonden, de resource weigert nog steeds, en de gebruikelijke volgende stap is iets uitschakelen. De twee controles in die zin doen verschillend werk: de VPN bouwt een pad voor het gedekte verkeer, en een firewall beslist per verbinding of het verkeer mag passeren. Een werkende tunnel met een weigerend beleid ziet er vanaf de stoel van de gebruiker precies uit als een kapotte tunnel, dus de taak is uitzoeken welke laag antwoordt. Dit is de volgorde die ik aanhoud, met de lezing die u zegt te stoppen.

Scheid het pad van het beleid

Begin met de vorm van de fout, want dat is gratis informatie. Een weggevallen pakket geeft een time-out: de client probeert opnieuw, er komt niets terug en de opdracht blijft hangen tot hij opgeeft. Een weigering geeft een afwijzing of een reset: iets antwoordde en zei nee. Een dienst die niet luistert, weigert op de host zelf, zonder enige firewall.

Die drie uitkomsten wijzen op verschillende lagen. Time-out betekent dat ergens een beleid stilzwijgend weggooit, of dat het pad de machine nooit verlaat. Geweigerd betekent dat u de host bereikte en zijn stack of zijn lokale firewall nee zei. Volledige stilte, met de tunnelinterface omhoog en geen route naar de bestemming, betekent dat het pad fout is en geen firewallregel dat oplost.

Lees het pad in één doorloop

Bevestig dat de tunnel de bestemming dekt voordat u naar één regel kijkt. Een gesplitste tunnel die alleen het kantoorsubnet draagt, zal een verzoek niet naar een ander bereik routeren, en de fout lijkt dan op een firewallblokkade die het niet is:

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

De route-uitvoer noemt de interface waar het pakket via vertrekt en het bronadres dat het draagt. Als die interface uw fysieke netwerkkaart is en niet de tunnel, zit het probleem in de routering of in de toegestane bereiken van de tunnel, en het hoort bij de VPN-configuratie en niet bij de firewall.

Eén VPN-specifieke valkuil verdient een eigen controle. In WireGuard is AllowedIPs van een peer zowel een route als een cryptografisch filter: een pakket waarvan het bronadres niet in de toegestane set van de peer past, wordt weggegooid voordat enige firewallregel wordt geraadpleegd. Een volstrekt correcte hostfirewall kan dus achter een stille weggooiing staan die op beleid lijkt, en de oplossing is een configuratieregel voor de sleutel, niet een regel.

Lees het beleid op de laag die antwoordt

Als het pad klopt, loop het beleid van de host naar buiten door en let op de ene laag waarvan de tellers bewegen:

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

De luisterende socket beantwoordt een andere vraag dan de regels. Als er niets op de poort luistert, weigert de kernel de verbinding en is geen inkomende regel relevant. Als de socket bestaat en de verbinding van een externe client verloopt, gebeurt er ergens op het pad een weggooiing, en de tellers van de regels vertellen of het hier gebeurt.

Zet logging aan voor het profiel of de keten die u vermoedt in plaats van van buitenaf te raden. Eén gelogde weggooiing die bron, bestemming en poort noemt, identificeert de laag en de regel, en bewijst ook dat het pakket aankwam, wat geen enkele test aan de clientzijde kan vaststellen.

Lees de beslissing van de gateway als de tunnel daar eindigt

Op een site-naar-site- of remote-accessgateway authenticeert de VPN een gebruiker en autoriseert het beleid een resource, en dat zijn aparte toekenningen. Een gebruiker die in de tunnel mag, mag niet automatisch op elke interne host, en de weigering komt vaak van een doorstuuregel terwijl de tunnel zelf gezond is. Dezelfde scheiding bestaat in IPsec, waar het beveiligingsbeleid dat verkeer selecteert verschilt van het filter dat het toelaat, en daarom zijn beide gedocumenteerd als verschillende mechanismen in RFC 4301.

Controleer de terugweg even zorgvuldig als de heenweg. Stateful filtering moet het antwoord zien, dus asymmetrische routering door de tunnel in de ene richting en eromheen in de andere geeft weggooiingen die willekeurig lijken en alleen vanaf sommige clients reproduceerbaar zijn. Als het verkeer de gateway bereikt en stopt, lees dan de doorstuuregel en de terugweg samen voordat u iets verbreedt.

De gateway is ook de plek waar een NAT- of masqueraderegel de echte bron kan verbergen. Als interne hosts het gatewayadres zien in plaats van de client, zullen hun hostfirewallregels die bij de clientpool moeten passen nooit passen, en de oplossing hoort bij de gateway en niet bij elke server.

Wijzig de smalste laag en verifieer daarna

Weerstaa de brede reparatie. De hostfirewall uitschakelen, een regel toevoegen die alles toestaat of elke interface in een vertrouwd profiel dwingen haalt telkens de controle weg die zijn werk deed, en de wijziging overleeft het incident. Een regel die beperkt is tot het bronbereik en de betrokken poort is makkelijker na te kijken, makkelijker te verwijderen en laat de rest van het beleid van de machine intact.

Verifieer met dezelfde test die faalde, vanaf dezelfde client, en daarna nog eens na opnieuw verbinden, omdat een regel die past voordat de tunnel opnieuw onderhandelt, daarna kan stoppen met passen:

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

Voordat u het afsluit:

• De route naar de bestemming verlaat de machine via de tunnelinterface, en het bronadres komt overeen met wat het beleid verwacht.
• Er luistert iets op de poort, en de weigering of time-out wordt aan een genoemde regel toegeschreven in plaats van aangenomen.
• De gateway stuurt in beide richtingen door, en de bestemming ziet de bron waarvoor uw regels zijn geschreven.
• Geen controle werd uitgeschakeld om de test te laten slagen, en de wijziging die u maakte noemt één bronbereik en één poort.