VPN er tilkoblet, men brannmuren blokkerer fortsatt: slik avgjør du hvilken

Tunnelen er oppe, og én port feiler fortsatt. Les veien, deretter policyen på hvert lag, og endre den smaleste regelen i stedet for å slå av en av de to kontrollene.

Klienten sier tilkoblet, ressursen avviser fortsatt, og det vanlige neste steget er å slå av noe. De to kontrollene i den setningen gjør ulike jobber: VPN bygger en vei for den dekkede trafikken, og en brannmur avgjør per tilkobling om trafikken får passere. En fungerende tunnel med en avvisende policy ser nøyaktig ut som en ødelagt tunnel fra brukerens stol, så oppgaven er å finne ut hvilket lag som svarer. Her er rekkefølgen jeg følger, med lesningen som sier at du skal stoppe.

Skill veien fra policyen

Begynn med feilens form, for det er gratis informasjon. En droppet pakke gir timeout: klienten prøver igjen, ingenting kommer tilbake, og kommandoen henger til den gir opp. En avvisning gir en nektelse eller en reset: noe svarte og sa nei. En tjeneste som ikke lytter, avviser på selve verten, helt uten brannmur.

Disse tre utfallene peker på ulike lag. Timeout betyr at en policy et sted forkaster stille, eller at veien aldri forlater maskinen. Avvist betyr at du nådde verten, og at stakken eller den lokale brannmuren sa nei. Fullstendig stillhet, med tunellgrensesnittet oppe og ingen vei til målet, betyr at veien er feil og ingen brannmurregel retter det.

Les veien i ett gjennomløp

Bekreft at tunnelen dekker målet før du ser på en eneste regel. En delt tunnel som bare bærer kontorets subnett vil ikke rute en forespørsel til et annet område, og da ser feilen ut som en brannmurblokkering som ikke er det:

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

Ruteutskriften navngir grensesnittet pakken vil forlate via og kildeadressen den vil bære. Hvis det grensesnittet er det fysiske nettkortet ditt og ikke tunnelen, er problemet i rutingen eller i tunnelens tillatte områder, og det hører til VPN-konfigurasjonen og ikke brannmuren.

Én VPN-spesifikk felle fortjener sin egen sjekk. I WireGuard er AllowedIPs for en peer både en rute og et kryptografisk filter: en pakke hvis kildeadresse ikke passer i peerens tillatte sett, forkastes før noen brannmurregel blir konsultert. Så en helt korrekt vertsbrannmur kan stå bak en stille forkastelse som ser ut som en policy, og rettelsen er en konfigurasjonslinje for nøkkelen, ikke en regel.

Les policyen på laget som svarer

Når veien er riktig, gå gjennom policyen fra verten og utover, og følg med på det ene laget der tellerne beveger seg:

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

Den lyttende sockelen svarer på et annet spørsmål enn reglene. Hvis ingenting lytter på porten, avvises tilkoblingen av kjernen, og ingen inngående regel er relevant. Hvis sockelen finnes og tilkoblingen fra en ekstern klient går ut på tid, skjer en forkastelse et sted på veien, og reglenes tellere forteller om det skjer her.

Slå på logging for profilen eller kjeden du mistenker, i stedet for å gjette utenfra. Én logget forkastelse som navngir kilde, mål og port identifiserer laget og regelen, og den beviser også at pakken kom fram, noe ingen test på klientsiden kan fastslå.

Les gatewayens beslutning når tunnelen ender der

På en gateway for nettsted-til-nettsted eller fjern tilgang autentiserer VPN en bruker, og policyen autoriserer en ressurs, og det er separate tildelinger. En bruker som er sluppet inn i tunnelen, er ikke automatisk sluppet inn på hver intern vert, og avvisningen kommer ofte fra en videresendingsregel mens selve tunnelen er sunn. Den samme delingen finnes i IPsec, der sikkerhetspolicyen som velger trafikk er forskjellig fra filteret som slipper den inn, og derfor er de to dokumentert som ulike mekanismer i RFC 4301.

Sjekk returveien like grundig som den utgående. Stateful filtrering må se svaret, så asymmetrisk ruting gjennom tunnelen i én retning og rundt den i den andre gir forkastelser som virker tilfeldige og bare gjentas fra noen klienter. Hvis trafikken når gatewayen og stopper, les videresendingsregelen og returveien sammen før du utvider noe.

Gatewayen er også stedet der en NAT- eller maskeringsregel kan skjule den virkelige kilden. Hvis interne verter ser gatewayadressen i stedet for klienten, vil deres vertsbrannmurregler som skal passe klientgruppen aldri passe, og rettelsen hører til gatewayen og ikke hver server.

Endre det smaleste laget, og verifiser deretter

Motstå den brede reparasjonen. Å slå av vertsbrannmuren, legge til en regel som tillater alt, eller tvinge hvert grensesnitt inn i en klarert profil fjerner hver gang kontrollen som gjorde jobben sin, og endringen overlever hendelsen. En regel begrenset til kildeområdet og den aktuelle porten er lettere å gjennomgå, lettere å fjerne, og lar resten av maskinens policy være intakt.

Verifiser med samme test som feilet, fra samme klient, og deretter en gang til etter ny tilkobling, fordi en regel som passer før tunnelen forhandler på nytt kan slutte å passe etterpå:

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

Før du lukker det:

  • Veien til målet forlater via tunellgrensesnittet, og kildeadressen stemmer med det policyen forventer.
  • Noe lytter på porten, og avvisningen eller timeouten tilskrives en navngitt regel i stedet for å antas.
  • Gatewayen videresender i begge retninger, og målet ser kilden reglene dine ble skrevet for.
  • Ingen kontroll ble slått av for at testen skulle passere, og endringen du gjorde navngir ett kildeområde og én port.

Relaterte artikler