Skybrannmur kontra vertsbrannmur for en VPN-server

Tillat VPN-porten i skypolitikken, og håndtrykket kan likevel dø på instansen: gjesten kjører sitt eget filter og sin egen lytterbinding, og begge kan forkaste det skyen godkjente. Det motsatte skjer også, når en vertsregel tillater porten og en politikk lenger opp forkaster den først. To eiere, to regelsett, én pakkevei. Gå den i rekkefølge i stedet for å gjette på det mest mistenkelige laget.

Start ved kanten og gå innover

Rekkefølgen er fast: offentlig endepunkt, ressursgrensesnitt, tilknyttet skypolitikk, gjesteadresse, prosesslytter, lokale inngangsregler. Hvert trinn slipper pakken gjennom eller avslutter undersøkelsen, og derfor kaster man bort mest tid på å begynne hos gjesten.

Videresendt klienttrafikk er et eget trinn som inspiseres etter at tunnelen er avkapslet. Skylaget ser bare den ytre tunnelen, så det kan godkjenne en tilkobling og likevel ikke ha noe med en indre tjenesteforespørsel å gjøre. En tunnel som kobler til, men ikke når en intern vert, peker vanligvis på videresending, ikke på en lukket port.

Les skypolitikken før du rører gjesten

Bekreft inngangsregelen for VPN-porten, protokollen og kildeomfanget som passer testklienten din. Sjekk også tilgangslisten for subnettet: et andre filter med egne regler og standardverdier. Begge må tillate flyten før en pakke når instansen. En tillatelse i det ene og en avvisning i det andre er den vanlige formen for denne feilen.

Begrens omfanget til det betyr noe. Å åpne VPN-porten mot hele internett er lett å bevise og vanskelig å forsvare, mens en regel festet til én adresse bryter sammen når testklienten din bytter nettverk. Noter regelidentifikatoren og policyeieren, slik at neste endring kan spores til en person.

Bekreft lytteren, deretter inngangskjeden

På instansen, kontroller at VPN-prosessen er bundet til adressen og porten du forventer, for eksempel med ss -lntp 'sport = :1194'. En daemon som bare er bundet til 127.0.0.1 godtar lokale klienter og ingenting gjennom tunnelen, noe som utenfra ser nøyaktig ut som en filtrert port.

Les deretter de lokale reglene i syntaksen du ville brukt for å endre dem, som iptables -S INPUT eller nft list chain inet filter input. En regel skrevet til en fil men aldri lastet, eller en standardforkastelse uten samsvarende tillatelse, forkaster pakker i stillhet. For en gateway som videresender, sjekk også innstillingene for videresending og returvei. De avgjør hva som skjer med pakker som rutes gjennom instansen i stedet for å være adressert til den.

Stateful i ett lag, stateless i det neste

Sikkerhetsgrupper husker flytene de tillot og slipper svarene inn igjen. Tilgangslister for subnett og mange vertsbrannmurer holder ingen slik tilstand, så en regel som bare dekker utgående retning slipper forespørselen gjennom og forkaster svaret. Overfør aldri en antakelse om returtrafikk mellom lag uten å lese regelen i det andre laget (second layer's rule).

Tellere avgjør dette raskere enn å lese hver regel i kontoen. En teller som stiger betyr at pakken kom frem og ble forkastet der, mens en frosset på null betyr at den aldri kom så langt; iptables -vnL INPUT og nft list ruleset viser disse tallene når reglene ble lastet med tellere.

Test med en fersk økt, ikke en levende

La kildenettverket og testprofilen være i fred mens du sammenligner visninger, og åpne en ny tilkobling etter hver endring. Å nå webkonsollen på 443 sier ingenting om hvorvidt VPN-daemonen er bundet til 1194, så test porten du trenger. En eksisterende økt er det dårligste vitnet her. Den fortsetter å virke mens hver ny innlogging avvises.

Før du redigerer en ekstern policy, sikre en vei tilbake som ikke avhenger av banen du endrer. Åpne deretter en andre administrasjonsøkt ved siden av VPN-testen: en som ble etablert tidligere, kan overleve regelen som blokkerer nye. Noter begge policyeierne slik at ingen gjenoppbygging gjenoppretter halve banen; hvis begge lag er enige og tunnelen fortsatt feiler, fang opp på gjestens grensesnitt og kontroller adressen og porten klienten faktisk bruker.