Å sette adressen en VPN-app viser på hvitlisten løser sjelden en blokkert port, og pakken forklarer hvorfor. Brannmuren ignorerer ikke regelen din; den vurderer en kildeadresse som ingenting på klientens skjerm viser. Inntil destinasjonen rapporterer den verdien, er hver regelendring en gjetning.

Start med forespørselen som når tjenesten. Tunneladressen, utgangsadressen og enhver oversettelse imellom forblir hypoteser til destinasjonen bekrefter en av dem.

Adressen i appen er ikke den som ankommer

En VPN-forbindelse bærer minst fire adresser som er verdt å navngi hver for seg: serverens endepunkt, den indre tunneladressen som er tildelt klienten din, den lokale Wi-Fi- eller Ethernet-adressen, og den offentlige adressen et nettsted ser etter at trafikken har forlatt leverandøren. Et klientvindu kan vise bare den andre. Navngi alle fire før du navngir en regel. Med delt tunnel kan forespørsler til en offentlig destinasjon hoppe helt over tunnelen, så den feilende økten er ikke den brukeren tror de startet.

Avgjør hvilken av de fire regelen skal tillate, og bekreft den deretter fra den andre siden. Hvis kravet virkelig er en kontoradresse, er betingelsen ruten pluss den nettstedets utgangsordning, og en forbindelse merket Office VPN gir ingen av delene av seg selv.

Spor én forespørsel til dens filtreringsgrense

Bekreft destinasjonsadressen og porten klienten bruker, og kontroller deretter at denne destinasjonen følger ruten du antar. En publisert containerport, en omvendt proxy eller en portvideresending kan flytte avgjørelsen til en vert du aldri har redigert. Hvert av disse hoppene kan ha sin egen policy. Å fastslå ruten først sparer deg for å rette en regel som ingen pakke noen gang når.

På en autorisert Linux-vert, les de aktive reglene i rekkefølge før du endrer dem. Videresendte tjenester og containertjenester hopper ofte inn i sin egen kjede, så undersøk hoppmålet så vel som den endelige dommen.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Siter det samsvarende regelnummeret i saken. Uten det kan neste leser ikke se hvilken endring som endret resultatet. Et regelnummer uten tidsstempel er fortsatt tvetydig.

Bekreft ruten med én avgrenset opptak

Én ufarlig forespørsel og ett smalt opptak avgjør spørsmålet som stadig kommer tilbake. Filtrer på destinasjonsporten og verten som undersøkes, begrens antall pakker, og stopp opptaket så snart forespørselen er fullført.

tcpdump -ni any 'tcp dst port 9443' -c 20

Sammenlign tre verdier side om side: kilden i opptaket, kilden den samsvarende regelen navngir, og avvisningen applikasjonen logget. De kan alle være forskjellige, og bare den første forklarer en dropp bestemt av en IP-regel. En videresendt HTTP-header tilhører proxy-laget, så en logg som siterer den headeren beskriver ikke kilden brannmuren vurderte.

Les kjederækkefølgen, ikke bare regelen

iptables-referansen dokumenterer ordnet gjennomgang, og derfor redder en tillatelse som ligger under en samsvarende terminal avvisning aldri pakken. En forbindelse som ble godtatt tidligere kan også oppføre seg annerledes enn en ny, så en gammel suksess sier ingenting om den nye regelen. Finn avvisningen eller droppet over tillatelsen din før du antar at tillatelsen er feil. Tellerne per regel forteller deg også hvilken regel som så pakken.

Å slette en regel for å se hva som skjer er en endring, ikke en observasjon. Les tellerne, noter regelnummeret, og behold den opprinnelige policyen i endringsloggen. Hvis en test er uunngåelig, kjør den på en kopi av kjeden.

Endre regelen som eieren kontrollerer

Oppdater bare den tiltenkte kilde- og tjenestepolicyen, gjennom den som eier den. En delt oversatt utgang kan representere mange brukere samtidig, så å tillate den adressen autentiserer ingen, og applikasjonstillatelsene bak den blir der de er.

Når adressen fortsetter å flytte seg, er det varige svaret en stabil utgang eller en autentisert kanal, ikke en lengre unntaksliste. Registrer den observerte kilden, destinasjonsporten og regelnummeret.

Relaterte artikler