Kwa nini usimamizi wa ruta huacha kujibu baada ya mabadiliko ya VPN

Ulibadilisha njia au sheria ya ngome ya moto ili kujaribu handaki kwenye ruta, na sasa ukurasa wa usimamizi haujibu kutoka kwa kompyuta ya mkononi iliyokuwa ikifanya kazi vizuri dakika kumi zilizopita. Mwitikio wa kwanza ni kulaumu VPN. Mara nyingi handaki ni nzima na moja ya mambo matatu mengine imeharibika: hakuna njia ya kurudi kwenye anwani ya ruta yenyewe, sera ya kuingia inatupa ombi, au huduma ya wavuti haisikilizi anwani unayoiita. Yote matatu yanaonekana sawa kwenye kivinjari, ndiyo sababu watu huanzisha upya handaki kwa saa moja na hawajifunzi chochote.

Hii ni hekaya inayofaa kuuawa kwanza: handaki inayofanya kazi si njia ya kurudi ndani. Ni muunganisho mpya wa mtandao wenye maswali yake ya uaminifu, na inaweza kuondoa kwa utulivu njia yako ya zamani ya usimamizi huku ikifungua mpya ambayo hakuna aliyekagua.

Handaki haikuwa kamwe njia ya usimamizi

Uelekezaji na kuingia ni kazi tofauti. "Je, mteja anaweza kufikia NAS kupitia handaki?" ni swali la uelekezaji kuhusu pakiti zinazopita kwenye ruta. "Je, naweza kufungua lango la SSH la ruta?" ni swali la kuingia kuhusu pakiti zilizoelekezwa kwa ruta yenyewe. Sheria ya ruhusa iliyoandikwa kwa trafiki iliyoelekezwa haifanyi chochote kwa swali la pili, na hiyo ni sababu ya kawaida zaidi kwa nini handaki inayobeba trafiki kikamilifu bado inakataa kikao chako cha usimamizi.

Kosa la kinyume ni kuamini jina la kiolesura. Handaki imesimbwa kwa rika, si kwa kila huduma iliyo nyuma yake, na neno VPN kwenye lebo ya kiolesura halisemi chochote kuhusu vyanzo vipi vinapaswa kuruhusiwa kuingia.

Tabaka la kwanza: je, kuna njia ya kufikia anwani ya ruta yenyewe?

Anza kwenye mteja na uulize kiini pakiti itaenda wapi. Kwenye Linux ip route get 10.6.0.1 huchapisha njia iliyochaguliwa, kiolesura cha kutoka na anwani ya chanzo. Ikiripoti njia chaguo-msingi kuelekea mtoa huduma wako, pakiti haingii kamwe kwenye handaki, na hakuna sheria kwenye ruta inayoweza kuiponya.

Upande wa handaki una toleo lake la swali. WireGuard huichukulia AllowedIPs kama jedwali la uelekezaji la ufunguo wa usimbaji: kwenye kila mwisho hutangaza anwani zipi za chanzo rika anaweza kutumia na ni maeneo gani yanayotumwa kwa rika huyo. Ikiwa ingizo la mteja halijumuishi anwani ya handaki ya ruta, mteja hana njia ya kufika huko. Ikiwa ingizo la seva kwa mteja huyo halifuniki anwani ya handaki ya mteja, seva hutupa pakiti kabla ya kuangalia sheria yoyote ya ngome ya moto.

Hakikisha anwani kamili unayotarajia kufikia kabla ya kutafuta hitilafu za sera. Rekodi ya DNS iliyopitwa na wakati au ingizo la jirani lililohifadhiwa kabla ya mabadiliko hukupeleka kwenye anwani ambayo ruta haijawahi kuimiliki.

Tabaka la pili: sera ya kuingia, si sera ya uelekezaji

Ngome za moto hutathmini sheria kwenye kiolesura ambacho pakiti hufika. Kwenye pfSense na OPNsense kichupo cha kiolesura na mpangilio wa sheria huamua ikiwa trafiki kuelekea huduma za ngome yenyewe inaruhusiwa; sheria inayowaruhusu wateja wa LAN kutoka kwenye intaneti si sheria inayomruhusu rika wa handaki kufungua kiolesura cha wavuti. Kwenye OpenWrt iliyo na firewall4 kila eneo hubeba sera ya kuingia, option input 'ACCEPT' au 'REJECT', na kiolesura cha handaki katika eneo lenye kuingia REJECT kitakataa miunganisho ya usimamizi huku kikiendelea kuelekeza trafiki ikiwa uelekezaji unaruhusiwa.

Usizime sheria ya kuzuia kufungwa ili njia mpya ifanye kazi. Sheria hiyo huzuia sheria mbaya kufunga anwani ya usimamizi ya LAN; inalinda subneti ya LAN, si subneti ya handaki uliyotengeneza sasa hivi. Ongeza sheria moja nyembamba kwa chanzo cha msimamizi na uache wavu wa usalama ukiwa kama ulivyo. Nyaraka za pfSense kuhusu ufikiaji wa msimamizi zinaeleza wapi vidhibiti hivyo vilipo.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Tabaka la tatu: je, kuna kitu kinasikiliza kwenye anwani hiyo?

