Har du sat VPN-adressen på hvidlisten og stadig blokeret? Spor den
Tilladelsesreglen angiver den adresse, din VPN-app viser, og anmodningerne falder stadig. Fang den kilde, der faktisk når tjenesten, og ret den.
At sætte den adresse, en VPN-app viser, på hvidlisten løser sjældent en blokeret port, og pakken forklarer hvorfor. Firewallen ignorerer ikke din regel; den vurderer en kildeadresse, som intet på klientens skærm viser. Indtil destinationen rapporterer den værdi, er enhver regelredigering et gæt.
Start med den anmodning, der når tjenesten. Tunneladressen, udgangsadressen og enhver oversættelse indimellem forbliver hypoteser, indtil destinationen bekræfter en af dem.
Adressen i appen er ikke den, der ankommer
En VPN-forbindelse bærer mindst fire adresser, som er værd at navngive hver for sig: serverens slutpunkt, den indre tunneladresse, der er tildelt din klient, den lokale Wi-Fi- eller Ethernet-adresse og den offentlige adresse, som et websted ser, efter at trafikken forlader udbyderen. Et klientvindue viser måske kun den anden. Navngiv alle fire, før du navngiver en regel. Med delt tunnelling kan anmodninger til en offentlig destination springe tunnelen helt over, så den fejlende session er ikke den, brugeren tror, de startede.
Afgør, hvilken af de fire reglen skal tillade, og bekræft den derefter fra den anden side. Hvis kravet virkelig er en kontoradresse, er betingelsen ruten plus den sides udgangsordning, og en forbindelse mærket Office VPN leverer ikke nogen af delene i sig selv.
Følg én anmodning til dens filtreringsgrænse
Bekræft destinationsadressen og porten, som klienten bruger, og kontroller derefter, at denne destination følger den vej, du antager. En offentliggjort containerport, en omvendt proxy eller en portvideresendelse kan flytte beslutningen til en vært, du aldrig har redigeret. Hvert af disse hop kan have sin egen politik. At fastlægge vejen først sparer dig for at rette en regel, som ingen pakke nogensinde når.
På en autoriseret Linux-vært skal du læse de aktive regler i rækkefølge, før du ændrer dem. Videresendte tjenester og containertjenester springer ofte ind i deres egen kæde, så undersøg hoppmålet samt den endelige dom.
iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'Citer det matchende regelnummer i billetten. Uden det kan den næste læser ikke se, hvilken ændring der ændrede resultatet. Et regelnummer uden tidsstempel er stadig tvetydigt.
Bekræft vejen med én afgrænset optagelse
Én harmløs anmodning og én smal optagelse afgør det spørgsmål, der hele tiden vender tilbage. Filtrér på destinationsporten og værten under undersøgelse, begræns antallet af pakker, og stop optagelsen, så snart anmodningen er fuldført.
tcpdump -ni any 'tcp dst port 9443' -c 20Sammenlign tre værdier side om side: kilden i optagelsen, den kilde, den matchende regel angiver, og den afvisning, applikationen loggede. De kan alle være forskellige, og kun den første forklarer et drop, som en IP-regel har besluttet. Et videresendt HTTP-header tilhører proxy-laget, så en log, der citerer det header, beskriver ikke den kilde, firewallen vurderede.
Læs kæderækkefølgen, ikke kun reglen
iptables-referencen dokumenterer ordnet gennemløb, og derfor redder en tilladelse, der ligger under en matchende terminal afvisning, aldrig pakken. En forbindelse, der blev accepteret tidligere, kan også opføre sig anderledes end en ny, så en gammel succes siger intet om den nye regel. Find afvisningen eller droppet over din tilladelse, før du antager, at tilladelsen er forkert. Tællere for hver regel fortæller også, hvilken regel der så pakken.
At slette en regel for at se, hvad der sker, er en ændring, ikke en observation. Læs tællerne, noter regelnummeret, og behold den oprindelige politik i ændringsloggen. Hvis en test er uundgåelig, skal du køre den på en kopi af kæden.
Ændr den regel, som dens ejer styrer
Opdater kun den tilsigtede kilde- og tjenestepolitik, gennem den, der ejer den. En delt oversat udgang kan repræsentere mange brugere på én gang, så tilladelse af den adresse autentificerer ingen, og applikationstilladelserne bag den bliver, hvor de er.
Når adressen fortsætter med at flytte sig, er det holdbare svar en stabil udgang eller en autentificeret kanal, ikke en længere undtagelsesliste. Registrér den observerede kilde, destinationsporten og regelnummeret.