NAS haipatikani kupitia VPN: anwani, njia ya kurudi au huduma?
Tuneli ya kibinafsi inahitaji njia kuelekea NAS, njia ya jibu na huduma inayoruhusiwa. Amua ni ipi kati ya tatu iliyoshindikana kabla ya kubadilisha vitambulisho.
Tuneli zinapanda, wateja wanapata anwani, na NAS haijibu kabisa. Dalili hii moja inafunika hitilafu tatu zisizohusiana, na mpangilio wa kuzijaribu huamua ukarabati utachukua muda gani. Uwekaji anwani huja kwanza, kwa sababu subnet inayopishana inaweza kutuma ombi lako kwa kifaa geni. Njia ya kurudi huja pili, kwa sababu ombi linalofika bila jibu linaonekana sawa na huduma iliyofungwa. Huduma na ruhusa huja mwisho, na tu baada ya mbili za kwanza kuthibitika.
Hitilafu tatu ambazo zote zinasomwa kama haipatikani
Uchaguzi wa anwani, uelekezaji wa kurudi na uidhinishaji wa huduma huzalisha ujumbe ule ule unaoonekana: hakuna kinachotokea. Zina ushahidi, wamiliki na marekebisho tofauti, kwa hivyo kuzitenganisha ndio kazi yote. Ping inayoshindikana huthibitisha kidogo yenyewe, na kukataliwa kwa TCP kwa mafanikio ni habari njema kwa kweli.
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
Soma jedwali kama mpangilio wa majaribio na si orodha ya sababu. Kila mstari huzuia unaofuata, kwa sababu kukataliwa tayari kunathibitisha kwamba uwekaji anwani na njia ya kurudi hufanya kazi. Kutumia dakika ishirini ndani ya kanuni za firewall kabla ya kuangalia ni kiolesura kipi njia ilichagua ni njia ya kawaida zaidi ya kupoteza mchana. Fanya kazi kutoka juu hadi chini na usimame kwenye mstari wa kwanza unaolingana.
Sharti la kwanza: je, anwani hiyo ni kifaa sahihi?
Andika subnet ya NAS na masafa ambayo VPN inawapa wateja, kisha linganisha yote mawili na mtandao ambao kompyuta yako ndogo iko sasa. Katika mwongozo huu NAS iko kwenye 10.40.7.25 na dimbwi la VPN ni 10.40.9.0/24, masafa mawili tofauti ya kibinafsi ndani ya mpango mmoja wa tovuti; kaya inayotumia 192.168.0.0/24 au 10.0.0.0/24 ina nafasi kubwa zaidi ya kugongana na moja wapo.
Mtandao wa ndani na mtandao wa NAS unapopishana, mteja hutuma trafiki hiyo kwenye lango lake mwenyewe na anaweza kufikia kifaa kisichohusiana ambacho kwa bahati kina anwani hiyo hiyo. Thibitisha njia kabla ya kuandika vitambulisho kwenye kitu chochote kinachojibu.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25
Amri ya kwanza inataja kiolesura na lango ambalo kernel ingetumia, na ya pili inaonyesha hops za kwanza zinazojibu kweli. Ikiwa hizo mbili hazilingani, amini utafutaji, kwa sababu ndiyo njia ambayo pakiti itapita. Orodha ya hops inayosimama hop moja kabla ya NAS pia ni ugunduzi na si kushindikana. Utafutaji unaotatuliwa kwa adapta halisi badala ya tuneli humaliza uchunguzi hapa.
Sharti la pili: je, jibu linarudi?
Mteja anahitaji njia kuelekea NAS, na mtandao wa NAS unahitaji njia ya kurudi kuelekea dimbwi la VPN. Upelekaji wa lango, kanuni za firewall na tafsiri ya kusudi kila moja huathiri jozi hiyo. Maelezo ya strongSwan kuhusu upelekaji zinaeleza chaguo za njia ya kurudi na tafsiri kwa subnet ya kibinafsi nyuma ya lango.
Ombi linapofika na jibu linatoka kwa lango lingine, hakuna mabadiliko ya DNS yanayorekebisha upendeleo huo. Unasaji pande zote mbili huamua hilo kwa jaribio moja, na pia huonyesha kama tafsiri iliandika upya chanzo ambacho NAS ilijibu. Msimamizi anamiliki mpaka huo: ruhusu huduma zinazohitajika tu na masafa ya wateja wa VPN, na andika kama uelekezaji au tafsiri ilichaguliwa.
Sharti la tatu: je, huduma iko na inaruhusiwa?
Ukurasa wa usimamizi na huduma ya kushiriki faili ni vituo tofauti kwenye mashine moja, na moja inaweza kupokea miunganisho wakati nyingine inazuiwa na firewall ya mwenyeji, usanidi wa huduma au ruhusa ya kushiriki. Kifaa kinachojibu kwa kukataa tayari kimethibitisha masharti mawili ya kwanza, jambo linalobana la tatu sana.
Jaribu kwa akaunti inayohitaji faili kweli, si akaunti ya msimamizi iliyotumika wakati wa usakinishaji, kwa sababu haki za usimamizi haziwezi kurekebisha njia inayokosekana na njia haiwezi kutoa ruhusa ya kushiriki. Majina pia yanahusika hapa: jina la NAS linalogunduliwa nyumbani mara nyingi hutegemea multicast ya ndani ambayo tuneli iliyoelekezwa haibebi, kwa hivyo jaribu jina la mwenyeji la kibinafsi lililoandikwa na mtengenezaji au anwani yenyewe ili kutenganisha uwekaji majina na ufikiaji.
Jaribu kutoka nje ya mtandao wa NAS, kisha panua polepole
Jaribio linalofanywa kwenye LAN moja huficha kila sehemu isiyokamilika ya njia ya mbali, ndiyo sababu jaribio la kwanza la mbali lililofanikiwa linastahili kumbukumbu kwenye kumbukumbu za mabadiliko. Endesha ukaguzi kutoka kwa mteja anayefikia NAS kwa tuneli pekee, na hifadhi maandishi ya awali ya hitilafu kwa kila jaribio.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest
Njia inapofanya kazi, hamisha faili isiyo na madhara na uthibitishe tabia ya kusoma au kuandika unayohitaji kweli. Ikiwa uhamishaji mkubwa unakwama wakati mdogo unafanikiwa, tatizo lililobaki ni ushughulikiaji wa ukubwa wa pakiti au uthabiti wa muunganisho, si uwekaji anwani.
Usichapishe milango ya kushiriki faili au usimamizi kwenye mtandao kwa ajili ya kukwepa hitilafu isiyoelezwa. Rekebisha njia ya kibinafsi, weka programu ya NAS ikiwa na msaada, na jaribu urejeshaji wa kila kitu unachohifadhi nakala kupitia hiyo kabla ya kutegemea nakala hiyo.