Sett opp en nettsteds-VPN ved siden av ISP-ruteren uten å bryte samtaler

Små nettsteder har som regel allerede en boks som tar seg av internett, DHCP og talelinjen, og den boksen kommer ikke til å kjøre nettstedets tunnel. Å sette inn en ekstra gateway for den private veien går bra dersom du bestemmer hvem som eier hver rute før du tar i en kabel. Risikoen er ikke tunnelen, men å skifte ut enheten som holder telefonnene registrert, uten at noen merker det. Utfør de fem kontrollene i rekkefølge, og stopp der en av dem slår feil.

Skriv opp rollene som allerede fungerer

Noter standard gateway, DHCP-tjener, navneoppslag og enheten som sitter på leverandørens taleregistrering. Her er ISP-ruteren 10.50.0.1, den nye gatewayen blir 10.50.0.2, og det fjerne nettstedet er 10.60.0.0/24. Ingen av delene endrer de tre første rollene, og nettopp det er poenget. Deretter bekrefter du at den andre boksen virkelig kan avslutte tunnelen: se på protokoll, forventet gjennomstrømning og om den mottar fastvare- eller pakkeoppdateringer. En enhet med VPN-merke og uten oppdateringsvei er en byrde, ikke et tilskudd.

Kan du ikke si hvem som eier taletjenesten, stopper du. Å bytte ruteren som har en registrering, uten en plan for tilbakeføring, gjør et VPN-prosjekt om til telefonsvikt.

Gi den nye gatewayen én adresse og én oppgave

Reserver LAN-adressen utenfor DHCP-området slik at den ikke flytter på 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 skal nå det fjerne nettstedet, viser du 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

Dersom oppslaget gir ISP-ruteren og traceroute dør ved internettkanten, har verten ennå ingen fjernvei, og det er ventet. Kommer det noe uventet tilbake, løser du det først, fordi hvert senere steg bygger på dette grunnlaget.

Velg hvem som eier ruten til det fjerne prefikset

Alternativ A er ISP-ruteren: den holder en statisk rute for 10.60.0.0/24 mot gatewayen, og hver vert følger standard gateway som før. Alternativ B er per vert: bare maskinene som trenger det fjerne nettstedet får en eksplisitt rute via 10.50.0.2, og alt annet står 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 medvirkning fra leverandøren, men lar deg vedlikeholde vertsoppsettet, så det passer for et lite godkjent sett maskiner.

I begge tilfeller må returveien finnes. Kommer et fjernsvar til gatewayen og gatewayen sender det rett videre til en LAN-vert, hopper trafikken over brannmurstanden 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 se bort fra.

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 gjennom vertens oppsettseier, ikke gjennom 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 fjerne nettstedet kan nå. Bak ISP-ruteren betyr det portvideresending eller en DMZ-oppføring, og begge avhenger av at leverandøren faktisk leverer trafikken. Lokal videresending overvinner ikke operatørnivå-NAT hos leverandøren. Gir leverandøren ikke et tilgjengelig punkt, snur du retningen: la begge nettstedene ta initiativ mot en hub du kontrollerer. Det er en gyldig løsning, 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 helt til lyttingen er bundet, og en videresending som aldri leverer trafikk ser lik ut som en lukket port fra utsiden.

Godta den private tjenesten og talelinjen sammen

Test den tiltenkte driften fra en LAN-vert, med privat DNS og applikasjonens egne innloggingsdata. En rutet tunnel får ikke fjernlesing til å se ut som et lokalt Ethernet-segment, så oppdaging 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 så at vanlig internettilgang fortsatt virker fra samme vert, og at telefonnene fortsatt er registrert; de to kontrollene fanger en utilsiktet endring av standardruten, den vanligste måten dette prosjektet ødelegger noe det aldri ville røre. Avslutt med et skriftlig gjenopprettingsnotat: hvilken enhet som har hvilken rolle, de reserverte adressene, og hvordan du fjerner ruten til det fjerne prefikset i ett trinn. En privat vei som kan trekkes tilbake rent, er mer verdt enn en som bare virker i dag.