VPN er tilkopla, men brannmuren blokkerer framleis: slik avgjer du kven

Tunnelen er oppe, og éin port feilar framleis. Les vegen, deretter policyen på kvart lag, og endre den smalaste regelen i staden for å slå av ein av dei to kontrollane.

Klienten seier tilkopla, ressursen avviser framleis, og det vanlege neste steget er å slå av noko. Dei to kontrollane i den setninga gjer ulike jobbar: VPN byggjer ein veg for den dekte trafikken, og ein brannmur avgjer per tilkopling om trafikken får passere. Ein fungerande tunnel med ein avvisande policy ser nøyaktig ut som ein øydelagd tunnel frå stolen til brukaren, så oppgåva er å finne ut kva lag som svarar. Her er rekkjefølgja eg følgjer, med lesinga som seier at du skal stoppe.

Skil vegen frå policyen

Byrja med forma på feilen, for det er gratis informasjon. Ein droppa pakke gir timeout: klienten prøver igjen, ingenting kjem tilbake, og kommandoen heng til han gir opp. Ei avvising gir ei nekting eller ein reset: noko svara og sa nei. Ein teneste som ikkje lyttar, avviser på sjølve verten, heilt utan brannmur.

Desse tre utfalla peikar på ulike lag. Timeout betyr at ein policy ein stad forkastar stille, eller at vegen aldri forlèt maskina. Avvist betyr at du nådde verten, og at stakken eller den lokale brannmuren sa nei. Fullstendig stillheit, med tunellgrensesnittet oppe og ingen veg til målet, betyr at vegen er feil og ingen brannmurregel rettar det.

Les vegen i eitt gjennomløp

Stadfest at tunnelen dekkjer målet før du ser på ein einaste regel. Ein delt tunnel som berre ber kontoret sitt subnett vil ikkje rute ein førespurnad til eit anna område, og då ser feilen ut som ei brannmursperring som ikkje er det:

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

Ruteutskrifta namngir grensesnittet pakken vil forlèta via og kjeldeadressa han vil bera. Viss det grensesnittet er det fysiske nettkortet ditt og ikkje tunnelen, er problemet i rutinga eller i dei tillatne områda til tunnelen, og det høyrer til VPN-konfigurasjonen og ikkje brannmuren.

Éi VPN-spesifikk felle fortener sin eigen sjekk. I WireGuard er AllowedIPs for ein peer både ein rute og eit kryptografisk filter: ein pakke der kjeldeadressa ikkje passar i det tillatne settet til peeren, blir forkasta før nokon brannmurregel blir konsultert. Så ein heilt korrekt vertsbrannmur kan stå bak ei stille forkasting som ser ut som ein policy, og rettinga er ei konfigurasjonslinje for nøkkelen, ikkje ein regel.

Les policyen på laget som svarar

Når vegen er riktig, gå gjennom policyen frå verten og utover, og følg med på det eine laget der teljarane flyttar seg:

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

Den lyttande sockelen svarar på eit anna spørsmål enn reglane. Viss ingenting lyttar på porten, blir tilkoplinga avvist av kjernen, og ingen inngåande regel er relevant. Viss sockelen finst og tilkoplinga frå ein ekstern klient går ut på tid, skjer ei forkasting ein stad på vegen, og teljarane til reglane fortel om det skjer her.

Slå på logging for profilen eller kjeda du mistenkjer, i staden for å gjette utanfrå. Éi logga forkasting som namngir kjelde, mål og port identifiserer laget og regelen, og ho beviser også at pakken kom fram, noko ingen test på klientsida kan fastslå.

Les avgjerda til gatewayen når tunnelen endar der

På ein gateway for nettstad-til-nettstad eller fjern tilgang autentiserer VPN ein brukar, og policyen autoriserer ein ressurs, og det er separate tildelingar. Ein brukar som er sleppt inn i tunnelen, er ikkje automatisk sleppt inn på kvar intern vert, og avvisinga kjem ofte frå ein vidaresendingsregel medan sjølve tunnelen er sunn. Den same delinga finst i IPsec, der sikkerheitspolicyen som vel trafikk er forskjellig frå filteret som slepp han inn, og derfor er dei to dokumenterte som ulike mekanismar i RFC 4301.

Sjekk returvegen like grundig som den utgåande. Stateful filtrering må sjå svaret, så asymmetrisk ruting gjennom tunnelen i éi retning og rundt han i den andre gir forkastingar som verkar tilfeldige og berre blir gjentekne frå nokre klientar. Viss trafikken når gatewayen og stoppar, les vidaresendingsregelen og returvegen saman før du utvidar noko.

Gatewayen er også staden der ein NAT- eller maskeringsregel kan skjule den verkelege kjelda. Viss interne vertar ser gatewayadressa i staden for klienten, vil vertsbrannmurreglane deira som skal passe klientgruppa aldri passe, og rettinga høyrer til gatewayen og ikkje kvar server.

Endre det smalaste laget, og verifiser deretter

Motstå den breie reparasjonen. Å slå av vertsbrannmuren, leggje til ein regel som tillèt alt, eller tvinge kvart grensesnitt inn i ein klarert profil fjernar kvar gong kontrollen som gjorde jobben sin, og endringa overlever hendinga. Ein regel avgrensa til kjeldeområdet og den aktuelle porten er lettare å gjennomgå, lettare å fjerne, og lèt resten av policyen til maskina vere intakt.

Verifiser med same test som feila, frå same klient, og deretter ein gong til etter ny tilkopling, fordi ein regel som passar før tunnelen forhandlar 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 lukkar det:

  • Vegen til målet forlèt via tunellgrensesnittet, og kjeldeadressa stemmer med det policyen ventar.
  • Noko lyttar på porten, og avvisinga eller timeouten blir tilskriven ein namngitt regel i staden for å bli antatt.
  • Gatewayen vidaresender i begge retningar, og målet ser kjelda reglane dine vart skrivne for.
  • Ingen kontroll vart slått av for at testen skulle passere, og endringa du gjorde namngir eitt kjeldeområde og éin port.

Relaterte artiklar