De tunnel is oan, wêrom mislearret de priveenamme dan noch?

Alles oan 'e ferbining liket goed: de tunnel is oan en de console toant it privee einpunt, mar elk fersyk mislearret by namme-oplossing. De natuerlike beweging is de tunnel de skuld te jaan, dy't meastentiids ûnskuldig blykt. De fraach wurdt stjoerd nei in tsjinner dy't neat fan 'e privee sône wit. Gjin rûteferoaring sil dat antwurd feroarje, want it probleem is wa't frege is.

Hokker oplosser hat de fraach berikt?

Fyn de oplosser dy't oan elke keppeling ferbûn is foardat jo hielendal nei de tunnel sjogge. Linux toant tsjinners per keppeling fia it oarder fan oplosserstatus, en macOS toant oplossers mei berik yn syn DNS-konfiguraasje-útfier. As it antwurd noch fan 'e hûsrûter komt, is de tunnelkeppeling nea rieplachte.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Hjir wurde twa fazen trochinoar helle: in tsjinner dy't in oplosseradres triuwt, en in klient dy't it op 'e aktive keppeling ynstallearret. In profyl kin de opsje befetsje, en in log kin sjen litte dat it oankomt, wylst it bestjoeringssysteem de âlde tsjinner bliuwt brûken. Fergelykje it log mei wat de keppeling rapportearret, en fertrou de keppeling.

Brûk in adres dêr't it wolkennetwurk echt op antwurdet

Wolkennetwurken beantwurdzje priveenammen meastentiids fia in reservearre adres twa posysjes fan 'e basis fan it berik, dus in netwurk dat by 10.0.0.0 begjint, antwurdet op 10.0.0.2. Guon providers publisearje ek in link-lokaal oplosser dy't wurket sûnder it berik te kennen, wat helpt as it netwurk troch immen oars boud is. Freegje it kandidaatadres direkt foardat jo it nei immen triuwe. In adres dat gjin oplosser is, liket krekt op in firewall-drop, want de fraach kriget gewoan nea antwurd.

As de direkte fraach fan binnen it netwurk antwurdet mar net oer de tunnel, is de oplosser goed en it paad tusken de twa punten net. Dat resultaat ferpleatst it ûndersyk nei rûtes, trochstjoeren en tagongsregels ynstee fan it klantprofyl.

In tunnel draacht de nammeromte net

Pakketten stekke oer; nammen net. Elke kant moat ferteld wurde hokker nammeromte by de oare heart, en dat is in apart objekt dat eigendom is fan wa't de sône hat. De gewoane foarm is in trochstjoering foar ien nammeromte, rjochte op in oplosser dy't oer de tunnel berikber is.

Yn 'e praktyk hat elke rjochting syn eigen regel nedich, want de kant dy't de sône hat, moat de fraach trochstjoere. Beide rjochtingen ferlangje dat de boarne fan 'e fraach rûte en tastien is, en de antwurdzjende kant moat antwurden troch de tunnel weromstjoere ynstee fan nei it ynternet. Hâld de trochstjoering smel, sadat allinne de privee nammeromte fan 'e keppeling ôfhinklik is. Elke fraach der troch stjoere makket fan in lytse ôfhinklikens in folsleine útfal op it momint dat de tunnel falt.

Gean de grinzen yn oarder by lâns

Test de oplosser dy't op 'e aktive keppeling ynstallearre is, dan in direkte fraach oan dy oplosser, dan deselde fraach fan 'e fiere kant, en úteinlik de applikaasje dy't deselde namme brûkt. Elke stap isolearret ien grins, dus in mislearring fertelt wêr't jo sjogge moatte ynstee fan it ûndersyk opnij te begjinnen. In antwurd dat wurket wylst de applikaasje mislearret, wiist op sertifikaatfertrouwen of in API-belied ynstee fan DNS. Dy fouten binne echt, en gjin feroaring fan oplosser sil se reparearje.

Skriuw op hokker stap mislearre. Dy iene rigel is wat de folgjende persoan nedich hat, en it duorret tsien sekonden om it fêst te lizzen.

Hâld de ketting dêr't de folgjende persoan it fine kin

Registrearje de triuwde oplosser, de trochstjoerregel, de tastiene fraachboarne en it antwurdzjende einpunt op ien plak. As de priveenamme wer mislearret, lit it record sjen oft de tunnel ferhuze, it oplosseradres feroare of in regel ferneaud is. Sûnder dat begjint elk ynsidint by nul en einiget mei deselde trije gissingen.

Hâld it record koart genôch om krekt te bliuwen: fjouwer rigels, in datum en de namme fan wa't elk diel hat. In ferâldere record is slimmer as gjin, want it liket gesachhawwend wylst it ferkeard is.