Inngangsreglur SSH og VPN: hvað leyfislistinn stjórnar í raun
Fylgdu einni tengingu frá biðlara til hýsils: hvaða krók hún fer í gegnum, hvers vegna hang og synjun þýða mismunandi reglur og hvers vegna synjun er aldrei stefna.
Tengstu einu sinni áður en þú breytir reglu og athugaðu hvort biðlarinn hangir eða er hafnað strax. Þessi eini munur segir þér hvaða ákvörðun felldi pakkann og sparar klukkustund af lestri stefnuskráa. Afgangur ferðarinnar er stuttur: pakkinn fer í gegnum krók, passar við reglu og nær annað hvort hlustanda eða ekki. Leyfislistinn er bara bókhald í kringum þessar þrjár staðreyndir.
Fylgdu einni SSH-tilraun að inngangskróknum
Biðlari sendir SYN á heimilisfang hýsilsins á porti 22 og kjarninn ákveður hvort pakkinn sé fyrir staðbundna þjónustu. Ef svo er keyrir inngangsleiðin og reglusettið samþykkir pakkann eða hendir honum. Þögn þýðir að SYN dó áður en hlustandinn sá það, en hröð synjun þýðir að eitthvað svaraði með endurstillingu. Þetta eru mismunandi dómar frá mismunandi reglum og bæði eru lögmætar niðurstöður.
Staðfestu hlustandann næst, því engin regla bjargar þjónustu sem er ekki til. Keyrðu ss -ltnp og athugaðu að eitthvað sé bundið við portið og heimilisfangaflokkinn sem þú átt von á, lestu svo ssh -v á biðlaranum til að sjá hvar hann stöðvast.
Framssending er sérstök ákvörðun
Á VPN-þjóni er áhugaverðari krókurinn forward, því umferð biðlarans er beint í gegnum vélina í stað þess að vera afhent henni. Hýsill sem keyrir aðeins eigin VPN-biðlara þarf mun minna reglusett en sá sem framsendir pakka annarra. Að blanda báðum hönnunum á einni vél framleiðir reglur sem líta réttar út og hleypa engu í gegn.
Skrifaðu innri stefnuna sem sérstaka spurningu: hvaða biðlaraheimilisföng mega ná hvaða áfangastöðum gegnum göngin. Hafðu stjórnunarleiðina, til dæmis SSH, á inngangsleiðinni með eigin upprunatakmörkun. Leyfandi forward-regla sem bætt er við í prófun er hinn klassíski galli sem lifir prófið af, svo faraðu yfir allt reglusettið eftir breytingu í stað einu línunnar sem þú breytti. Að opna hlustanda ganganna er ekki leyfi fyrir hvern tengdan biðlara að stjórna hýslinum.
Að henda og hafna eru aðgerðir, ekki stefnur
Stefna grunnkeðju samþykkir eða hendir og það er allur listinn yfir valkosti, eins og nftables-handbókin segir. Synjun er til sem regluaðgerð með völdu svari, þess vegna mistekst að skrifa hana sem stefnu bæði á nftables og iptables. Í reynd gefur drop biðlaranum engar upplýsingar, en reject gefur honum villu sem hann getur unnið með.
table inet admin {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related accept
ip saddr 203.0.113.0/28 tcp dport 22 accept
udp dport 51820 accept
icmp type { destination-unreachable, time-exceeded } accept
}
}
Lestu þessa skissu sem lögun ákvörðunar en ekki skrá til að líma inn, því heimilisfangabilin eru dæmi. Skýr reject á SSH-portinu lætur óheimilan biðlara mistakast á sekúndu í stað þess að bíða tímamarka, sem styttir þína eigin kembiforritun. Þögn dregur úr tilviljunarkenndri skönnun og segir heimildarmanni ekkert. Veldu fyrir hverja þjónustu og skrifaðu hvers vegna, annars breytir næsta manneskja því aftur.
Haltu stjórnunarumferðinni sem þú þarft í raun
Að loka öllu ICMP er vinsælt sjálfgefið sem brýtur MTU-greiningu leiðarinnar, og einkennið er tenging sem kemst á og stöðvast svo á stærri pakkum. Nágrannagreining á IPv6 er háð eigin ICMPv6-tögum og að henda þeim brýtur tenginguna áður en nokkur TCP-regla er skoðuð. Bæði eiga heima á leyfislistanum sem nafngreindar ósjálfstæður en ekki sem almenn leyfi. Stefna sem brýtur greininguna hljóðlega er verri en sú sem leyfir smá greiningarumferð.
Leyfðu stöðunum established og related fyrir tengingar sem þú hófst sjálf og láttu stöðuvélina sjá um svörin. Staðfestu svo að svarleiðin sé ekki lokuð lengra út, því takmörkun sem aðeins nær til útleiðar ofar í keðjunni framleiðir sama tímamarkið og þú varst að fara að kenna hýslinum um.
Sannaðu endurheimt áður en þú hættir notkun gömlu leiðarinnar
Haltu konsólsetu opinni, beittu breytingunni og opnaðu algjörlega nýja stjórnunartengingu frá öðru skjáhermi. Núverandi seta sannar ekkert, því hún getur lifað reglu sem lokar hverri nýrri innskráningu af, sem gerir hana sannfærandi falska jákvæða niðurstöðu í eldveggjavinnu. Ef eftirlitskerfi athugar hýsilinn skaltu bæta við upprunafanginu fyrir breytinguna en ekki eftir fyrstu viðvörunina. Prófaðu svo einn stóran og einn lítinn pakka til að sanna að greiningin virki enn.
Fyrir VPN-þjónustu skaltu endurtaka frá biðlara sem hefur aldrei tengst, því framhaldsseta getur endurnýtt stöðu sem ný seta verður að semja um. Skráðu nákvæmlega það reglusett sem stóðst, með gátsummu eða afriti, svo hægt sé að bera saman síðari breytingu í stað þess að giska. Samræmdu við þann sem á regluröðina, því fyrri regla vinnur hljóðlega gegn þeirri sem þú bættir við.