Pilve tulemüür versus hosti tulemüür VPN-serveri jaoks
Kaks filtrit valvavad sama VPN-porti. Käige läbi piirijärjekord pilvepoliitikast külalise kuulajani ja tõestage parandus seejärel värske sessiooniga.
Lubage VPN-port pilvepoliitikas ja käepigistus võib ikkagi instantsil surra: külaline käitab oma filtrit ja oma kuulaja sidumist ning kumbki võib ära visata selle, mille pilv heaks kiitis. Juhtub ka vastupidi, kui hosti reegel lubab porti ja ülemine poliitika viskab selle esimesena ära. Kaks omanikku, kaks reeglistikku, üks paketitee. Käige see järjekorras läbi, selle asemel et kõige kahtlasemal kihil oletada.
Alustage servast ja liikuge sissepoole
Järjekord on fikseeritud: avalik lõpp-punkt, ressursi liides, külge kinnitatud pilvepoliitika, külalise aadress, protsessi kuulaja, kohalikud sisendreeglid. Iga etapp kas laseb paketi läbi või lõpetab uurimise, mistõttu külalisest alustamine kaotab kõige rohkem aega.
Edastatud kliendiliiklus on eraldi etapp, mida uuritakse pärast tunnelist lahtipakkimist. Pilvekiht näeb ainult välimist tunnelit, seega võib see ühenduse heaks kiita ja samas mitte mingit pistmist olla sisemise teenuse päringuga. Tunnel, mis ühendub, kuid ei jõua sisemise hostini, osutab tavaliselt edastamisele, mitte suletud pordile.
Lugege pilvepoliitikat enne, kui külalist puudutate
Kinnitage VPN-pordi sissetulev reegel, selle protokoll ja teie testkliendiga sobiv allika ulatus. Kontrollige ka alamvõrgu juurdepääsuloendit: teine filter oma reeglite ja vaikeväärtustega. Mõlemad peavad voolu lubama, enne kui pakett instantsini jõuab. Luba ühes ja keeld teises on selle vea tavaline kuju.
Kitsendage ulatust, kuni sellel on tähendus. VPN-pordi avamine kogu internetile on lihtne tõestada ja raske kaitsta, samas kui ühele aadressile kinnitatud reegel puruneb, kui teie testklient võrku vahetab. Märkige üles reegli identifikaator ja poliitika omanik, et järgmine muudatus oleks jälgitav inimeseni.
Kinnitage kuulaja, seejärel sisendkett
Kontrollige instantsil, et VPN-protsess on seotud oodatava aadressi ja pordiga, näiteks käsuga ss -lntp 'sport = :1194'. Ainult aadressile 127.0.0.1 seotud deemon võtab vastu kohalikke kliente ja mitte midagi tunnelist, mis näeb väljast täpselt välja nagu filtreeritud port.
Seejärel lugege kohalikke reegleid samas süntaksis, mida kasutaksite nende muutmiseks, näiteks iptables -S INPUT või nft list chain inet filter input. Faili kirjutatud, kuid kunagi laadimata reegel, või vaikimisi viskamine ilma sobiva loata, viskab paketid vaikselt ära. Edastava lüüsi puhul kontrollige ka edastamise ja pöördtee seadeid. Need otsustavad, mis juhtub pakettidega, mis marsruuditakse läbi instantsi, mitte ei ole sellele adresseeritud.
Ühel kihil olekuga, järgmisel olekuta
Turvagrupid mäletavad voogusid, mille nad lubasid, ja lasevad vastused tagasi. Alamvõrkude juurdepääsuloendid ja paljud hosti tulemüürid sellist olekut ei hoia, seega ainult väljuvat suunda kattev reegel laseb päringu läbi ja viskab vastuse ära. Ärge kunagi kandke tagastusliikluse eeldust kihtide vahel, lugemata teise kihi reeglit (second layer's rule).
Loendurid lahendavad selle kiiremini kui iga reegli lugemine kontol. Kasvav loendur tähendab, et pakett jõudis kohale ja visati seal ära, samas kui nulli külmunud loendur tähendab, et see ei jõudnudki nii kaugele; iptables -vnL INPUT ja nft list ruleset näitavad neid arve, kui reeglid laaditi loenduritega.
Testige värske sessiooniga, mitte elava sessiooniga
Jätke lähtevõrk ja testprofiil puutumata, kui vaateid võrdlete, ja avage iga muudatuse järel uus ühendus. Veebikonsoolile pordil 443 jõudmine ei ütle midagi selle kohta, kas VPN-deemon on seotud pordiga 1194, seega testige porti, mida vajate. Olemasolev sessioon on siin halvim tunnistaja. See töötab edasi, samal ajal kui iga uus sisselogimine tagasi lükatakse.
Enne kaugpoliitika muutmist kindlustage tagasitee, mis ei sõltu teest, mida muudate. Seejärel avage VPN-testi kõrvale teine haldussessioon: varem loodud sessioon võib üle elada reegli, mis blokeerib uued. Märkige üles mõlema poliitika omanik, et ükski ülesehitus ei taastaks poolt teed; kui mõlemad kihid on nõus ja tunnel ikka ei tööta, jäädvustage külalise liidesel ja kontrollige aadressi ja porti, mida klient tegelikult kasutab.