Mwenyeji wa iptables wa VPN pekee: taja kifaa cha tun, si tun+

Kuandika -o tun+ kunaonekana kama maagizo sahihi na kwa kweli ni alama ya jumla inayolingana na kila handaki lililopo kwenye kerneli. Mteja wa pili wa VPN, daraja la kontena au kiungo kilichobaki na kikao kilichoanguka vyote vinakidhi, na mwenyeji huruhusu trafiki ambayo sera ilikusudia kuizuia. Utaratibu hapa chini unabainisha jina moja la kifaa, unapanga misamaha ili handaki liweze kutokea kwa kweli, na unakuletea njia ya kurudi ikiwa kanuni zitakaa vibaya. Kila hatua ni fupi vya kutosha kuondolewa yenyewe.

Hatua 1: andika kanuni ulizonazo sasa

Kabla ya kubadilisha sera chaguo-msingi, hifadhi hali ya sasa ili kurudi nyuma kuwe amri na si kumbukumbu. iptables-save > /root/iptables.pre huandika kila jedwali kwenye faili unayoweza kurejesha, na terminal ya pili yenye kikao cha root kilicho wazi si woga kupindukia wakati sera unayokaribia kuweka inakata muunganisho unaoibeba. Ikiwa unafanya kazi kwa mbali, panga pia flush kama swichi ya dharura.

Kisha orodhesha viungo, kwa sababu jina ulilodhani ni jina ambalo ulipaswa kulisoma: ip -br link linaonyesha kilichopo sasa hivi, na handaki halitaonekana hadi liwe juu. Andika majina ya vifaa unapoyasoma.

Hatua 2: ipe handaki jina lake mwenyewe

OpenVPN inakubali dev tun_work katika usanidi wa mteja, na Linux huunda kiungo chenye jina hilo hasa badala ya kugawa tun0. Jina hubaki thabiti kati ya muunganisho upya mradi hakuna kingine kinachodai, na hiyo ndiyo inayofanya kanuni inayotaja kifaa iwe na maana.

Mahali ambapo jina haliwezi kudhibitiwa, linganisha na anwani ya handaki au alama ya pakiti. Zote mbili zinafanya kazi, zote mbili ni ngumu kusoma, na zote mbili hushindwa kwa utulivu zaidi handaki linapobadilisha namba. Kwa vyovyote, linganisha na kitu kimoja na ueleze wazi kipi.

Hatua 3: andika sera ukiweka msamaha wa endpoint kwanza

Mwenyeji wa VPN pekee ni mwenyeji wa kukataa chaguo-msingi na orodha fupi ya misamaha, na msamaha unaojaliwa zaidi ni ule unaoruhusu handaki kuwepo. Jenga kwa mpangilio huu, kanuni ya endpoint kabla ya kanuni ya kifaa cha handaki, ili kupeana mkono kuwe na mahali pa kwenda:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Anwani halisi ya endpoint na bandari ni za mtoa huduma wako, si za ukurasa huu. Ikiwa endpoint ni jina la mwenyeji, litatue mara moja na ubainishe matokeo, kwa sababu kanuni haiwezi kutafuta jina na jibu linalozunguka litavunja sera kwa utulivu baada ya mabadiliko ya DNS yajayo. Angalia bandari pia, kwa sababu watoa huduma wanaokuhamaisha kwenda TCP 443 vinginevyo watahitaji kanuni ambayo hakuna aliyeandika. Handaki linalofanya kazi kwa itifaki moja tu kwa kawaida ni upungufu huu na si hitilafu ya firewall.

Kwenye kipanga njia umbo hilo hilo huingia kwenye mnyororo wa FORWARD kwa wateja walio nyuma yake, na trafiki ya kipanga njia yenyewe inahitaji kanuni zake. Seti ya kanuni inayoshughulikia pakiti zilizosambazwa pekee huwaacha SSH na DNS kwenye njia ya zamani, na hivyo kipanga njia huwa hakiwezi kufikiwa wakati handaki linapoinuka.

Hatua 4: angalia mpangilio, si uwepo tu

Kanuni hutathminiwa kwa mfuatano, kwa hivyo ACCEPT inayokuja mapema hufunika tu REJECT uliyoongeza baadaye. Ulinganifu wa established na related ndio unaoruhusu majibu ya maombi yako ya nje kurudi bila kufungua njia ya jumla ya kuingia, na kuiweka baada ya kukubali handaki kunamaanisha handaki lililoanguka bado linapita trafiki ya kurudi kwenye kiungo chake.

Weka idadi ya kanuni ndogo vya kutosha kusomeka kwenye skrini moja. Seti ya kanuni usiyoweza kuikagua ni ile utakayoiboresha kwa kuongeza misamaha juu, na hivyo sera za kukataa chaguo-msingi hupata hatua kwa hatua ukingo wa kuruhusu chaguo-msingi. Hesabu ACCEPT kabla na baada ya mabadiliko.

Hatua 5: ifanye istahimili uanzishaji na familia ya anwani

Kanuni zilizoingizwa kwa mkono hupotea wakati wa kuwasha upya, kwa hivyo zipakie kutoka huduma ya firewall ya usambazaji au unit inayokimbia baada ya kiungo cha handaki kuwepo. Kurejelea tun_work katika skripti inayokimbia kabla OpenVPN kuanza ni njia ya kawaida ya kuunda mzunguko wa uanzishaji wa trafiki iliyoangushwa.

Kisha angalia IPv6 kwa pekee, kwa sababu sera nzuri ya kukataa chaguo-msingi kwa IPv4 haisemi chochote kuhusu familia nyingine. ip -6 route itakuambia ikiwa mwenyeji ana njia inayoweza kubeba trafiki kuzunguka handaki linaloshughulikia IPv4 pekee, na ip6tables au nftables inahitaji kanuni zake sawa. Jaribu na lengwa la IPv6-only badala ya kuamini ulinganifu wa seti ya kanuni.

Hatua 6: thibitisha na uwe tayari kurejesha

Inua handaki, thibitisha kuwa huduma unayokusudia inafanya kazi, kisha jaribu kitu ambacho sera inapaswa kukataa. Rejesha kwa iptables-restore < /root/iptables.pre ikiwa jibu linakushangaza, na ndipo tu uanze kuhariri kanuni. Uvumilivu pamoja na njia ya kurejesha iliyojaribiwa ndiyo inayofanya hii kuwa mabadiliko unayoweza kufanya mara mbili.