VPN-eindpuntnaam teenoor privaat diensnaam: twee eienaars

Twee name kan dieselfde tak beskryf en heeltemal verskillende vrae beantwoord. vpn.branch.example sê vir ’n afgeleë eweknie waar om die VPN-eindpunt te vind, en dit moet opgelos word voordat enige tonnel bestaan. inventory.branch.example sê vir ’n gemagtigde gebruiker waar ’n privaat toepassing woon, en dit maak eers saak wanneer die tonnel op is. Om een van hulle te onderhou, doen niks vir die ander nie.

Benoem die twee rekords voordat jy enigeen ontfout

Skryf albei neer saam met hulle eienaars. Vir die eindpunt, teken aan wie die publieke adres opdateer en hoe die VPN-kliënt sy antwoord verfris. Vir die diens, teken aan wie die privaat adres besit, watter sone die rekord hou, en watter oplossers veronderstel is om daarvoor te antwoord.

Daardie kort lys voorkom die mees algemene verkeerde diagnose in hierdie gebied: om ’n werkende taktonnel te herbegin om ’n rekord te herstel wat heeltemal binne-in dit woon. Die tonnel is die vervoer vir die diensnaam; dit is nie die gesag daarvoor nie.

Wanneer ’n verandering voorgestel word, vra watter van die twee rekords dit raak. As niemand kan antwoord nie, is die verandering nie gereed om te beplan nie.

Die eindpunt moet opgelos word voordat enige tonnel bestaan

Veronderstel die tak se internetverbinding kry ’n nuwe publieke adres. Die eindpunt-opdatering publiseer die nuwe adres, en die afgeleë VPN-implementering moet die veranderde antwoord kan lees. Watter opgelosser ook al daardie antwoord verskaf, moet sonder die tonnel bereikbaar wees, anders jaag die kliënt ’n naam wat hy eers kan oplos nadat hy aan die ding verbind het wat hy nie kan vind nie.

Daardie selflaai-afhanklikheid is die moeite werd om duidelik te stel, want dit is maklik om per ongeluk te skep wanneer alle interne oplossers agter die VPN sit. Hou ’n voor-tonnel-pad vir die eindpunt-soektog, en bevestig die kliënt se herverbindingsgedrag eerder as om te aanvaar dat ’n nuwe antwoord onmiddellik opgetel word.

Dinamiese DNS het ook grense wat die rekordopdatering nie kan oorskry nie. Om ’n rekord op te dateer maak geen firewall-poort oop nie, skep geen NAT-kaarte nie en bewys geen eweknie-identiteit nie. ’n Gepubliseerde adres met ’n geslote poort lewer ’n kliënt wat korrek oplos en steeds nie aan enigiets kan verbind nie.

Laastens, ’n lopende kliënt kan ’n gekaste eindpunt bly gebruik totdat dit herverbind. Skei die publikasie, die kas en die herverbindingsbeleid in jou notas, sodat ’n verouderde eweknie nie vir ’n stukkende opdatering aangesien word nie.

Die diensnaam beskryf waar die toepassing woon

Veronderstel nou die tonnel bly gesond maar die inventarisserver skuif van 172.26.14.20 na 172.26.14.35. Die publieke eindpuntrekord word nie geraak nie, terwyl die privaat diensrekord moet verander. Om ’n adres te gebruik wat vir daardie diens gereserveer is, of ’n statiese toewysing, maak dit skaarser; ’n gemagtigde opdateringspad hanteer die kere wanneer dit bedoel is.

Twee opdateringsmeganismes word hier verwar. RFC 2136 definieer ’n protokol om DNS-rekords in ’n sone by te voeg en te verwyder, terwyl ’n kommersiële dinamiese DNS-verskaffer ’n heeltemal ander HTTP-API vir ’n ander doel kan blootstel. Om een te gebruik impliseer nie dat die ander in jou omgewing bestaan nie. Kontroleer watter meganisme jou sone werklik aanvaar voordat jy ’n opdatering daarvoor skryf.

’n Korrekte privaat antwoord is net die eerste voorwaarde. Vir ’n afgeleë oproeper om dit te gebruik, het die kliënt ’n opgelosser nodig wat die privaat sone dra, ’n beleid wat navrae na daardie opgelosser toelaat, en deurstuur vir die adres wat terugkom. ’n Naam wat na ’n adres oplos wat die kliënt nie kan bereik nie, produseer ’n tydsverloop wat soos ’n bedienerfout lyk.

Toets die twee paaie afsonderlik

Kontroleer die eindpunt van buite die tonnel en die diens van binne dit, en hou die resultate as twee onafhanklike feite:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

As die eerste navraag misluk, is die probleem publieke publikasie of die voor-tonnel-opsporingspad, en geen interne verandering sal help nie. As die tweede ’n adres teruggee maar die derde geen roete deur die tonnel wys nie, is die DNS-laag reg en die deurstuurbeleid nie.

Voer die paar ná elke adresverandering uit, en let op watter rekord geskuif het. ’n Oordrag wat net sê “DNS is opgedateer” laat die volgende ingenieur raai watter van die twee lewensiklusse werklik geloop het.