ການເຊື່ອມຕໍ່ ແລະ DNS
ທົດສອບການຮົ່ວໄຫຼ WebRTC
ກວດສອບທີ່ຢູ່ທີ່ຟັງຊັນໂທຂອງບຣາວເຊີກວດພົບ ແລະຮຽນຮູ້ວິທີອ່ານຜົນທັງເມື່ອໃຊ້ ແລະບໍ່ໃຊ້ VPN.
ການຕັ້ງຄ່າການທົດສອບ
ການຕັ້ງຄ່າ TURN ທາງເລືອກ
TURN relay ສາມາດສະແດງວ່າບຣາວເຊີໃຊ້ຕົວເລືອກປະເພດນີ້ໄດ້ relay. ຂໍ້ມູນຮັບຮອງທີ່ປ້ອນໃຊ້ຢືນຢັນຕົວຕົນກັບ TURN; ເຄື່ອງມືນີ້ບໍ່ບັນທຶກ ຫຼື ສົ່ງໄປຫາເຊີບເວີເຮົາ.
ຄວາມເປັນສ່ວນຕົວ: ບໍລິການ STUN/TURN ແລະ echo ຈະເຫັນທີ່ຢູ່ຕົ້ນທາງທີ່ໃຊ້ຕິດຕໍ່ຢ່າງແນ່ນອນ. ຕົວເລືອກແລະລາຍງານຢູ່ໃນຄວາມຈຳຂອງແຖບນີ້ ເວັ້ນແຕ່ຈະສົ່ງອອກ.
ພ້ອມ. ການທົດສອບບໍ່ເຂົ້າເຖິງກ້ອງ ຫຼື ໄມໂຄຣໂຟນ.
ຜົນການກວດພົບ
ທີ່ຢູ່ທາງອອກທີ່ບຣາວເຊີເຫັນ
| ທົດສອບ | ປະເພດ | ທີ່ຢູ່ | ສະຖານະ | ໄລຍະເວລາ |
|---|
ຕົວເລືອກ WebRTC ICE
| ໄລຍະ | ປະເພດ | ທີ່ຢູ່ | ພອດ | ຂອບເຂດ | ການຂົນສົ່ງ | ທີ່ຢູ່ທີ່ກ່ຽວຂ້ອງ |
|---|
ສະຄຣິບບໍ່ເຫັນຕົວເລືອກ ICE ໃດໆ.
ບັນທຶກທາງເຕັກນິກ
| ໄລຍະ | ສະຖານະ | ລາຍລະອຽດ | ໄລຍະເວລາ |
|---|
ປະຫວັດຂອງແຖບນີ້
ເບິ່ງວ່າທີ່ຢູ່ປ່ຽນໄປລະຫວ່າງການທົດສອບຫຼືບໍ່. ປະຫວັດຈະບໍ່ຄົງຢູ່ຫຼັງປິດແຖບ.
| ເວລາ | ຜົນ | ທີ່ຢູ່ທີ່ເບິ່ງເຫັນ | ຕົວເລືອກ |
|---|
ລາຍງານ JSON ສະແດງໃນເຄື່ອງ
ຂ້ອຍຄວນແປຜົນແນວໃດ?
hostລະບຸອິນເຕີເຟດພາຍໃນ, ຊຶ່ງມັກເຊື່ອງຫຼັງຊື່ mDNS ທີ່ລົງທ້າຍດ້ວຍ.local.srflxເປັນທີ່ຢູ່ reflexive ທີ່ໄດ້ຈາກເຊີບເວີ STUN; ປຽບທຽບກັບທາງອອກ VPN ທີ່ຄາດໄວ້.relayເປັນຂອງ TURN relay ແລະບໍ່ໄດ້ແທນທີ່ຢູ່ເຂົ້າເຖິງຂອງທ່ານໂດຍກົງ.- ການບໍ່ມີຕົວເລືອກສາທາລະນະອາດເກີດຈາກການປ້ອງກັນຂອງບຣາວເຊີ, ການປິດກັ້ນເຄືອຂ່າຍ ຫຼື ການໝົດເວລາ. ສິ່ງນີ້ຢ່າງດຽວບໍ່ພິສູດວ່າບໍ່ມີການຮົ່ວໄຫຼ.
ປຽບທຽບກ່ອນ ແລະຫຼັງ
ທົດສອບດຽວກັນໃນອຸປະກອນດຽວກັນ ແລະບັນທຶກຄ່າພື້ນຖານ. ເປີດ VPN ຫຼືປ່ຽນການຕັ້ງຄ່າທີ່ກ່ຽວຂ້ອງໜຶ່ງຢ່າງ, ທົດສອບອີກພາຍໃຕ້ເງື່ອນໄຂດຽວກັນ ແລະບັນທຶກຜົນຕໍ່ໄປ.
ບັນທຶກຜົນກ່ອນ ແລະຫຼັງເພື່ອປຽບທຽບ.
ການທົດສອບນີ້ບອກຫຍັງ
WebRTC ອາດເລືອກເສັ້ນທາງເຄືອຂ່າຍຕ່າງຈາກຄຳຮ້ອງເວັບທົ່ວໄປ. ການທົດສອບນີ້ຊ່ວຍກວດເສັ້ນທາງເຫຼົ່ານັ້ນໂດຍບໍ່ເລີ່ມການໂທ. ທີ່ຢູ່ສ່ວນຕົວ ຫຼືຊື່ mDNS ຕ່າງຈາກ IP ສາທາລະນະຂອງຜູ້ໃຫ້ອິນເຕີເນັດ ແລະທີ່ຢູ່ TURN relay ເປັນຂອງຈຸດສົ່ງຕໍ່ ບໍ່ໄດ້ລະບຸການເຊື່ອມຕໍ່ຂອງທ່ານໂດຍກົງ.
ວິທີທົດສອບ
- ຮັກສາສະຖານະການເຊື່ອມຕໍ່ໃຫ້ຄົງທີ່ ແລະປ້ອນທີ່ຢູ່ VPN ທີ່ຄາດໄວ້ຖ້າມີອັນທີ່ໜ້າເຊື່ອຖື.
- ເລີ່ມເກັບຕົວເລືອກ; ອາດລວມຄຳຮ້ອງສະທ້ອນ IP ຂອງບຣາວເຊີເພື່ອປຽບທຽບເສັ້ນທາງ HTTPS.
- ອ່ານປະເພດຕົວເລືອກ, ປະເພດທີ່ຢູ່, ຂອບເຂດ ແລະສະຖານະປຽບທຽບ ລວມທັງການເກັບທີ່ບໍ່ຄົບ.
ການວັດເຮັດວຽກແນວໃດ
ບຣາວເຊີເກັບຕົວເລືອກ Interactive Connectivity Establishment ຫຼື ICE ກ່ອນໂດຍບໍ່ມີ STUN/TURN ແລ້ວໃຊ້ເຊີບເວີທີ່ຕັ້ງໄວ້. ປະເພດລວມມີ host, server-reflexive, peer-reflexive ແລະ relay.
ຊ່ອງຂໍ້ມູນເລີ່ມການເກັບໂດຍບໍ່ຂໍສິດກ້ອງ ຫຼືໄມໂຄຣໂຟນ. ຕົວເລືອກຢູ່ໃນບຣາວເຊີ; STUN, TURN ແລະບໍລິການສະທ້ອນທາງເລືອກເຫັນທີ່ຢູ່ຕົ້ນທາງທີ່ໃຊ້ຕິດຕໍ່ມັນ.
ເຂົ້າໃຈຜົນຂອງທ່ານ
- ທີ່ຢູ່ສາທາລະນະກົງກັບເສັ້ນທາງທີ່ຄາດ
- ຕົວເລືອກທີ່ສັງເກດກົງກັບທີ່ຢູ່ VPN ທີ່ປ້ອນ ຫຼືຜົນສະທ້ອນທີ່ປຽບທຽບໄດ້. ນີ້ສະໜັບສະໜູນຄວາມສອດຄ່ອງສຳລັບການສັງເກດນັ້ນ.
- ທີ່ຢູ່ສາທາລະນະທີ່ບໍ່ຄາດ
- ຕົວເລືອກອາດໃຊ້ເສັ້ນທາງອື່ນ. ກວດປະເພດທີ່ຢູ່ ແລະຊະນິດກ່ອນຖືວ່າຄວາມຕ່າງອາດເປີດເຜີຍນອກ VPN ທີ່ຕ້ອງການ.
- ຫຼັກຖານສ່ວນຕົວ, ຜ່ານ relay ຫຼືບໍ່ຄົບ
- ຕົວເລືອກສ່ວນຕົວ ແລະ mDNS ຕ້ອງແປຜົນຕ່າງກັນ; ທີ່ຢູ່ relay ອະທິບາຍ TURN. ການເກັບທີ່ລົ້ມເຫຼວ ຫຼືຫວ່າງເຮັດໃຫ້ຜົນບໍ່ແນ່ນອນ ແມ້ການສະທ້ອນ HTTPS ສຳເລັດ.
ປຽບທຽບກ່ອນ ແລະຫຼັງ
- ບັນທຶກປະເພດຕົວເລືອກ, ປະເພດທີ່ຢູ່, ການຕັ້ງຄ່າ STUN/TURN ແລະທີ່ຢູ່ທີ່ຄາດໃນບຣາວເຊີດຽວກັນ.
- ປ່ຽນການກຳນົດເສັ້ນທາງ VPN ຫຼືການຕັ້ງຄ່າ WebRTC ທີ່ກ່ຽວຂ້ອງໜຶ່ງຢ່າງ ແລ້ວເກັບຊ້ຳແບບດຽວກັນ.
- ປຽບທຽບຕົວເລືອກສາທາລະນະຕາມປະເພດທີ່ຢູ່ ແລະຊະນິດ. ອັບເດດຈຸດອອກທີ່ຄາດສະເພາະເມື່ອຮູ້ແນ່ວ່າມັນປ່ຽນແລ້ວ.
ຂໍ້ຈຳກັດຂອງການທົດສອບ
- ການບໍ່ມີຕົວເລືອກສາທາລະນະບໍ່ພິສູດວ່າທຸກການເຊື່ອມຕໍ່ WebRTC ຫຼີກລ່ຽງເສັ້ນທາງທີ່ບໍ່ຕ້ອງການ.
- ຖ້າບໍ່ມີທີ່ຢູ່ທີ່ຄາດ ຫຼືຜົນສະທ້ອນທີ່ກ່ຽວຂ້ອງສຳເລັດ ບໍ່ສາມາດເອີ້ນຕົວເລືອກສາທາລະນະວ່າຮົ່ວໄຫຼອັດຕະໂນມັດ.
ສິ່ງທີ່ຄວນປ່ຽນຖ້າຈຳເປັນ
- ຕົວເລືອກສາທາລະນະໃຊ້ເສັ້ນທາງ ISP ທີ່ບໍ່ຄາດ
- ກວດເສັ້ນທາງແອັບ ແລະການຈັດການປະເພດທີ່ຢູ່ນັ້ນຂອງ VPN ແລ້ວທົດສອບອີກດ້ວຍເຊີບເວີດຽວກັນ.
- ການເກັບບໍ່ຄົບ
- ກວດນະໂຍບາຍບຣາວເຊີ, firewall ແລະການໃຊ້ງານໄດ້ຂອງເຊີບເວີກ່ອນຕັດສິນເສັ້ນທາງ; ຮັກສາສະຖານະບໍ່ແນ່ນອນ.
ຄຳຖາມທີ່ພົບເລື້ອຍ
ນີ້ເປີ້ດໄມໂຄຣໂຟນຂອງຂ້ອຍບໍ?
ບໍ່. ການເກັບຕົວເລືອກໃຊ້ຊ່ອງຂໍ້ມູນ ແລະບໍ່ຂໍເຂົ້າໃຊ້ກ້ອງ ຫຼືໄມໂຄຣໂຟນ.
ທຸກທີ່ຢູ່ທີ່ຕ່າງກັນເປັນການຮົ່ວໄຫຼບໍ?
ບໍ່. ເຊີບເວີ relay, ປະເພດທີ່ຢູ່ ແລະເສັ້ນທາງຕ່າງໆທີ່ອະນຸຍາດອາດເຮັດໃຫ້ຕ່າງກັນໄດ້ຕາມປົກກະຕິ.