Lägg till en plats-VPN bredvid ISP-routern utan att bryta samtal

De flesta små anläggningar har redan en box som sköter internet, DHCP och röstlinjen, och den boxen kommer inte att köra anläggningens tunnel. Att lägga till en andra gateway för den privata vägen fungerar om du bestämmer vem som äger varje rutt innan du rör en kabel. Den verkliga risken är inte tunneln, utan att tyst byta ut enheten som håller telefonerna registrerade. Gör de fem kontrollerna i ordning och stanna där en av dem fallerar.

Skriv ned rollerna som redan fungerar

Anteckna standardgatewayen, DHCP-servern, resolvern och enheten som har leverantörens röstregistrering. I det här exemplet är ISP-routern 10.50.0.1, den nya gatewayen blir 10.50.0.2 och den avlägsna anläggningen är 10.60.0.0/24. Ingenting i den planen ändrar de tre första rollerna, och det är precis poängen. Bekräfta sedan att den andra boxen verkligen kan avsluta tunneln: titta på protokollet, förväntat genomflöde och om den får firmware- eller paketuppdateringar. En enhet med VPN-logga och utan uppdateringsväg är en belastning, inte ett tillskott.

Om du inte kan säga vem som äger rösttjänsten, stanna. Att byta routern som har en registrering utan en återställningsplan gör ett VPN-projekt till ett telefonavbrott.

Ge den nya gatewayen en adress och en uppgift

Reservera dess LAN-adress utanför DHCP-poolen så att den inte flyttar sig efter omstart, och ge den ingen egen standardrutt om du inte vill att den ska bli en internetväg. Uppgiften är att hålla tunneln och svara för avlägsna prefix. På de LAN-värdar som måste nå den avlägsna anläggningen bevisar du vilken väg de tar nu och vilken du vill ha efter ändringen; samma två kommandon före och efter är det billigaste beviset.

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

Om uppslaget ger ISP-routern och traceroute dör vid internetkanten har värden ännu ingen avlägsen väg, vilket är väntat. Kommer något oväntat tillbaka löser du det först, eftersom varje senare steg utgår från denna bas.

Välj vem som äger rutten till det avlägsna prefixet

Alternativ A är ISP-routern: den håller en statisk rutt för 10.60.0.0/24 mot gatewayen, och varje värd följer sin standardgateway som förut. Alternativ B är per värd: bara maskinerna som behöver den avlägsna anläggningen får en explicit rutt via 10.50.0.2, och allt annat lämnas orört. A är renare vid många värdar, men kräver vanligen att leverantörens router accepterar en statisk rutt, vilket en del inte gör. B kräver inget samarbete från leverantören men lämnar underhållet av värdkonfigurationen hos dig, så det passar en liten godkänd uppsättning maskiner.

I båda fallen måste returvägen finnas. Om ett fjärrsvar kommer till gatewayen och gatewayen vidarebefordrar det rakt till en LAN-värd, hoppar trafiken över det brandväggstillstånd som ISP-routern höll på väg ut. När gatewayen inte är LAN:ets standardrouter, är den asymmetrin ett designval, inte ett fel du kan ignorera.

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

Gör posten beständig via värdens konfigurationsägare, inte via ett inloggningsskript. En rutt som bara finns efter att någon loggat in kommer att fallera första gången maskinen startar om av en orelaterad anledning.

Ordna en nåbar inkommande ändpunkt

Gatewayen behöver en adress som den avlägsna anläggningen kan nå. Bakom ISP-routern betyder det portvidarebefordran eller en DMZ-post, och båda beror på att leverantören faktiskt levererar trafiken. En lokal vidarebefordran övervinner inte operatörsnivå-NAT på leverantörens sida. Om leverantören inte ger en nåbar punkt, vänd riktningen: låt båda anläggningarna initiera mot ett nav som du kontrollerar. Det är en giltig design, men den lägger till ett tredje beroende för vidarebefordran, tillit och tillgänglighet, och dynamisk DNS ersätter det inte.

Bekräfta vidarebefordran med en avlyssning på gatewayen, inte med en webbplats som skannar portar. Skannrar rapporterar porten stängd tills lyssnaren är bunden, och en vidarebefordran som aldrig levererar trafik ser utifrån ut som en stängd port.

Acceptera den privata tjänsten och röstlinjen tillsammans

Testa den avsedda driften från en LAN-värd, med privat DNS och applikationens egna inloggningsuppgifter. En routad tunnel får inte fjärrsurfande att se ut som ett lokalt Ethernet-segment, så upptäckt och namnmatchning behöver egna arrangemang.

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

Bekräfta sedan att vanlig internetåtkomst fortfarande fungerar från samma värd och att telefonerna fortfarande är registrerade; de två kontrollerna fångar en oavsiktlig ändring av standardrutten, det vanligaste sättet detta projekt förstör något det aldrig menade att röra. Avsluta med en skriftlig återställningsnotering: vilken enhet som har vilken roll, de reserverade adresserna och hur du tar bort rutten till det avlägsna prefixet i ett steg. En privat väg som kan dras tillbaka rent är värd mer än en som bara fungerar i dag.