NAS onbereikbaar via de VPN: adres, terugroute of dienst?

Tunnels komen omhoog, clients krijgen een adres, en de NAS antwoordt helemaal niets. Dat ene symptoom dekt drie losstaande fouten, en de volgorde waarin u ze test bepaalt hoe lang de reparatie duurt. Adressering komt eerst, omdat een overlappend subnet uw verzoek naar een vreemd apparaat kan sturen. Het terugpad komt tweede, omdat een verzoek dat zonder antwoord aankomt er precies zo uitziet als een gesloten dienst. Dienst en toestemming komen als laatste, en pas nadat de eerste twee zijn bewezen.

Drie fouten die allemaal als onbereikbaar worden gelezen

Adreskeuze, terugroutering en dienstautorisatie leveren hetzelfde zichtbare bericht op: er gebeurt niets. Ze hebben verschillend bewijs, verschillende eigenaren en verschillende oplossingen, dus het scheiden ervan is de hele opgave. Een ping die mislukt bewijst op zichzelf weinig, en een geslaagde TCP-weigering is juist bemoedigend nieuws.

Lees de tabel als een volgorde van tests in plaats van een lijst met oorzaken. Elke rij beperkt de volgende, omdat een weigering al bewijst dat adressering en het terugpad werken. Twintig minuten in firewallregels doorbrengen voordat u controleert welke interface de route koos, is de meest voorkomende manier om een middag te verliezen. Werk van boven naar beneden en stop bij de eerste rij die past.

Voorwaarde één: is dat adres het juiste apparaat?

Schrijf het NAS-subnet op en het bereik dat de VPN aan clients uitgeeft, en vergelijk beide met het netwerk waarop uw laptop nu zit. In deze uitleg staat de NAS op 10.40.7.25 en is de VPN-pool 10.40.9.0/24, twee aparte particuliere bereiken binnen één siteplan; een huishouden dat 192.168.0.0/24 of 10.0.0.0/24 gebruikt, heeft een veel grotere kans om met een van beide te botsen.

Wanneer het lokale netwerk en het NAS-netwerk overlappen, stuurt de client dat verkeer naar zijn eigen gateway en kan hij een ongerelateerd apparaat bereiken dat toevallig hetzelfde adres heeft. Controleer het pad voordat u inloggegevens typt in wat er ook antwoordt.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

De eerste opdracht noemt de interface en gateway die de kernel zou gebruiken, en de tweede toont de eerste hops die daadwerkelijk antwoorden. Als de twee het oneens zijn, geloof de opzoeking, want dat is het pad dat het pakket zal nemen. Een hoplijst die één hop voor de NAS stopt, is ook een bevinding en geen mislukking. Een opzoeking die naar de fysieke adapter in plaats van de tunnel uitkomt, beëindigt het onderzoek op dit punt.

Voorwaarde twee: komt het antwoord terug?

De client heeft een route naar de NAS nodig, en het NAS-netwerk heeft een terugpad naar de VPN-pool nodig. Gateway-doorsturing, firewallregels en bewuste vertaling beïnvloeden elk dat paar. De doorstuurmededelingen van strongSwan beschrijven de keuzes voor terugroute en vertaling voor een particulier subnet achter een gateway.

Wanneer het verzoek aankomt en het antwoord via een andere gateway vertrekt, herstelt geen enkele DNS-wijziging de asymmetrie. Een capture aan beide kanten beslecht het in één poging, en laat ook zien of vertaling de bron heeft herschreven waarop de NAS antwoordde. De beheerder is eigenaar van die grens: sta alleen de benodigde diensten en het VPN-clientbereik toe, en schrijf op of er voor routering of vertaling is gekozen.

Voorwaarde drie: is de dienst er en is hij toegestaan?

Een beheerpagina en een bestandsdelingsdienst zijn verschillende eindpunten op dezelfde machine, en de ene kan verbindingen accepteren terwijl de andere wordt geblokkeerd door de host-firewall, de dienstconfiguratie of een deelrechten. Een apparaat dat met een weigering antwoordt, heeft de eerste twee voorwaarden al bewezen, wat de derde aanzienlijk vernauwt.

Test met het account dat de bestanden echt nodig heeft, niet met het beheerdersaccount uit de installatie, want beheerdersrechten kunnen geen ontbrekende route repareren en een route kan geen deelrechten geven. Namen horen hier ook bij: een NAS-naam die thuis wordt ontdekt, hangt vaak af van lokale multicast, die een gerouteerde tunnel niet meeneemt, dus probeer de gedocumenteerde particuliere hostnaam van de leverancier of het adres zelf om naamgeving van toegang te scheiden.

Test van buiten het NAS-netwerk en breid dan langzaam uit

Een test op hetzelfde LAN verbergt elk onvolledig deel van het externe pad, en daarom verdient de eerste geslaagde externe poging een notitie in het wijzigingsregister. Voer de controles uit vanaf een client die de NAS alleen via de tunnel bereikt, en bewaar de oorspronkelijke fouttekst van elke poging.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Zodra het pad werkt, draagt u een onschadelijk bestand over en bevestigt u het lees- of schrijfgedrag dat u echt nodig hebt. Als grote overdrachten vastlopen terwijl kleine slagen, is het resterende probleem de afhandeling van pakketgrootte of de stabiliteit van de verbinding en niet de adressering.

Publiceer geen bestandsdelings- of beheerpoorten naar het internet om een onverklaarde fout te omzeilen. Repareer het particuliere pad, houd de NAS-software ondersteund, en test het terugzetten van alles wat u erover back-upt voordat u op die back-up vertrouwt.