Geografia DNS kaj anycast: kontroli la VPN-eniron, kiun vi ricevas

Proksima DNS-respondo ŝajnas solvita problemo ĝis la konekto alteriĝas aliloke. Geografia DNS kaj anycast ambaŭ provas mallongigi la vojon, kaj ili faras tiun decidon el malsamaj informoj. Neniu el ili garantias, ke la enireja pordego, kiun vi atingas, estas atingebla, ke ĝi prezentas la identecon, kiun via kliento atendas, aŭ ke via seanco postvivas nodan ŝanĝon. La kontroloj sube apartigas tiujn kvar demandojn.

Kontrolu, kies lokon la solvilo fakte raportas

Aŭtoritata servilo, kiu respondas al topologiosentema demando, kutime vidas la adreson de la rekursiva solvilo, kiu demandis, ne la adreson de la persono, kiu tajpis la nomon. Centra solvilo povas troviĝi malproksime de la klientoj, kiujn ĝi servas, kaj la respondo spegulas la solvilon anstataŭ ilin. Tio ne estas difekto; tiel kondutas la protokolo, se oni ne aldonas pliajn informojn. Specifo de EDNS-klienta subreto priskribas kaj la limigon kaj la nedevigan rimedon.

EDNS-klienta subreto povas porti informojn pri la origina reto, kiam ĉiu partoprenanto subtenas kaj ŝaltas ĝin. Ĝi estas nedeviga, ĝi havas sekvojn por privateco kaj kaŝmemoro, kaj ĝi ne estas permeso supozi, ke iu ajn publika solvilo raportas precizan uzanton-lokon. Demandu la operatorojn de solviloj antaŭ ol konstrui sur ĝi.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Kontrolu, kion decidis anycast-enkursigado

Ĉe anycast, pluraj lokoj anoncas atingeblon por unu serva adreso, kaj la reto liveras ĉiun klienton al tiu nodo, kiun ĝia enkursigado preferas. Tiun elekton faras BGP kaj la ĉirkaŭa politiko, ne distanco sur mapo. Ankaŭ topologia proksimeco ĝenerale ne egalas pli bonan rondvojan rendimenton, ĉar la vojo, kiu aspektas mallonga, povas esti kongestita aŭ nesimetria. La adreso, kiun vi ricevis, diras nenion pri tio, kiu nodo respondis.

Konfirmu la servan lokon de la serva flanko, aŭ el respondo, kiu nomas ĝin, anstataŭ nur el la DNS-respondo. traceroute -n 198.51.100.20 montras la vojon, kiun vi iris, kaj ankoraŭ ne nomas la gastiganton ĉe ĝia fino, do legu ĝin kiel vojon, ne kiel respondon.

Kontrolu, ke la seanco postvivas nodan ŝanĝon

DNS-demando estas mallonga kaj VPN-seanco estas longa, kaj la du havas tute malsamajn postulojn pri stato. Enkursigado povas ŝoviĝi meze de seanco, kaj kiam tio okazas, postaj pakaĵoj povas alveni al nodo, kiu neniam vidis vian tunelon. Ĉu tio estas postvivebla dependas de la efektivigo: komuna stato, intenca rekonekto aŭ dokumentita fiasko. La adreso sola provizas neniun el tiuj.

Observu la ŝoviĝon anstataŭ supozi ĝin. sudo tcpdump -ni any -c 20 esp montras la eksterajn pakaĵojn dum la vojo ŝanĝiĝas, kaj subita ŝanĝo en la adreso de la samtavolano estas la ŝoviĝo mem. Difinu la celatan konduton eksplicite por la efektivigo, kiun vi funkciigas, poste testu ĝin devigante vojan ŝanĝon. Se la dezajno supozas seancan replikadon, nomu la mekanismon kaj nomu la fiaskon, kiun ĝi ne kovras.

Kontrolu, ke la identeco ankoraŭ kongruas

Ĉiu enirpunkto devas prezenti la identecon, kiun via klienta profilo atendas. Atestilo eldonita por la serva nomo funkcias trans nodoj, dum atestiloj po nodo devigas la klienton akcepti ion novan, kaj ĝuste tie uzantoj lernas klaki tra avertoj. Tenu la atendatan identecon kaj la profilon kongruaj kun la enira modelo.

Kontrolu ĝin de kliento, kiu atingis nekutiman nodon, ĉar tio estas la kazo, en kiu atestilo po nodo fariĝas videbla. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com presas la ĉenon kaj la nomojn, kio estas ĝuste tio, kion la kliento komparas. Poste decidu, ĉu la profilon oni mallarĝigu aŭ la atestilan modelon oni ŝanĝu.

Kontrolu la rikordon, ne nur la unuan respondon

Takstu tri scenarojn kaj skribu kvar faktojn por ĉiu: normala eniro, unu neatingebla loko kaj la interkonsentita reakira kazo. La kvar faktoj estas la uzita solvilo, la redonita adreso, la loko, kiu servis, kaj freŝa aplikrezulto. Tiu rikordo apartigas DNS-elektan problemon de pordega problemo, enkursiga problemo aŭ seanca-stata problemo. Sen ĝi, ĉiuj kvar aspektas identaj de la klienta flanko.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Rulu la scenarojn el reprezentaj alirretoj, ne nur el la oficejo, ĉar la tuta demando temas pri tio, kiun enirpunkton malsamaj klientoj fakte atingas. Unu reto estas specimeno de unu.