NAS neatingebla tra la VPN: adreso, revena vojo aŭ servo?
Privata tunelo bezonas itineron al la NAS, respondan vojon kaj permesitan servon. Decidu, kiu el la tri malsukcesis, antaŭ ol ŝanĝi la legitimilojn.
Tuneloj ekfunkcias, klientoj ricevas adreson, kaj la NAS respondas absolute nenion. Tiu sola simptomo kovras tri sendependajn paneojn, kaj la ordo, en kiu vi testas ilin, decidas kiom longe daŭros la riparo. Adresado venas unue, ĉar interkovranta subreto povas sendi vian peton al fremda aparato. La revena vojo venas due, ĉar peto, kiu alvenas sen respondo, aspektas idente al fermita servo. Servo kaj permeso venas laste, kaj nur post kiam la unuaj du estas pruvitaj.
Tri paneoj, kiuj ĉiuj legiĝas kiel neatingebla
Adreselekto, revena enkursigo kaj serva rajtigo produktas la saman videblan mesaĝon: nenio okazas. Ili havas malsamajn pruvojn, malsamajn respondeculojn kaj malsamajn riparojn, do la apartigo de ili estas la tuta tasko. Ping, kiu malsukcesas, pruvas malmulte sole, kaj sukcesa TCP-rifuzo estas fakte bona novaĵo.
| 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 |
Legu la tabelon kiel ordon de testoj kaj ne kiel liston de kaŭzoj. Ĉiu vico limigas la sekvan, ĉar rifuzo jam pruvas, ke adresado kaj la revena vojo funkcias. Pasigi dudek minutojn en fajroŝirmaj reguloj antaŭ ol kontroli, kiun interfacon la itinero elektis, estas la plej ofta maniero perdi posttagmezon. Laboru de supre malsupren kaj haltu ĉe la unua vico, kiu kongruas.
Kondiĉo unu: ĉu tiu adreso estas la ĝusta aparato?
Notu la subreton de la NAS kaj la intervalon, kiun la VPN donas al klientoj, kaj komparu ambaŭ kun la reto, en kiu via tekkomputilo nun estas. En ĉi tiu trairo la NAS estas ĉe 10.40.7.25 kaj la VPN-grupo estas 10.40.9.0/24, du apartaj privataj intervaloj ene de unu reteja plano; hejmo, kiu uzas 192.168.0.0/24 aŭ 10.0.0.0/24, havas multe pli grandan ŝancon kolizii kun unu el ili.
Kiam la loka reto kaj la NAS-reto interkovriĝas, la kliento sendas tiun trafikon al sia propra enirejo kaj povas atingi nerilatan aparaton, kiu hazarde havas la saman adreson. Kontrolu la vojon antaŭ ol tajpi legitimilojn en ion ajn, kio respondas.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25
La unua komando nomas la interfacon kaj la enirejon, kiujn la kerno uzus, kaj la dua montras la unuajn saltojn, kiuj efektive respondas. Se la du malkongruas, kredu la serĉon, ĉar tio estas la vojo, kiun la paketo sekvos. Salta listo, kiu haltas unu salton antaŭ la NAS, estas ankaŭ konkludo kaj ne malsukceso. Serĉo, kiu solviĝas al la fizika adaptilo anstataŭ al la tunelo, finas la esploron ĉe tiu ĉi punkto.
Kondiĉo du: ĉu la respondo revenas?
La kliento bezonas itineron al la NAS, kaj la NAS-reto bezonas revenan vojon al la VPN-grupo. Enireja plusendado, fajroŝirmaj reguloj kaj intenca traduko ĉiu influas tiun paron. la plusendaj notoj de strongSwan priskribas la eblojn pri revena itinero kaj traduko por privata subreto malantaŭ enirejo.
Kiam la peto alvenas kaj la respondo eliras tra alia enirejo, neniu DNS-ŝanĝo riparas la malsimetrion. Kapto sur ambaŭ flankoj solvas ĝin per unu provo, kaj ĝi ankaŭ montras, ĉu traduko reverkis la fonton, al kiu la NAS respondis. La administranto posedas tiun limon: permesu nur la necesajn servojn kaj la VPN-klientan intervalon, kaj notu, ĉu oni elektis enkursigon aŭ tradukon.
Kondiĉo tri: ĉu la servo ekzistas kaj estas permesita?
Administra paĝo kaj dosierkomuniga servo estas malsamaj finpunktoj sur la sama maŝino, kaj unu povas akcepti konektojn dum la alia estas blokata de la gastiga fajroŝirmilo, de la serva agordo aŭ de komuniga permeso. Aparato, kiu respondas per rifuzo, jam pruvis la unuajn du kondiĉojn, kio konsiderinde mallarĝigas la trian.
Testu per la konto, kiu efektive bezonas la dosierojn, ne per la administranta konto uzita dum la instalado, ĉar administraj rajtoj ne povas ripari mankantan itineron, kaj itinero ne povas doni komunigan permeson. Ankaŭ nomoj apartenas ĉi tien: NAS-nomo malkovrita hejme ofte dependas de loka multelsendo, kiun enkursigita tunelo ne transportas, do provu la dokumentitan privatan gastignomon de la fabrikanto aŭ la adreson mem por apartigi nomadon de aliro.
Testu de ekster la NAS-reto, poste vastigu malrapide
Testo farita en la sama LAN kaŝas ĉiun nekompletan parton de la fora vojo, kaj tial la unua sukcesa fora provo meritas noton en la ŝanĝprotokolo. Rulu la kontrolojn de kliento, kiu atingas la NAS nur tra la tunelo, kaj konservu la originan erartekston de ĉiu provo.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest
Post kiam la vojo funkcias, transigu sendanĝeran dosieron kaj konfirmu la legadon aŭ skribadon, kiun vi efektive bezonas. Se grandaj transigoj haltas dum malgrandaj sukcesas, la restanta problemo estas la traktado de paketa grando aŭ la stabileco de la konekto, ne la adresado.
Ne publikigu dosierkomunigajn aŭ administrajn pordojn en la interreto por ĉirkaŭiri neklarigitan paneon. Riparu la privatan vojon, tenu la NAS-programaron subtenata, kaj testu la restarigon de ĉio, kion vi savkopias tra ĝi, antaŭ ol fidi tiun savkopion.