Nama titik akhir VPN berbanding nama perkhidmatan peribadi: dua pemilik

Dua nama boleh menerangkan cawangan yang sama dan menjawab soalan yang sama sekali berbeza. vpn.branch.example memberitahu rakan jauh di mana hendak mencari titik akhir VPN, dan ia mesti diselesaikan sebelum sebarang terowong wujud. inventory.branch.example memberitahu pengguna yang diberi kuasa di mana aplikasi peribadi berada, dan ia hanya penting selepas terowong naik. Menyelenggara salah satunya tidak melakukan apa-apa untuk yang lain.

Namakan kedua-dua rekod sebelum menyahpepijat mana-mana satu

Tulis kedua-duanya bersama pemiliknya. Untuk titik akhir, catat siapa mengemas kini alamat awam dan bagaimana klien VPN menyegarkan jawapannya. Untuk perkhidmatan, catat siapa memiliki alamat peribadi, zon mana menyimpan rekod itu dan penyelesai mana yang sepatutnya menjawabnya.

Senarai pendek itu menghalang salah diagnosis paling biasa dalam bidang ini: memulakan semula terowong cawangan yang berfungsi untuk membaiki rekod yang hidup sepenuhnya di dalamnya. Terowong ialah pengangkutan untuk nama perkhidmatan; ia bukan autoritinya.

Apabila perubahan dicadangkan, tanya rekod mana antara dua itu yang disentuhnya. Jika tiada siapa boleh menjawab, perubahan itu belum sedia untuk dijadualkan.

Titik akhir mesti diselesaikan sebelum sebarang terowong wujud

Katakan sambungan internet cawangan menerima alamat awam baharu. Pengemas kini titik akhir menerbitkan alamat baharu, dan pelaksanaan VPN jauh mesti dapat membaca jawapan yang berubah. Penyelesai mana pun yang memberikan jawapan itu mesti boleh dicapai tanpa terowong, jika tidak klien mengejar nama yang hanya boleh diselesaikannya selepas bersambung kepada perkara yang tidak dapat ditemuinya.

Kebergantungan butstrap itu wajar dinyatakan dengan jelas, kerana ia mudah tercipta secara tidak sengaja apabila semua penyelesai dalaman berada di belakang VPN. Kekalkan laluan pra-terowong untuk carian titik akhir, dan sahkan tingkah laku sambungan semula klien dan bukannya menganggap jawapan baharu diambil serta-merta.

DNS dinamik juga mempunyai had yang tidak boleh dilangkaui oleh kemas kini rekod. Mengemas kini rekod tidak membuka port tembok api, tidak mencipta pemetaan NAT dan tidak membuktikan identiti rakan. Alamat yang diterbitkan dengan port tertutup menghasilkan klien yang menyelesaikan dengan betul dan masih tidak boleh bersambung kepada apa-apa.

Akhir sekali, klien yang berjalan mungkin terus menggunakan titik akhir yang dicache sehingga ia bersambung semula. Asingkan penerbitan, cache dan dasar sambungan semula dalam nota anda, supaya rakan yang lapuk tidak disalah anggap sebagai pengemas kini yang rosak.

Nama perkhidmatan menerangkan di mana aplikasi berada

Sekarang katakan terowong kekal sihat tetapi pelayan inventori berpindah dari 172.26.14.20 ke 172.26.14.35. Rekod titik akhir awam tidak terjejas, manakala rekod perkhidmatan peribadi mesti berubah. Menggunakan alamat yang dikhaskan untuk perkhidmatan itu, atau peruntukan statik, menjadikan ini lebih jarang; laluan kemas kini yang diberi kuasa mengendalikan masa ia memang disengajakan.

Dua mekanisme kemas kini dicampurkan di sini. RFC 2136 mentakrifkan protokol untuk menambah dan memadam rekod DNS dalam zon, manakala pembekal DNS dinamik komersial mungkin mendedahkan API HTTP yang sama sekali berbeza untuk tujuan lain. Menggunakan satu tidak bermakna yang lain wujud dalam persekitaran anda. Semak mekanisme mana yang benar-benar diterima zon anda sebelum menulis pengemas kini terhadapnya.

Jawapan peribadi yang betul hanyalah syarat pertama. Untuk pemanggil jauh menggunakannya, klien memerlukan penyelesai yang membawa zon peribadi, dasar yang membenarkan pertanyaan kepada penyelesai itu, dan pemajuan untuk alamat yang kembali. Nama yang diselesaikan kepada alamat yang tidak dapat dicapai oleh klien menghasilkan tamat masa yang kelihatan seperti kerosakan pelayan.

Uji kedua-dua laluan secara berasingan

Semak titik akhir dari luar terowong dan perkhidmatan dari dalamnya, dan simpan hasilnya sebagai dua fakta bebas:

$ 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

Jika pertanyaan pertama gagal, masalahnya ialah penerbitan awam atau laluan penyelesaian pra-terowong, dan tiada perubahan dalaman akan membantu. Jika yang kedua memulangkan alamat tetapi yang ketiga tidak menunjukkan laluan melalui terowong, lapisan DNS baik dan dasar pemajuan tidak.

Jalankan pasangan itu selepas setiap perubahan alamat, dan catat rekod mana yang bergerak. Serah terima yang hanya berkata «DNS telah dikemas kini» membiarkan jurutera seterusnya meneka kitaran hayat mana antara dua itu yang benar-benar berjalan.