’n Gehoste bediener met ’n VPN op hou uiteindelik drie adresse vas, en net een daarvan hoort op elke plek wat jy gaan opstel. Om die nommer uit ’n verskaffer se paneel in DNS, in ’n luisteraar of in ’n toelatingslys te kopieer, is hoe ’n werkende tonnel ’n diens word wat niemand kan bereik nie. Hierdie draaiboek orden die werk sodat elke adres vir ’n genoemde doel gekies word. Dit lys ook die opdragte wat bevestig wat jy werklik gepubliseer het.

Karteer die drie adresse voordat jy iets publiseer

Noem hulle volgens funksie. Die onderlaag-adres is wat die masjien gebruik om die VPN-eindpunt oor die internet te bereik, en dit is dikwels privaat agter die verskaffer se NAT. Die tonneladres leef binne die VPN en word deur die bediener of die kliënt uitgedeel, afhangend van die produk. Die openbare uitgang is die adres wat ’n afgeleë webwerf ná die vertaling aanteken, en dit hoef op geen koppelvlak te bestaan wat jy kan navraag doen nie.

’n Paneel wat een openbare adres vir ’n masjien wys, vertel jou baie min oor die ander twee rolle. Onderlaag-bereikbaarheid is ’n vereiste, nie ’n aankoop nie: ’n skootrekenaar agter ’n tuisroeteerder kan ’n gehoste VPN-eindpunt bereik sonder om ’n openbare IPv4-adres te besit. Wat jy nie kan doen nie, is om ’n inkomende pad uit te dink deur ’n naam te skryf wat na ’n adres oplos wat niemand aanstuur nie.

Kies die adres volgens die diens, nie volgens die etiket nie

Skryf neer wat die bediener moet doen voordat jy ’n nommer kies. Uitgaande API-oproepe het ’n stabiele uitgang nodig wanneer die ander kant ’n toelatingslys hou. Privaat toegang het ’n tonneladres nodig waarheen kliënte kan roeteer en ’n luisteraar wat daaraan gebind is. Openbare gasheer het ’n inkomende kartering nodig wat die verskaffer werklik bied, en die uitgangsadres alleen lewer dit nie.

Een masjien kan al drie die doele dien en steeds drie verskillende adresse gebruik. Wat breek, is die aanname dat een waarde hulle almal dek:

RequirementValue that belongs thereWhat you see when the roles are swapped
Outbound allowlistingPublic exitRequests reach the service but are rejected
Private client accessTunnel addressClient connects, nothing answers
Inbound web serviceProvider mappingName resolves, connection times out

Die inkomende ry is die een waaroor mense stry. ’n Rekord wat na die uitgangsadres wys, skep geen luisteraar, geen firewall-opening en geen poortkartering nie, en wag verander dit nie. Wanneer die verskaffer ’n toegewyde adres saam met ’n inkomende reël verkoop, is daardie bondel die vermoë wat jy gekoop het; die adres op sigself is nie die aanspraak nie.

Opdragte wat wys watter adres watter is

Lees die masjien, nie die paneel nie. Koppelvlakname verskil tussen stelsels, so pas adresse by toestelle en vertrou nie ’n etiket nie.

Die eerste reël lys elke IPv4-adres en sy toestel, en die tweede vra die kernel watter toestel hy vir ’n bekende bestemming buite sou gebruik:

ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'

As die roetenavraag vir openbare verkeer met ’n tonneltoestel antwoord, is jou volle tonnel in werking. Die luisteraar-kontrole is net so belangrik, want ’n proses wat net aan 127.0.0.1 gebind is, sal nooit op die tonneladres antwoord nie, maak nie saak watter naam jy publiseer nie.

Publiseer dit, en verifieer dan van buite

Publiseer die waarde wat die diens nodig het en niks meer nie: ’n A- of AAAA-rekord vir gasheer, ’n toelatingslys-inskrywing vir uitgaande oproepe, ’n kliëntprofiel vir privaat toegang. Toets dan vanaf die posisie wat saak maak, en dit is nooit die masjien wat jy pas verander het nie.

Twee kontroles dek die meeste daarvan, en albei is goedkoop genoeg om in ’n skrip te hou:

dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/health

’n DNS-antwoord wat bewys dat jou rekord bestaan, is nie ’n bewys dat ’n versoek aankom nie, en een suksesvolle versoek bewys net dat een pad van een netwerk af werk. Herhaal die kontrole oor ’n mobiele verbinding wanneer ’n toelatingslys betrokke is, want die uitgang wat jy sien kan van die adresfamilie en die gevolgde roete afhang. Let op watter familie jy geverifieer het; ’n werkende IPv4-pad sê heeltemal niks oor IPv6 nie.

As die diens inkomend is, is die uitgangsadres nie genoeg nie

Inkomende toegang het vier dinge in ’n ry nodig: ’n naam of adres wat ’n kliënt kan bereik, ’n roete wat die pakket by die masjien aflewer, ’n luisteraar wat dit aanvaar en ’n beleid wat dit nie laat val nie. ’n VPN verander die tweede item en soms die eerste, en dit doen niks vir die derde en vierde nie. Wanneer die tonnel die afleweringspad is, koppel kliënte aan die tonneladres, nie aan die uitgang nie.

Teken aan van watter adres elke diens afhang, en hersien daardie aantekening wanneer die verskaffer sy roetemodel verander. ’n Bediener wat privaat antwoord en openbaar faal, is gewoonlik nie stukkend nie; dit antwoord onder die verkeerde identiteit, en die herstel is ’n karteringsbesluit eerder as ’n firewallverandering.

Verwante artikels