Adjon hozzá helyszíni VPN-t az ISP-router mellé a hívások megszakítása nélkül

Tartsa érintetlenül az ISP-router internet- és hangszerepét, miközben egy második átjáró viszi a privát útvonalat. Végezze el ezt az öt ellenőrzést, mielőtt bármelyik útvonalat módosítja.

A legtöbb kis telephelyen már van egy doboz, amely az internetet, a DHCP-t és a hangvonalat viszi, és ez a doboz nem fogja vinni a telephelyi alagutat. Egy második átjáró hozzáadása a privát útvonalhoz működik, ha a kábel megérintése előtt eldönti, kié melyik útvonal. Az igazi kockázat nem az alagút, hanem annak csendes cseréje, ami a telefonokat regisztrálva tartja. Végezze el az öt ellenőrzést sorrendben, és álljon meg ott, ahol az egyik elbukik.

Írja le a már működő szerepeket

Rögzítse az alapértelmezett átjárót, a DHCP-kiszolgálót, a névfeloldót és azt az eszközt, amelyen a szolgáltató hangregisztrációja van. Ebben a példában az ISP-router 10.50.0.1, az új átjáró 10.50.0.2 lesz, a távoli telephely pedig 10.60.0.0/24. Ebben a tervben semmi nem változtatja meg az első három szerepet, és éppen ez a lényeg. Ezután ellenőrizze, hogy a második doboz valóban le tudja zárni a szükséges alagutat: nézze meg a protokollt, a várt átbocsátóképességet, és hogy kap-e firmware- vagy csomagfrissítést. A VPN-logós, frissítési útvonal nélküli eszköz teher, nem bővítés.

Ha nem tudja megmondani, kié a hangszolgáltatás, álljon meg. A regisztrációt tartó router visszaállítási terv nélküli cseréje a VPN-projektet telefonkieséssé teszi.

Adjon az új átjárónak egy címet és egy feladatot

Foglalja le a LAN-címét a DHCP-készleten kívül, hogy újraindítás után ne mozduljon el, és ne adjon neki saját alapértelmezett útvonalat, hacsak nem akarja internetes útvonallá tenni. A feladata az alagút tartása és a távoli előtagokért való válaszadás. Azokon a LAN-gazdákon, amelyeknek el kell érniük a távoli telephelyet, bizonyítsa, melyik útvonalat használják most, és melyiket akarja a változtatás után; ugyanaz a két parancs előtte és utána a legolcsóbb bizonyíték.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Ha a keresés az ISP-routert adja vissza, és a traceroute az internet peremén meghal, a gazdának még nincs távoli útvonala, ami várható. Ha valami váratlant ad vissza, előbb azt oldja meg, mert minden későbbi lépés ezt az alapot feltételezi.

Válassza ki, kié a távoli előtag útvonala

Az A lehetőség az ISP-router: statikus útvonalat tart a 10.60.0.0/24-hez az átjáró felé, és minden gazda úgy követi az alapértelmezett átjáróját, mint korábban. A B lehetőség gazdánkénti: csak azok a gépek kapnak kifejezett útvonalat a 10.50.0.2-n keresztül, amelyeknek kell a távoli telephely, minden más érintetlen marad. Az A sok gazdánál tisztább, de általában megköveteli, hogy a szolgáltató routere elfogadjon egy statikus útvonalat, amit egyesek nem tesznek. A B nem igényel együttműködést a szolgáltatótól, de a gazdák konfigurációjának karbantartását Önnél hagyja, ezért kis, jóváhagyott géphalmazhoz illik.

Mindkét esetben léteznie kell a visszaútnak. Ha egy távoli válasz az átjáróhoz érkezik, és az átjáró egyenesen egy LAN-gazdához továbbítja, a forgalom megkerüli azt a tűzfal-állapotot, amelyet az ISP-router a kifelé vezető úton tartott. Amikor az átjáró nem a LAN alapértelmezett routere, ez az aszimmetria tervezési döntés, nem figyelmen kívül hagyható hiba.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Tegye állandóvá a bejegyzést a gazda konfigurációjának gazdája révén, ne bejelentkezési szkripttel. Az az útvonal, amely csak valaki bejelentkezése után létezik, először akkor bukik el, amikor a gépet egy független okból újraindítják.

Alakítson ki elérhető bejövő végpontot

Az átjárónak olyan cím kell, amelyet a távoli telephely elér. Az ISP-router mögött ez porttovábbítást vagy DMZ-bejegyzést jelent, és mindkettő attól függ, hogy a szolgáltató valóban kézbesíti-e a forgalmat. A helyi továbbítás nem győzi le a szolgáltató oldali operátori NAT-ot. Ha a szolgáltató nem ad elérhető pontot, fordítsa meg az irányt: hagyja, hogy mindkét telephely az Ön által vezérelt hub felé kezdeményezzen. Ez érvényes tervezés, de harmadik függőséget ad a továbbításhoz, a bizalomhoz és az elérhetőséghez, és a dinamikus DNS nem pótolja.

Erősítse meg a továbbítást az átjárón készült rögzítéssel, ne portokat szkennelő webhellyel. A szkennerek zártként jelentik a portot, amíg a figyelő nem kötődik, és a soha forgalmat nem kézbesítő továbbítás kívülről ugyanúgy néz ki, mint egy zárt port.

Fogadja el a privát szolgáltatást és a hangvonalat együtt

Tesztelje a tervezett működést LAN-gazdáról, privát DNS-sel és az alkalmazás saját hitelesítő adataival. Az útvonalazott alagút nem teszi a távoli böngészést helyi Ethernet-szegmenssé, ezért a felderítésnek és a névfeloldásnak saját megoldás kell.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Ezután erősítse meg, hogy a szokásos internetelérés ugyanarról a gazdáról még működik, és a telefonok még regisztráltak; ez a két ellenőrzés kapja el az alapértelmezett útvonal véletlen változását, ami a leggyakoribb módja annak, hogy ez a projekt elrontson valamit, amihez soha nem akart nyúlni. Fejezze be írásos helyreállítási feljegyzéssel: melyik eszköz melyik szerepet viszi, a lefoglalt címek, és hogyan távolítható el a távoli előtag útvonala egy lépésben. Többet ér az a privát útvonal, amely tisztán visszavonható, mint amelyik csak ma működik.

Kapcsolódó cikkek