VPN er forbundet, men firewallen blokerer stadig: sådan afgør du hvilken

Tunnelen kører, og én port fejler stadig. Læs ruten, derefter politikken på hvert lag, og ændr den snævreste regel i stedet for at slå en af de to kontroller fra.

Klienten siger forbundet, ressourcen afviser stadig, og det sædvanlige næste skridt er at slå noget fra. De to kontroller i den sætning gør forskellige ting: VPN'en bygger en rute for den dækkede trafik, og en firewall afgør for hver forbindelse, om trafikken må passere. En fungerende tunnel med en afvisende politik ser præcis ud som en brudt tunnel fra brugerens stol, så opgaven er at finde ud af, hvilket lag der svarer. Her er den rækkefølge, jeg følger, med den læsning der siger, at du skal stoppe.

Adskil ruten fra politikken

Begynd med fejlens form, for det er gratis information. Et tabt paket giver en timeout: klienten prøver igen, intet kommer tilbage, og kommandoen hænger, indtil den giver op. En afvisning giver en afvisning eller en nulstilling: noget svarede og sagde nej. En tjeneste, der ikke lytter, afviser på selve værten, helt uden firewall.

De tre udfald peger på forskellige lag. Timeout betyder, at en politik et sted kasserer tavst, eller at ruten aldrig forlader maskinen. Afvist betyder, at du nåede værten, og at dens stak eller dens lokale firewall sagde nej. Fuldstændig tavshed, med tunnelens grænseflade oppe og ingen rute til destinationen, betyder, at ruten er forkert, og ingen firewallregel kan rette det.

Læs ruten i ét gennemløb

Bekræft, at tunnelen dækker destinationen, før du ser på en enkelt regel. En opdelt tunnel, der kun bærer kontorets undernet, vil ikke rute en anmodning til et andet område, og så ser fejlen ud som en firewallblokering, der ikke er det:

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

Ruteoutputtet angiver den grænseflade, pakken vil forlade via, og den kildeadresse, den vil bære. Hvis den grænseflade er dit fysiske netkort og ikke tunnelen, er problemet routing eller tunnelens tilladte områder, og det hører til VPN-konfigurationen og ikke til firewallen.

En VPN-specifik fælde fortjener sin egen kontrol. I WireGuard er AllowedIPs for en peer både en rute og et kryptografisk filter: en pakke, hvis kildeadresse ikke matcher peerens tilladte mængde, kasseres, før nogen firewallregel bliver konsulteret. Så en fuldstændig korrekt vært-firewall kan stå bag et tavst kast, der ser ud som en politik, og rettelsen er en konfigurationslinje for nøglen og ikke en regel.

Læs politikken på det lag, der svarer

Når ruten er rigtig, gå gennem politikken fra værten og udad, og hold øje med det ene lag, hvis tællere flytter sig:

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

Den lyttende socket svarer på et andet spørgsmål end reglerne. Hvis intet lytter på porten, afvises forbindelsen af kernen, og ingen indgående regel er relevant. Hvis socketen findes, og forbindelsen fra en fjern klient udløber, sker der et kast et sted på ruten, og reglernes tællere fortæller, om det sker her.

Slå logning til for den profil eller kæde, du mistænker, i stedet for at gætte udefra. Et enkelt logget kast, der navngiver kilde, destination og port, identificerer laget og reglen, og det beviser også, at pakken nåede frem, hvilket ingen test på klientsiden kan fastslå.

Læs gatewayens beslutning, når tunnelen slutter der

På en site-to-site- eller fjernadgangsgateway autentificerer VPN'en en bruger, og politikken autoriserer en ressource, og det er særskilte tilladelser. En bruger, der lukkes ind i tunnelen, er ikke automatisk lukket ind til hver intern vært, og afvisningen kommer ofte fra en videresendelsesregel, mens tunnelen selv er sund. Den samme adskillelse findes i IPsec, hvor sikkerhedspolitikken, der vælger trafik, er forskellig fra filteret, der lukker den ind, og derfor er de to dokumenteret som forskellige mekanismer i RFC 4301.

Kontrollér returvejen lige så omhyggeligt som den udgående. Stateful filtrering skal se svaret, så asymmetrisk routing gennem tunnelen i en retning og uden om den i den anden giver kast, der ser tilfældige ud og kun gentages fra nogle klienter. Hvis trafikken når gatewayen og stopper, læs videresendelsesreglen og returruten sammen, før du udvider noget.

Gatewayen er også stedet, hvor en NAT- eller masquerade-regel kan skjule den rigtige kilde. Hvis interne værter ser gatewayens adresse i stedet for klienten, vil deres vært-firewallregler, der skal matche klientpuljen, aldrig matche, og rettelsen hører til gatewayen og ikke til hver server.

Ændr det snævreste lag, og verificér derefter

Modstå den brede reparation. At slå vært-firewallen fra, tilføje en regel, der tillader alt, eller tvinge hver grænseflade ind i en betroet profil fjerner hver gang den kontrol, der gjorde sit arbejde, og ændringen overlever hændelsen. En regel begrænset til kildeområdet og den pågældende port er lettere at gennemgå, lettere at fjerne og lader resten af maskinens politik være intakt.

Verificér med den samme test, der fejlede, fra den samme klient, og derefter en gang til efter en genopkobling, fordi en regel, der matcher før tunnelen forhandler igen, kan holde op med at matche efter:

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

Før du lukker sagen:

  • Ruten til destinationen forlader via tunnelens grænseflade, og kildeadressen matcher det, politikken forventer.
  • Noget lytter på porten, og afvisningen eller timeouten tilskrives en navngivet regel i stedet for at antages.
  • Gatewayen videresender i begge retninger, og destinationen ser den kilde, dine regler blev skrevet for.
  • Ingen kontrol blev slået fra for at få testen til at bestå, og den ændring, du lavede, navngiver ét kildeområde og én port.

Relaterede artikler