Legg til en nettsteds-VPN ved siden av ISP-ruteren uten å bryte samtaler

De fleste små nettsteder har allerede én boks som gjør internett, DHCP og talelinjen, og den boksen kommer ikke til å kjøre nettstedets tunnel. Å legge til en ekstra gateway for den private veien fungerer hvis du bestemmer hvem som eier hver rute før du berører en kabel. Den egentlige risikoen er ikke tunnelen, men å bytte ut enheten som holder telefonene registrert, i det stille. Gjør de fem kontrollene i rekkefølge, og stopp der en av dem feiler.

Skriv ned rollene som allerede virker

Noter standardgatewayen, DHCP-serveren, resolveren og enheten som har leverandørens taleregistrering. I dette eksempelet er ISP-ruteren 10.50.0.1, den nye gatewayen blir 10.50.0.2, og det fjernede nettstedet er 10.60.0.0/24. Ingenting i den planen endrer de tre første rollene, og det er nettopp poenget. Bekreft deretter at den andre boksen faktisk kan avslutte tunnelen: se på protokollen, forventet gjennomstrømning og om den får fastvare- eller pakkeoppdateringer. En enhet med VPN-logo og uten oppdateringsvei er en belastning, ikke et tillegg.

Hvis du ikke kan si hvem som eier taletjenesten, stopp. Å bytte ruteren som har en registrering uten en tilbakerullingsplan gjør et VPN-prosjekt til et telefonsvikt.

Gi den nye gatewayen én adresse og én oppgave

Reserver LAN-adressen utenfor DHCP-poolen slik at den ikke flytter seg etter omstart, og gi den ingen egen standardrute med mindre du vil at den skal bli en internettvei. Oppgaven er å holde tunnelen og svare for fjerne prefikser. På LAN-vertene som må nå det fjernede nettstedet, bevis hvilken vei de bruker nå og hvilken du vil ha etter endringen; de samme to kommandoene før og etter er det billigste beviset.

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

Hvis oppslaget returnerer ISP-ruteren og traceroute dør ved internettkanten, har verten ennå ingen fjernvei, noe som er forventet. Hvis det returnerer noe uventet, løs det først, fordi hvert senere trinn forutsetter dette grunnlaget.

Velg hvem som eier ruten til fjernprefikset

Alternativ A er ISP-ruteren: den holder en statisk rute for 10.60.0.0/24 mot gatewayen, og hver vert følger standardgatewayen som før. Alternativ B er per vert: bare maskinene som trenger det fjernede nettstedet får en eksplisitt rute gjennom 10.50.0.2, og alt annet forblir urørt. A er renere ved mange verter, men krever vanligvis at leverandørens ruter godtar en statisk rute, noe ikke alle gjør. B krever ingen samarbeid fra leverandøren, men lar deg vedlikeholde vertskonfigurasjonen, så det passer for et lite godkjent sett med maskiner.

I begge tilfeller må returretningen finnes. Hvis et fjernsvar kommer til gatewayen og gatewayen videresender det rett til en LAN-vert, hopper trafikken over brannmurtilstanden som ISP-ruteren holdt på vei ut. Når gatewayen ikke er LAN-ets standardruter, er den asymmetrien et designvalg, ikke en feil du kan ignorere.

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

Gjør oppføringen varig via vertens konfigurasjonseier, ikke via et innloggingsskript. En rute som bare finnes etter at noen logger inn, vil feile første gang maskinen starter på nytt av en urelatert grunn.

Sørg for et tilgjengelig innkommende endepunkt

Gatewayen trenger en adresse som det fjernede nettstedet kan nå. Bak ISP-ruteren betyr det portvideresending eller en DMZ-oppføring, og begge avhenger av at leverandøren faktisk leverer trafikken. En lokal videresending overvinner ikke operatørnivå-NAT på leverandørens side. Hvis leverandøren ikke gir et tilgjengelig punkt, snu retningen: la begge nettstedene ta initiativ mot en hub du kontrollerer. Det er en gyldig design, men den legger til en tredje avhengighet for videresending, tillit og tilgjengelighet, og dynamisk DNS erstatter det ikke.

Bekreft videresendingen med en opptak på gatewayen, ikke med et nettsted som skanner porter. Skannere melder porten lukket til lytteren er bundet, og en videresending som aldri leverer trafikk ser utenfra ut som en lukket port.

Godta den private tjenesten og talelinjen sammen

Test den tiltenkte driften fra en LAN-vert, med privat DNS og applikasjonens egne påloggingsdata. En rutet tunnel får ikke fjernbrowsing til å se ut som et lokalt Ethernet-segment, så oppdagelse og navneoppslag trenger egne ordninger.

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

Bekreft deretter at vanlig internettilgang fortsatt virker fra samme vert, og at telefonene fortsatt er registrert; de to kontrollene fanger en utilsiktet endring av standardruten, den vanligste måten dette prosjektet ødelegger noe det aldri mente å røre. Avslutt med et skriftlig gjenopprettingsnotat: hvilken enhet som har hvilken rolle, de reserverte adressene, og hvordan du fjerner ruten til fjernprefikset i ett trinn. En privat vei som kan trekkes tilbake rent er mer verdt enn en som bare virker i dag.