Tilføj en site-VPN ved siden af ISP-routeren uden at afbryde opkald

De fleste små lokaliteter har allerede en boks, der klarer internet, DHCP og telefonlinjen, og den boks kommer ikke til at køre jeres site-tunnel. At tilføje en ekstra gateway til den private vej virker, hvis I beslutter, hvem der ejer hver rute, før I rører en kabel. Den egentlige risiko er ikke tunnelen; det er lydløst at udskifte den enhed, der holder telefonerne registreret. Tag de fem kontroller i rækkefølge, og stop hvor en af dem fejler.

Skriv rollerne ned, som allerede virker

Noter standardgatewayen, DHCP-serveren, resolveren og den enhed, der har udbyderens taleregistrering. Her er ISP-routeren 10.50.0.1, den nye gateway kommer på 10.50.0.2, og det fjernede site er 10.60.0.0/24. Intet i den plan ændrer de tre første roller, og det er netop pointen. Bekræft derefter, at den anden boks faktisk kan afslutte jeres tunnel: se på protokollen, den forventede gennemstrømning, og om den får firmware- eller pakkeopdateringer. En enhed med VPN-logo og uden opdateringsvej er en byrde, ikke en tilføjelse.

Hvis I ikke kan sige, hvem der ejer taletjenesten, så stop. At skifte den router, der har en registrering, uden en tilbagerulningsplan gør et VPN-projekt til et telefonnedbrud.

Giv den nye gateway én adresse og én opgave

Reservér dens LAN-adresse uden for DHCP-puljen, så den ikke flytter sig efter en genstart, og giv den ingen egen standardrute, medmindre I vil have den til at blive en internetvej. Dens opgave er at holde tunnelen og svare for fjernpræfikser. På de LAN-værter, der skal nå det fjernede site, skal I bevise, hvilken vej de tager nu, og hvilken I vil have efter ændringen; de samme to kommandoer før og efter er det billigste bevis.

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

Hvis opslaget returnerer ISP-routeren, og traceroute dør ved internetkanten, har værten endnu ingen fjernvej, hvilket er forventet. Returnerer det noget uventet, så løs det først, fordi hvert senere trin forudsætter denne baseline.

Vælg, hvem der ejer ruten til fjernpræfikset

Mulighed A er ISP-routeren: den holder en statisk rute for 10.60.0.0/24 mod gatewayen, og hver vært følger sin standardgateway som før. Mulighed B er pr. vært: kun maskinerne, der har brug for det fjernede site, får en eksplicit rute gennem 10.50.0.2, og alt andet forbliver urørt. A er renere ved mange værter, men kræver normalt, at udbyderens router accepterer en statisk rute, hvilket nogle ikke gør. B kræver ingen samarbejde fra udbyderen, men efterlader vedligeholdelsen af værtskonfigurationen hos jer, så den passer til et lille godkendt sæt maskiner.

I begge tilfælde skal returvejen findes. Hvis et fjernsvar kommer til gatewayen, og gatewayen videresender det direkte til en LAN-vært, springer trafikken den firewalltilstand over, som ISP-routeren holdt på vejen ud. Når gatewayen ikke er LANets standardrouter, er den asymmetri et designvalg, ikke en fejl, I 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

Gør posten permanent via værtenes konfigurationsejer, ikke via et login-script. En rute, der kun findes, efter nogen logger ind, fejler første gang maskinen genstarter af en uvedkommende grund.

Sørg for et tilgængeligt indgående endepunkt

Gatewayen har brug for en adresse, som det fjernede site kan nå. Bag ISP-routeren betyder det en portvideresendelse eller en DMZ-post, og begge afhænger af, at udbyderen faktisk leverer trafikken. En lokal videresendelse kan ikke overvinde carrier-grade NAT hos udbyderen. Hvis udbyderen ikke vil give et tilgængeligt endepunkt, vend retningen: lad begge sites tage initiativ mod et hub, I kontrollerer. Det er et gyldigt design, men det tilføjer en tredje afhængighed for videresendelse, tillid og tilgængelighed, og dynamisk DNS erstatter det ikke.

Bekræft videresendelsen med en optagelse på gatewayen, ikke med et websted, der scanner porte. Scannere melder porten lukket, indtil lytteren er bundet, og en videresendelse, der aldrig leverer trafik, ser udefra ud som en lukket port.

Accepter den private tjeneste og telefonlinjen sammen

Test den tilsigtede drift fra en LAN-vært, med privat DNS og applikationens egne legitimationsoplysninger. En routet tunnel får ikke fjernbrowsing til at ligne et lokalt Ethernet-segment, så opdagelse og navneopløsning kræver deres egne aftaler.

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

Bekræft derefter, at almindelig internetadgang stadig virker fra samme vært, og at telefonerne stadig er registreret; de to kontroller fanger en utilsigtet ændring af standardruten, den mest almindelige måde, dette projekt ødelægger noget, det aldrig ville røre. Afslut med et skriftligt gendannelsesnotat: hvilken enhed der ejer hvilken rolle, de reserverede adresser, og hvordan I fjerner ruten til fjernpræfikset i ét trin. En privat vej, der kan trækkes rent tilbage, er mere værd end en, der bare virker i dag.