Legg til ein nettstads-VPN ved sida av ISP-rutaren utan å bryte samtalar

Dei fleste små nettstadar har allereie éin boks som gjer internett, DHCP og talelinja, og den boksen kjem ikkje til å køyre tunnelen til nettstaden. Å leggje til ein ekstra gateway for den private vegen fungerer dersom du avgjer kven som eig kvar rute før du rører ein kabel. Den eigentlege risikoen er ikkje tunnelen, men å byte ut eininga som held telefonane registrerte, i det stille. Gjer dei fem kontrollane i rekkjefølgje, og stopp der ein av dei feilar.

Skriv ned rollene som allereie verkar

Noter standardgatewayen, DHCP-tenaren, resolvaren og eininga som har taleregistreringa til leverandøren. I dette dømet er ISP-rutaren 10.50.0.1, den nye gatewayen blir 10.50.0.2, og den fjernade nettstaden er 10.60.0.0/24. Ingenting i den planen endrar dei tre første rollene, og det er nettopp poenget. Stadfest deretter at den andre boksen faktisk kan avslutte tunnelen: sjå på protokollen, forventa gjennomstrøyming og om han får fastvare- eller pakkeoppdateringar. Ei eining med VPN-logo og utan oppdateringsveg er ei belastning, ikkje eit tillegg.

Viss du ikkje kan seie kven som eig taletenesta, stopp. Å byte rutaren som har ei registrering utan ein tilbakerullingsplan gjer eit VPN-prosjekt til eit telefonsvikt.

Gje den nye gatewayen éi adresse og éi oppgåve

Reserver LAN-adressa utanfor DHCP-bassenget slik at ho ikkje flyttar seg etter omstart, og gje henne inga eiga standardrute med mindre du vil at ho skal bli ein internettveg. Oppgåva er å halde tunnelen og svare for fjerne prefiks. På LAN-vertane som må nå den fjernade nettstaden, prov kva veg dei brukar no og kva veg du vil ha etter endringa; dei same to kommandoane før og etter er det billegaste provet.

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

Viss oppslaget returnerer ISP-rutaren og traceroute døyr ved internettkanten, har verten enno ingen fjernveg, noko som er forventa. Viss det returnerer noko uventa, løys det først, fordi kvart seinare steg føreset dette grunnlaget.

Vel kven som eig ruta til fjernprefikset

Alternativ A er ISP-rutaren: han held ei statisk rute for 10.60.0.0/24 mot gatewayen, og kvar vert følgjer standardgatewayen som før. Alternativ B er per vert: berre maskinene som treng den fjernade nettstaden får ei eksplisitt rute gjennom 10.50.0.2, og alt anna blir urørt. A er reinare ved mange vertar, men krev vanlegvis at rutaren til leverandøren godtek ei statisk rute, noko ikkje alle gjer. B krev ingen samarbeid frå leverandøren, men lèt deg vedlikehalde vertskonfigurasjonen, så det passar for eit lite godkjent sett med maskiner.

I begge tilfelle må returretninga finnast. Viss eit fjernsvar kjem til gatewayen og gatewayen vidaresender det rett til ein LAN-vert, hoppar trafikken over brannmurtilstanden som ISP-rutaren heldt på veg ut. Når gatewayen ikkje er standardrutaren til LAN-et, er den asymmetrien eit designval, ikkje ein 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

Gjer oppføringa varig via konfigurasjonseigaren til verten, ikkje via eit innloggingsskript. Ei rute som berre finst etter at nokon loggar inn, vil feile første gong maskinen startar på nytt av ein urelatert grunn.

Sørg for eit tilgjengeleg innkomande endepunkt

Gatewayen treng ei adresse som den fjernade nettstaden kan nå. Bak ISP-rutaren betyr det portvideresending eller ei DMZ-oppføring, og begge er avhengige av at leverandøren faktisk leverer trafikken. Lokal vidaresending overvinn ikkje operatørnivå-NAT på leverandøren si side. Viss leverandøren ikkje gir eit tilgjengeleg punkt, snu retninga: la begge nettstadane ta initiativ mot ein hub du kontrollerer. Det er eit gyldig design, men det legg til ein tredje avhengnad for vidaresending, tillit og tilgjenge, og dynamisk DNS erstattar det ikkje.

Stadfest vidaresendinga med eit opptak på gatewayen, ikkje med ein nettstad som skannar portar. Skannarar melder porten lukka til lyttaren er bunden, og ei vidaresending som aldri leverer trafikk ser utanfrå lik ut som ein lukka port.

Godta den private tenesta og talelinja saman

Test den tiltenkte drifta frå ein LAN-vert, med privat DNS og applikasjonen sine eigne påloggingsdata. Ein ruta tunnel får ikkje fjernlesing til å sjå ut som eit lokalt Ethernet-segment, så oppdaging og namneoppslag treng eigne ordningar.

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

Stadfest deretter at vanleg internettilgang framleis verkar frå same vert, og at telefonane framleis er registrerte; dei to kontrollane fangar ei utilsikta endring av standardruta, den vanlegaste måten dette prosjektet øydelegg noko det aldri meinte å røre. Avslutt med eit skriftleg gjenopprettingsnotat: kva eining som har kva rolle, dei reserverte adressene, og korleis du fjernar ruta til fjernprefikset i eitt steg. Ein privat veg som kan trekkjast tilbake reint er meir verdt enn ein som berre verkar i dag.