NAS net berikber oer de VPN: adres, weromrûte of tsjinst?
In privee tunnel hat in rûte nei de NAS, in antwurdwei en in tastiene tsjinst nedich. Bepaal hokker fan de trije mislearre is foardat jo oanmeldgegevens feroarje.
Tunnels komme omheech, kliïnten krije in adres, en de NAS antwurdet hielendal neat. Dat iene symptoom dekt trije losse flaters, en de folchoarder wêryn jo se testje beslút hoe lang de reparaasje duorret. Adressearring giet earst, want in oerlappend subnet kin jo fersyk nei in frjemd apparaat stjoere. De weromwei komt twadde, want in fersyk dat oankomt sûnder antwurd liket gelyk oan in sletten tsjinst. Tsjinst en tastimming komme lêst, en pas neidat de earste twa bewiisd binne.
Trije flaters dy't allegear as net berikber lêzen wurde
Adreskar, weromrouting en tsjinstautorisearring leverje deselde sichtbere melding: der bart neat. Se hawwe oare bewizen, oare eigners en oare reparaasjes, dus it skieden derfan is de hiele taak. In ping dy't mislearret bewiist op himsels net folle, en in slagge TCP-wegering is eins goed nijs.
| 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 |
Lês de tabel as in folchoarder fan tests yn stee fan in list fan oarsaken. Elke rige beheint de folgjende, want in wegering bewiist al dat adressearring en de weromwei wurkje. Tweintich minuten yn firewallregels trochbringe foardat jo kontrolearje hokker ynterface de rûte keas, is de meast foarkommende manier om in middei te ferliezen. Wurkje fan boppe nei ûnderen en stopje by de earste rige dy't past.
Betingst ien: is dat adres it goede apparaat?
Skriuw it NAS-subnet op en it berik dat de VPN oan kliïnten jout, en fergelykje beide mei it netwurk dêr't jo laptop no op sit. Yn dizze rûn stiet de NAS op 10.40.7.25 en is de VPN-pool 10.40.9.0/24, twa aparte privee berikken yn ien siteplan; in húshâlding dy't 192.168.0.0/24 of 10.0.0.0/24 brûkt, hat in folle gruttere kâns om mei ien fan beide te botsen.
As it lokale netwurk en it NAS-netwurk oerlappe, stjoert de kliïnt dat ferkear nei syn eigen gateway en kin er in net besibbe apparaat berikke dat tafallich itselde adres hat. Ferifiearje it paad foardat jo oanmeldgegevens yn tikje by wat dan ek antwurdet.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25
It earste kommando neamt de ynterface en de gateway dy't de kernel brûke soe, en it twadde lit de earste hops sjen dy't echt antwurdzje. As de twa faninoar ferskille, leau de opfrege, want dat is it paad dat it pakket nimme sil. In hoplist dy't ien hop foar de NAS stopt, is ek in befining yn stee fan in mislearring. In opfrege dy't nei de fysike adapter yn stee fan de tunnel útkomt, einiget it ûndersyk op dit punt.
Betingst twa: komt it antwurd werom?
De kliïnt hat in rûte nei de NAS nedich, en it NAS-netwurk hat in weromwei nei de VPN-pool nedich. Gateway-foartsjen, firewallregels en bewuste oersetting beynfloedzje elk dat pear. De foartsjen-notys fan strongSwan beskriuwe de karren foar weromrûte en oersetting foar in privee subnet efter in gateway.
As it fersyk oankomt en it antwurd fia in oare gateway fuortgiet, reparearret gjin DNS-wiziging de asymmetry. In opname oan beide kanten besljochtet it yn ien poging, en it lit ek sjen oft oersetting de boarne weromskreaun hat dêr't de NAS op antwurde. De behearder is eigner fan dy grins: tastie allinnich de ferplichte tsjinsten en it VPN-kliïntberik, en skriuw op oft foar routing of oersetting keazen is.
Betingst trije: is de tsjinst der en tastien?
In behearspagina en in bestândieltsjinst binne ferskillende einpunten op deselde doaze, en de iene kin ferbinings oannimme wylst de oare troch de host-firewall, de tsjinstkonfiguraasje of in dieltastimming blokkearre wurdt. In apparaat dat mei in wegering antwurdet, hat de earste twa betingsten al bewiisd, wat de tredde flink beheint.
Test mei it akkount dat de bestannen echt nedich hat, net it beheardersakkount fan de ynstallaasje, want behearderrjochten kinne gjin ûntbrekkende rûte reparearje en in rûte kin gjin dieltastimming jaan. Nammen hearre hjir ek by: in NAS-namme dy't thús ûntdutsen wurdt, hinget faak fan lokale multicast ôf, dy't in routearre tunnel net draacht, dus probearje de dokumintearre privee hostnamme fan de fabrikant of it adres sels om nammejouwing fan tagong te skieden.
Test fan bûten it NAS-netwurk, en wreidzje dan stadich út
In test op itselde LAN ferberget elk ûnfolslein diel fan it remote paad, en dêrom fertsjinnet it earste slagge remote besykjen in notysje yn it feroaringsregister. Rin de kontrôles fan in kliïnt dy't de NAS allinnich fia de tunnel berikt, en bewarje de oarspronklike flatertekst fan elk besykjen.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest
Sadree't it paad wurket, ferpleats in harmless bestân en befêstigje it lês- of skriuwgedrach dat jo echt nedich hawwe. As grutte oerdrachten fêstrinne wylst lytse slagje, is it oerbleaune probleem pakketgrutte-ôfhanneling of ferbiningsstabiliteit yn stee fan adressearring.
Publisearje gjin bestândiel- of behearsports nei it ynternet om in ûnferklearre flater te omgean. Reparearje it privee paad, hâld de NAS-software stipe, en test it weromsetten fan alles wat jo deroer befeiligje foardat jo op dy reserve fertrouwe.