Távoli hozzáférés vagy site-to-site VPN: melyik illik?

Az utazó munkatársnak és a fiókirodának különböző alagutakra van szüksége, és a rossz választás olyan kialakítást ad, amely a laborban működik, és az első hétfőn elbukik. A távoli hozzáférés egy eszközt köt össze egy átjáróval. A site-to-site két átjárót köt össze, amelyek hálózatokat képviselnek. Az alábbi ellenőrzőlista eldönti, melyiket írja le valójában a követelmény.

Ki tárcsáz, és mi van a tárcsázó mögött

Távoli hozzáférésnél a laptopon vagy telefonon futó szoftver építi fel az alagutat, az átjáró pedig a cím és az útvonalak kiosztása előtt hitelesíti a felhasználót, az eszközt vagy mindkettőt. Site-to-site esetén routerek, tűzfalak vagy felhőátjárók hozzák létre a kapcsolatot, a mögöttük lévő eszközök pedig hagyományos útválasztást használnak kliens futtatása helyett. Ez a különbség dönti el, ki felel az alagút rendelkezésre állásáért: az első esetben a munkatárs eszköze, a másodikban egy kezelt készülék. Azt is eldönti, hogy a hitelesítés egy személyt vagy egy hálózatot ír le.

Álljon meg itt, ha a követelmény az, hogy az egyik iroda minden gépe eszközönkénti beállítás nélkül elérje a másik irodát. Az site-to-site, és a távoli hozzáférésű bejelentkezések halmaza gyenge helyettesítő.

Címzés és a visszaút

Tervezzen külön helyi és távoli tartományokat. Két hely ugyanazt a privát alhálózatot használhatja, és ilyenkor a kialakításnak fordításra vagy újraszámozásra van szüksége, mielőtt az útválasztás egyértelmű lehet. A központtal azonos tartományt használó otthoni router ugyanezt a problémát okozza egy távoli munkatársnak. Az átfedés elég gyakori ahhoz, hogy ellenőrzése az első beszélgetés része legyen.

A visszaút ugyanolyan fontos, mint a kimenő út. Egy kiszolgáló fogadhat kérést, és mégsem lehet útvonala vissza az ügyfél hálózatába.

Dokumentálja, melyik router ismeri a távoli előtagot, különösen felhőhálózatok és több átjáró esetén. Egy zöld alagút ikon nem tud válaszolni arra, hogy egy célállomásnak van-e működő visszaútja, és az egyirányú ping sem. Távoli hozzáférésnél az átjáró birtokolja általában a pool útvonalát; site-to-site esetén minden köztes routernek egyet kell értenie, amely az előtagot hordozza. A fordítás elrejthet egy hiányzó útvonalat, amíg egy címeket beágyazó alkalmazás el nem törik.

Az internetes kilépés külön döntés

A privát elérhetőség nem követeli meg, hogy az alagút nyilvános böngészést szállítson. Hogy a szokásos webtraffic kilép-e az átjárón, második döntés, amelyet kialakításonként hoznak meg, és az ügyfélprofilban vagy a hely konfigurációjában rögzítenek.

A teljes és az osztott alagút erre a kérdésre ad választ, nem a távoli hozzáférés kontra site-to-site kérdésre. A belső neveknek mindkét kialakításban megfelelő DNS kell, mert egy nyilvános feloldó nem tud választ adni egy privát irodai gépnévre. Feloldó küldése és alapértelmezett útvonal küldése összefüggő beállítások, és az egyik megváltoztatása a másik nélkül DNS-problémáknak látszó hibákat okoz.

A topológiával szűkítse a hibát

Egy barangoló laptop elveszti a hozzáférést az ügyfélnél, a fiókjánál vagy a helyi hálózatánál. Egy egész fiókiroda elveszti a hozzáférést a megosztott útvonalaknál és átjáróknál.

Először az alagút felépítését ellenőrizze, aztán az útvonalakat, aztán az engedélyezett forgalmat, aztán a névfeloldást, aztán az alkalmazásba való bejelentkezést, és álljon meg az első lépésnél, amely elbukik.ip route get 10.60.8.15 egyetlen alkalmazásnapló elolvasása előtt válaszol az útválasztási kérdésre. A titkosítási beállítások nem javítanak egy fájlmegosztási engedélyhibát, és egy működő ping nem bizonyítja, hogy egy alkalmazás jogosult. A sorrend megtartása megakadályozza a véletlenszerű konfigurációmódosításokat, amelyek egy hibából hármat csinálnak.

Végül tartsa egyenesen a definíciókat, amikor szállítói anyagot olvas: a kereskedelmi internetkilépő kiszolgáló más szolgáltatás, mint egy vállalat privát átjárója, és nem ad hozzáférést a vállalat hálózatához.