Adăugați un VPN de site lâng routerul ISP fără a întrerupe apelurile

Păstrați intacte rolurile de internet și voce ale routerului ISP, iar un al doilea gateway să țină calea privată. Faceți aceste cinci verificări înainte de a schimba vreo rută.

Majoritatea site-urilor mici au deja o cutie care face internet, DHCP și linia de voce, iar acea cutie nu va rula tunelul site-ului. Adăugarea unui al doilea gateway pentru calea privată funcționează dacă stabiliți cine deține fiecare rută înainte de a atinge un cablu. Riscul real nu este tunelul, ci înlocuirea în tăcere a echipamentului care ține telefoanele înregistrate. Faceți cele cinci verificări în ordine și opriți-vă unde una eșuează.

Notați rolurile care funcționează deja

Înregistrați gateway-ul implicit, serverul DHCP, resolverul și echipamentul care are înregistrarea de voce a furnizorului. În acest exemplu routerul ISP este 10.50.0.1, noul gateway va fi 10.50.0.2, iar site-ul îndepărtat este 10.60.0.0/24. Nimic din acel plan nu schimbă primele trei roluri, și exact acesta este ideea. Apoi confirmați că a doua cutie poate termina într-adevăr tunelul: verificați protocolul, debitul așteptat și dacă primește actualizări de firmware sau de pachete. Un echipament cu siglă VPN și fără cale de actualizare este o povară, nu un plus.

Dacă nu puteți spune cine deține serviciul de voce, opriți-vă. Înlocuirea routerului care are o înregistrare fără un plan de revenire transformă un proiect VPN într-o pană telefonică.

Dați noului gateway o adresă și o sarcină

Rezervați adresa lui LAN în afara pool-ului DHCP ca să nu se mute după o repornire, și nu-i dați o rută implicită proprie decât dacă vreți să devină o cale de internet. Sarcina lui este să țină tunelul și să răspundă pentru prefixele îndepărtate. Pe hosturile din LAN care trebuie să ajungă la site-ul îndepărtat, demonstrați ce rută folosesc acum și pe care o vreți după schimbare; aceleași două comenzi înainte și după sunt cea mai ieftină dovadă.

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

Dacă interogarea returnează routerul ISP și traceroute moare la marginea internetului, hostul nu are încă o rută îndepărtată, ceea ce este de așteptat. Dacă returnează ceva neașteptat, rezolvați asta mai întâi, pentru că fiecare pas următor presupune această bază.

Alegeți cine deține ruta prefixului îndepărtat

Opțiunea A este routerul ISP: ține o rută statică pentru 10.60.0.0/24 către gateway, iar fiecare host urmează gateway-ul implicit ca înainte. Opțiunea B este pe host: doar mașinile care au nevoie de site-ul îndepărtat primesc o rută explicită prin 10.50.0.2, iar restul rămâne neatins. A este mai curată la multe hosturi, dar de obicei cere ca routerul furnizorului să accepte o rută statică, ceea ce unii nu fac. B nu are nevoie de cooperarea furnizorului, dar lasă întreținerea configurației hosturilor în sarcina dumneavoastră, așa că se potrivește unui set mic de mașini aprobate.

În ambele cazuri direcția de întoarcere trebuie să existe. Dacă un răspuns îndepărtat ajunge la gateway și gateway-ul îl trimite direct la un host din LAN, traficul ocolește starea de firewall pe care routerul ISP o ținea pe calea de ieșire. Când gateway-ul nu este routerul implicit al LAN-ului, acea asimetrie este o decizie de proiectare, nu un defect de ignorat.

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

Faceți intrarea permanentă prin proprietarul configurației hostului, nu printr-un script de autentificare. O rută care există doar după ce cineva se autentifică va eșua prima dată când mașina repornește dintr-un motiv nelegat.

Asigurați un punct de intrare accesibil

Gateway-ul are nevoie de o adresă pe care site-ul îndepărtat o poate atinge. În spatele routerului ISP asta înseamnă redirecționare de port sau o intrare DMZ, iar ambele depind de furnizorul care livrează într-adevăr traficul. O redirecționare locală nu depășește NAT-ul de nivel de operator din partea furnizorului. Dacă furnizorul nu oferă un punct accesibil, inversați direcția: lăsați ambele site-uri să inițieze către un concentrator pe care îl controlați. Este o proiectare validă, dar adaugă o a treia dependență pentru redirecționare, încredere și disponibilitate, iar DNS-ul dinamic nu o înlocuiește.

Confirmați redirecționarea cu o captură pe gateway, nu cu un site care scanează porturi. Scanerele raportează portul închis până când ascultătorul este legat, iar o redirecționare care nu livrează niciodată trafic arată din exterior ca un port închis.

Acceptați serviciul privat și linia de voce împreună

Testați funcționarea dorită de pe un host din LAN, cu DNS privat și acreditările aplicației înseși. Un tunel rutat nu face navigarea îndepărtată să semene cu un segment Ethernet local, așa că descoperirea și rezolvarea numelor au nevoie de aranjamente proprii.

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

Apoi confirmați că accesul obișnuit la internet funcționează în continuare de pe același host și că telefoanele sunt încă înregistrate; aceste două verificări prind o schimbare accidentală a rutei implicite, cea mai frecventă cale prin care acest proiect strică ceva ce nu a vrut niciodată să atingă. Încheiați cu o notă scrisă de recuperare: ce echipament are ce rol, adresele rezervate și cum se elimină ruta prefixului îndepărtat într-un singur pas. O cale privată care poate fi retrasă curat valorează mai mult decât una care funcționează doar astăzi.

Articole similare