Skybrannmur kontra vertsbrannmur for ein VPN-server
To filter vaktar same VPN-porten. Gå grenseløpet frå skypolitikken til lyttaren hos gjesten, og prov deretter rettinga med ei fersk økt.
Tillat VPN-porten i skypolitikken, og handtrykket kan likevel døy på instansen: gjesten køyrer sitt eige filter og si eiga lyttarbinding, og begge kan kaste det skya godkjende. Det motsette skjer òg, når ei vertsregel tillèt porten og ein politikk lenger oppe kastar han først. To eigarar, to regelsett, éin pakkeveg. Gå han i rekkjefølgje i staden for å gjette på det mest mistenkelege laget.
Start ved kanten og gå innover
Rekkjefølgja er fast: offentleg endepunkt, ressursgrensesnitt, tilknytt skypolitikk, gjesteadresse, prosesslyttar, lokale inngangsreglar. Kvart trinn slepp pakken gjennom eller avsluttar undersøkinga, og difor kastar ein bort mest tid på å byrje hos gjesten.
Vidaresend klienttrafikk er eit eige trinn som blir inspisert etter at tunnelen er avkapsla. Skylaget ser berre den ytre tunnelen, så det kan godkjenne ei tilkopling og likevel ikkje ha noko med ein indre tenesteførespurnad å gjere. Ein tunnel som koplar til, men ikkje når ein intern vert, peikar vanlegvis på vidaresending, ikkje på ein lukka port.
Les skypolitikken før du rører gjesten
Stadfest inngangsregelen for VPN-porten, protokollen og kjeldeomfanget som passar testklienten din. Sjekk òg tilgangslista for subnettet: eit andre filter med eigne reglar og standardverdiar. Begge må tillate flyten før ein pakke når instansen. Ei tillating i det eine og eit avslag i det andre er den vanlege forma for denne feilen.
Avgrens omfanget til det betyr noko. Å opne VPN-porten mot heile internett er lett å prove og vanskeleg å forsvare, medan ein regel fest til éi adresse bryt saman når testklienten din byter nettverk. Noter regelidentifikatoren og politikkeigaren, slik at neste endring kan sporast til ein person.
Stadfest lyttaren, deretter inngangskjeda
På instansen, kontroller at VPN-prosessen er bunden til adressa og porten du ventar, til dømes med ss -lntp 'sport = :1194'. Ein daemon som berre er bunden til 127.0.0.1 godtek lokale klientar og ingenting gjennom tunnelen, noko som utanfrå ser nøyaktig ut som ein filtrert port.
Les deretter dei lokale reglane i syntaksen du ville bruke for å endre dei, som iptables -S INPUT eller nft list chain inet filter input. Ein regel skriven til ei fil men aldri lasta, eller eit standardkast utan tilsvarande tillating, kastar pakkar i stillheit. For ein gateway som vidaresender, sjekk òg innstillingane for vidaresending og returveg. Dei avgjer kva som skjer med pakkar som blir ruta gjennom instansen i staden for å vere adresserte til han.
Stateful i eitt lag, stateless i det neste
Tryggingsgrupper hugsar flyta dei tillét og slepp svara inn att. Tilgangslister for subnett og mange vertsbrannmurar held ingen slik tilstand, så ein regel som berre dekkjer utgåande retning slepp førespurnaden gjennom og kastar svaret. Overfør aldri ei føresetnad om returtrafikk mellom lag utan å lese regelen i det andre laget (second layer's rule).
Teljarar avgjer dette raskare enn å lese kvar regel i kontoen. Ein teljar som stig betyr at pakken kom fram og vart kasta der, medan ein som er frosen på null betyr at han aldri kom så langt; iptables -vnL INPUT og nft list ruleset viser desse tala når reglane vart lasta med teljarar.
Test med ei fersk økt, ikkje ei levande
Lat kjeldanettverket og testprofilen vere i fred medan du samanliknar visingar, og opne ei ny tilkopling etter kvar endring. Å nå nettkonsollen på 443 seier ingenting om korvidt VPN-daemonen er bunden til 1194, så test porten du treng. Ei eksisterande økt er det dårlegaste vitnet her. Ho held fram med å verke medan kvar ny innlogging blir avvist.
Før du redigerer ein ekstern politikk, sikre ein veg tilbake som ikkje er avhengig av banen du endrar. Opne deretter ei andre administrasjonsøkt ved sida av VPN-testen: ei som vart oppretta tidlegare, kan overleve regelen som blokkerer nye. Noter begge politikkeigarane slik at ingen gjenoppbygging gjenopprettar halve banen; om begge laga er samde og tunnelen framleis feilar, fang opp på grensesnittet til gjesten og kontroller adressa og porten klienten faktisk brukar.