Huduma inaweza kuwa inaendesha na bado isifikike kwa sababu imejifunga kwenye anwani moja. uhttpd ya OpenWrt huhifadhi ingizo wazi za kusikiliza katika /etc/config/uhttpd, kwa mfano list listen_http '0.0.0.0:80'; ujenzi unaojifunga kwenye anwani ya LAN pekee haukubali chochote kwenye anwani ya handaki, na bidhaa zinazoonyesha mpangilio wa kiolesura cha kusikiliza hufanya vivyo hivyo. Amri za kusikiliza zilizo juu hujibu hili moja kwa moja.

Kisha tenganisha kukataa na ukimya. nc -vz 10.6.0.1 443 inayorudisha muunganisho uliokataliwa inamaanisha pakiti ilifika kwenye ruta na kitu kiliikataa, ama lango lililofungwa au sheria wazi ya kukataa. Kuning'inia hadi muda uishe inamaanisha pakiti ilitupwa au haikuwahi kuelekezwa. Tofauti hiyo inakuambia tabaka gani la kuchunguza baadaye, na inagharimu sekunde tano.

Kiolesura cha VPN ni mpaka, si njia ya kurejesha

Usimbaji hulinda waya; hausemi chochote kuhusu nani anaruhusiwa kufungua ukurasa wa usimamizi. Handaki ikiisha kufanya kazi, pinga hamu ya kutatua ufikiaji kwa kuruhusu kila kitu kwenye kiolesura cha handaki. Wape wasimamizi sheria iliyofungwa kwenye anwani yao ya handaki au handaki tofauti ya wasimamizi pekee, na waweke watumiaji wa kawaida, NAS, kamera na kompyuta za familia mbali na lango la usimamizi. Rika anayehitaji kushiriki faili hapaswi kuwa sheria moja kutoka kwa kuingia kwa ruta.

Jukumu la ruta hubadilisha jibu. Ruta inayomaliza handaki inaweza kukubali wasimamizi kutoka humo kwa haki, ilhali ruta inayotumia handaki tu kama njia ya kutoka intaneti kwa kawaida haipaswi. Katika hali zote mbili ruhusa ya subneti si kuingia, kwa hiyo acha uthibitishaji wa akaunti na usalama wa usafirishaji ukiwa washa.

Hatua ya kufidia ambayo watu hufanya baada ya kufungwa ni mbaya zaidi: kuwasha usimamizi wa WAN au kuelekeza lango kwenye kiolesura cha wavuti. Hiyo hubadilisha usumbufu mfupi kuwa mfiduo wa kudumu, na ukurasa wa kuingia unaweza kufikiwa na kila kichanganuzi kwenye intaneti. Jaribu pia upande uliokataliwa, si ule ulioruhusiwa tu, ili rika asiyepaswa kuwa na ufikiaji wa msimamizi apate muda kuisha au kukataliwa badala ya ombi la kuingia.

Jaribu pia kwa muunganisho mpya. Ngome ya moto yenye hali huhifadhi mitiririko iliyopo kwenye jedwali lake la hali, kwa hiyo kikao cha SSH ulichokwisha kufungua kinaweza kustahimili mabadiliko yanayozuia kila muunganisho mpya. Ndiyo jinsi kufungwa kunabaki kusikoonekana hadi kuwasha upya kunakofuata au usingizi unaofuata wa kompyuta.

Tayarisha njia ya kurudi kabla ya kugusa sera

Andika mambo manne kabla ya mabadiliko ya kwanza: jinsi utakavyofikia kifaa ikiwa handaki itakufa, kwa mfano konsoli ya mfululizo, konsoli ya mtoa huduma au mashine iliyo kwenye LAN; wapi usanidi wa sasa unaondolewa; sheria au njia moja utakayobadilisha; na jinsi utakavyorudisha kipengele hicho kwa usahihi. Kwenye OpenWrt sysupgrade -b /tmp/backup.tar.gz hunasa usanidi, na hariri hubaki zikisubiri hadi uci commit, jambo linalokupa utenguzi wa bei nafuu ikiwa utagundua kwa wakati. pfSense huweka historia ya usanidi, na AutoConfigBackup husaidia tu ikiwa ilikuwa imewashwa tayari. Ikiwa ruta inaendesha seti ya sheria za fail-closed, hakikisha njia ya matengenezo uliyopanga haiko ndani ya trafiki inayozuiwa na sheria hiyo, na kumbuka kuwa kuwasha upya hutumia tena sheria za kudumu badala ya kuzifuta.

Badilisha mpaka mmoja kwa jaribio, kisha jaribu kutoka muunganisho mpya badala ya shell uliyoiacha wazi. Ikiwa jaribio litashindikana, rudisha mabadiliko hayo moja kabla ya kugusa tabaka linalofuata. Handaki inaweza kubaki juu muda wote, lakini aikoni yake ya hali ya kijani si uthibitisho kwamba bado unaweza kuingia.

Ukaguzi wa haraka kabla ya kuondoka:

• Je, unaweza kufikia ruta kutoka chanzo kisichotegemea sheria uliyohariri sasa hivi?
• Je, sera ya kuingia kwenye kiolesura cha handaki inaruhusu chanzo cha msimamizi pekee?
• Je, huduma ya usimamizi imefungwa kwenye anwani iliyopo kwenye handaki?
• Je, umejaribu rika mmoja aliyekataliwa na kikao kimoja kipya?
• Je, uso wa usimamizi wa WAN bado umefungwa?