A NAS nem érhető el a VPN-en át: cím, visszaút vagy szolgáltatás?

Az alagutak feljönnek, az ügyfelek címet kapnak, a NAS pedig egyáltalán nem válaszol. Ez az egyetlen tünet három, egymástól független hibát takar, és a vizsgálat sorrendje dönti el, mennyi ideig tart a javítás. A címzés az első, mert egy átfedő alhálózat egy idegen eszközhöz küldheti a kérést. A visszaút a második, mert a válasz nélkül érkező kérés pontosan úgy néz ki, mint egy lezárt szolgáltatás. A szolgáltatás és az engedély az utolsó, és csak akkor, ha az első kettő bizonyított.

Három hiba, amelyek mind elérhetetlenként olvashatók

A címválasztás, a visszaútvonal-kezelés és a szolgáltatás-engedélyezés ugyanazt a látható üzenetet adja: semmi sem történik. Különböző bizonyítékaik, felelőseik és javításaik vannak, ezért a szétválasztásuk maga a feladat. Egy sikertelen ping önmagában keveset bizonyít, a sikeres TCP-elutasítás pedig valójában jó hír.

A táblázatot vizsgálati sorrendként olvassa, nem okok listájaként. Minden sor korlátozza a következőt, mert az elutasítás már bizonyítja, hogy a címzés és a visszaút működik. Húsz percet a tűzfal-szabályok között tölteni, mielőtt ellenőrzi, melyik interfészt választotta az útvonal, a leggyakoribb módja egy délután elvesztésének. Haladjon fentről lefelé, és álljon meg az első megfelelő sornál.

Első feltétel: az az eszköz a megfelelő eszköz?

Jegyezze fel a NAS alhálózatát és a tartományt, amelyet a VPN az ügyfeleknek ad, és hasonlítsa össze mindkettőt azzal a hálózattal, amelyben a laptopja éppen van. Ebben a végigvezetésben a NAS a 10.40.7.25 címen van, a VPN tartománya pedig 10.40.9.0/24, két külön privát tartomány egyetlen telephely-terven belül; egy háztartásnak, amely 192.168.0.0/24 vagy 10.0.0.0/24 címet használ, sokkal nagyobb az esélye, hogy összeütközik valamelyikkel.

Amikor a helyi hálózat és a NAS hálózata átfed, az ügyfél ezt a forgalmat a saját átjárójára küldi, és elérhet egy kapcsolatban nem álló eszközt, amelynek véletlenül ugyanaz a címe. Ellenőrizze az útvonalat, mielőtt hitelesítő adatokat ír be bármibe, ami válaszol.

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

Az első parancs megnevezi az interfészt és az átjárót, amelyet a kernel használna, a második pedig megmutatja az első ugrásokat, amelyek valóban válaszolnak. Ha a kettő nem egyezik, higgyen a lekérdezésnek, mert azon az úton halad a csomag. Az ugráslista, amely egy ugrással a NAS előtt megáll, szintén megállapítás, és nem kudarc. Az a lekérdezés, amely a fizikai adapterre oldódik fel az alagút helyett, ezen a ponton lezárja a vizsgálatot.

Második feltétel: visszajön a válasz?

Az ügyfélnek útvonalra van szüksége a NAS felé, a NAS hálózatának pedig visszaútra a VPN tartománya felé. Az átjáró továbbítása, a tűzfalszabályok és a szándékos címfordítás mindegyike hatással van erre a párra. A strongSwan továbbítási jegyzetei leírják a visszaút és a fordítás lehetőségeit egy átjáró mögötti privát alhálózat esetén.

Amikor a kérés megérkezik, és a válasz egy másik átjárón távozik, semmilyen DNS-módosítás nem javítja az aszimmetriát. A két oldalon végzett rögzítés egyetlen kísérlettel eldönti, és azt is megmutatja, hogy a fordítás átírta-e azt a forrást, amelyre a NAS válaszolt. Az adminisztrátor felelős ezért a határért: csak a szükséges szolgáltatásokat és a VPN-ügyfél tartományát engedélyezze, és jegyezze fel, hogy az útválasztást vagy a fordítást választották.

Harmadik feltétel: ott van a szolgáltatás, és engedélyezett?

A kezelőoldal és a fájlmegosztó szolgáltatás különböző végpontok ugyanazon a gépen, és az egyik fogadhat kapcsolatokat, miközben a másikat a gazdagép tűzfala, a szolgáltatás konfigurációja vagy egy megosztási engedély blokkolja. Az az eszköz, amely elutasítással válaszol, már bizonyította az első két feltételt, ami jelentősen szűkíti a harmadikat.

Azzal a fiókkal teszteljen, amelynek valóban szüksége van a fájlokra, ne a telepítéskor használt adminisztrátori fiókkal, mert az adminisztrátori jogok nem javíthatnak hiányzó útvonalat, és az útvonal nem adhat megosztási engedélyt. A nevek is ide tartoznak: az otthon felderített NAS-név gyakran helyi multicast-tól függ, amelyet egy útválasztott alagút nem visz át, ezért próbálja a gyártó által dokumentált privát gazdagépnevet vagy magát a címet, hogy elválassza a névfeloldást a hozzáféréstől.

A NAS hálózatán kívülről teszteljen, majd lassan bővítsen

Az ugyanazon a LAN-on végzett teszt elrejti a távoli útvonal minden hiányos részét, ezért az első sikeres távoli kísérlet bejegyzést érdemel a változási naplóban. A vizsgálatokat olyan ügyfélről futtassa, amely csak az alagúton keresztül éri el a NAS-t, és őrizze meg minden kísérlet eredeti hibaüzenetét.

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

Amikor az útvonal működik, vigyen át egy ártalmatlan fájlt, és erősítse meg a ténylegesen szükséges olvasási vagy írási viselkedést. Ha a nagy átvitelek elakadnak, miközben a kicsik sikerülnek, a fennmaradó probléma a csomagméret kezelése vagy a kapcsolat stabilitása, nem a címzés.

Ne tegyen közzé fájlmegosztó vagy adminisztrációs portokat az interneten egy megmagyarázatlan hiba megkerülésére. Javítsa a privát útvonalat, tartsa támogatottan a NAS szoftverét, és tesztelje azon keresztül készített mentések visszaállítását, mielőtt bízna abban a mentésben.