VPN imeunganishwa lakini firewall bado inazuia: jinsi ya kujua ipi

Tuneli inafanya kazi na bandari moja bado inashindikana. Soma njia, kisha sera katika kila tabaka, na ubadilishe kanuni nyembamba zaidi badala ya kuzima mojawapo ya vidhibiti viwili.

Mteja anasema imeunganishwa, rasilimali bado inakataa, na hatua inayofuata ya kawaida ni kuzima kitu. Vidhibiti viwili katika sentensi hiyo hufanya kazi tofauti: VPN hujenga njia kwa trafiki iliyofunikwa, na firewall huamua kwa kila muunganisho kama trafiki inaweza kupita. Tuneli inayofanya kazi na sera inayokataa inaonekana kama tuneli iliyovunjika kutoka kiti cha mtumiaji, kwa hiyo kazi ni kujua tabaka lipi linajibu. Huu ndio mpangilio ninaofuata, pamoja na usomaji unaokuambia usimame.

Tenganisha njia na sera

Anza na umbo la kushindikana, kwa sababu ni taarifa ya bure. Kuanguka kwa pakiti hutoa muda wa kusubiri: mteja anajaribu tena, hakuna kinachorudi, na amri inaning'inia hadi ikate tamaa. Kukataa hutoa kukataliwa au kuweka upya: kitu kilijibu na kusema hapana. Huduma isiyosikiliza hukataa kwenye mwenyeji yenyewe, bila firewall yoyote.

Matokeo hayo matatu yanaelekeza kwenye tabaka tofauti. Muda wa kusubiri unamaanisha kwamba mahali fulani sera inatupa kimya, au njia haiondoki kwenye mashine. Kukataliwa kunamaanisha ulifika kwa mwenyeji na tabaka lake au firewall ya ndani ilikataa. Ukimya kamili, huku kiolesura cha tuneli kikiwa juu na hakuna njia ya kufikia lengwa, kunamaanisha njia si sahihi na hakuna kanuni ya firewall itakayoirekebisha.

Soma njia kwa mpito mmoja

Thibitisha kwamba tuneli inashughulikia lengwa kabla ya kuangalia kanuni moja. Tuneli iliyogawanyika inayobeba subnet ya ofisi pekee haitaelekeza ombi kwenye safu nyingine, na wakati huo kushindikana kunaonekana kama kuzuia kwa firewall ambako si hivyo:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Matokeo ya njia yanataja kiolesura ambacho pakiti itatoka na anwani ya chanzo itakayobeba. Ikiwa kiolesura hicho ni kadi yako ya mtandao halisi na si tuneli, tatizo liko kwenye uelekezaji au kwenye safu zinazoruhusiwa za tuneli, na ni la usanidi wa VPN na si la firewall.

Mtego mmoja maalum kwa VPN unastahili ukaguzi wake. Katika WireGuard, AllowedIPs ya peer ni njia na kichujio cha siri kwa wakati mmoja: pakiti ambayo anwani yake ya chanzo hailingani na seti inayoruhusiwa ya peer hutupwa kabla ya kanuni yoyote ya firewall kushauriwa. Kwa hiyo firewall sahihi kabisa ya mwenyeji inaweza kusimama nyuma ya kutupa kwa kimya kunakoonekana kama sera, na suluhisho ni mstari wa usanidi wa ufunguo, si kanuni.

Soma sera katika tabaka linalojibu

Njia ikiwa sahihi, pitia sera kutoka kwa mwenyeji kwenda nje na uangalie tabaka moja ambalo vihesabio vyake vinasonga:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Soketi inayosikiliza hujibu swali tofauti na kanuni. Ikiwa hakuna kinachosikiliza kwenye bandari, kerneli inakataa muunganisho na hakuna kanuni ya kuingia inayohusika. Ikiwa soketi ipo na muunganisho kutoka mteja wa mbali unaisha muda, kutupa kunatokea mahali fulani kwenye njia, na vihesabio vya kanuni vinakuambia kama kunatokea hapa.

Washa ukataji wa kumbukumbu kwa wasifu au mnyororo unaoshuku badala ya kukisia kutoka nje. Kutupa kumoja kulikorekodiwa kunakotaja chanzo, lengwa na bandari hutambua tabaka na kanuni, na pia kunathibitisha kwamba pakiti ilifika, jambo ambalo hakuna jaribio la upande wa mteja linaweza kuthibitisha.

Soma uamuzi wa lango wakati tuneli inaishia hapo

Kwenye lango la tovuti-hadi-tovuti au ufikiaji wa mbali, VPN huthibitisha mtumiaji na sera huidhinisha rasilimali, na hizo ni idhini tofauti. Mtumiaji aliyeruhusiwa kuingia tunelini haruhusiwi kiotomatiki kwa kila mwenyeji wa ndani, na kukataa mara nyingi hutoka kwa kanuni ya upelekaji wakati tuneli yenyewe iko salama. Mgawanyiko huo huo unaonekana katika IPsec, ambapo sera ya usalama inayochagua trafiki ni tofauti na kichujio kinachoiruhusu, na ndiyo sababu zote mbili zimeandikwa kama mifumo tofauti katika RFC 4301.

Angalia njia ya kurudi kwa umakini kama ile ya kwenda. Uchujaji wa hali unahitaji kuona jibu, kwa hiyo uelekezaji usio sawa kupitia tuneli kwa upande mmoja na kuizunguka kwa upande mwingine hutoa kutupa kunakoonekana kama nasibu na kunajirudia tu kutoka kwa wateja wengine. Ikiwa trafiki inafika kwenye lango na kusimama, soma kanuni ya upelekaji na njia ya kurudi pamoja kabla ya kupanua kitu.

Lango pia ni mahali ambapo kanuni ya NAT au ufichaji inaweza kuficha chanzo halisi. Ikiwa wenyeji wa ndani wanaona anwani ya lango badala ya mteja, kanuni zao za firewall ya mwenyeji zinazopaswa kufanana na bwawa la wateja hazitafanana kamwe, na suluhisho ni la lango na si la kila seva.

Badilisha tabaka nyembamba zaidi, kisha thibitisha

Pinga ukarabati mpana. Kuzima firewall ya mwenyeji, kuongeza kanuni inayoruhusu kila kitu, au kulazimisha kila kiolesura kwenye wasifu unaoaminiwa kila mara kunaondoa kidhibiti kilichokuwa kikifanya kazi yake, na mabadiliko yanaishi zaidi ya tukio. Kanuni iliyowekewa kikomo cha safu ya chanzo na bandari husika ni rahisi kukagua, rahisi kuondoa, na inaacha sera nyingine ya mashine ikiwa kamili.

Thibitisha kwa jaribio lilelile lililoshindikana, kutoka kwa mteja yuleyule, na kisha mara moja zaidi baada ya kuunganisha tena, kwa sababu kanuni iliyolingana kabla tuneli kujadiliana upya inaweza kuacha kulingana baadaye:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Kabla ya kuifunga:

  • Njia ya kufikia lengwa inatoka kupitia kiolesura cha tuneli, na anwani ya chanzo inalingana na kile sera inatarajia.
  • Kitu kinasikiliza kwenye bandari, na kukataa au muda wa kusubiri kunahusishwa na kanuni iliyotajwa badala ya kudhaniwa.
  • Lango hupeleka pande zote mbili, na lengwa linaona chanzo ambacho kanuni zako ziliandikwa kwa ajili yake.
  • Hakuna kidhibiti kilichozimwa ili jaribio lipite, na mabadiliko uliyofanya yanataja safu moja ya chanzo na bandari moja.

Makala zinazohusiana