Aling address ang pumapasok sa DNS para sa server na konektado sa VPN?
May tatlong address ang naka-host na server at hindi sila maaaring pagpalitin. Piliin ang value na kailangan ng bawat serbisyo, pagkatapos ay i-verify ito mula sa labas ng makina.
Ang naka-host na server na may naka-install na VPN ay nauuwi sa tatlong address, at isa lamang sa mga ito ang para sa bawat lokasyong iyong i-configure. Ang pagkopya ng numero mula sa panel ng provider papunta sa DNS, sa isang listener, o sa isang allowlist ang paraan kung paano nagiging serbisyong walang makarating ang isang gumaganang tunnel. Inaayos ng gabay na ito ang trabaho upang ang bawat address ay piliin para sa isang nakasaad na layunin. Inililista rin nito ang mga command na nagpapatunay sa aktwal mong na-publish.
I-map ang tatlong address bago mag-publish ng kahit ano
Pangalanan sila ayon sa tungkulin. Ang underlay address ang ginagamit ng makina upang maabot ang endpoint ng VPN sa internet, at madalas ito ay pribado sa likod ng NAT ng provider. Ang tunnel address ay naninirahan sa loob ng VPN, ibinibigay ng server o ng kliyente depende sa produkto. Ang pampublikong labasan ay ang address na itinatala ng malayong website pagkatapos ng pagsasalin, at hindi kailangang umiral ito sa anumang interface na maaari mong tanungin.
Ang panel na nagpapakita ng isang pampublikong address para sa isang makina ay nagsasabi sa iyo ng napakakaunti tungkol sa dalawang iba pang tungkulin. Ang maabot ng underlay ay isang pangangailangan, hindi isang pagbili: ang laptop sa likod ng home router ay maaaring makarating sa naka-host na VPN endpoint nang walang pampublikong IPv4 address. Ang hindi mo magagawa ay mag-imbento ng papasok na landas sa pamamagitan ng pagsulat ng pangalang nagsasalin sa address na walang nagpapasa.
Piliin ang address ayon sa serbisyo, hindi ayon sa label
Isulat kung ano ang dapat gawin ng server bago pumili ng numero. Ang papalabas na tawag sa API ay nangangailangan ng matatag na labasan kapag may allowlist ang kabilang panig. Ang pribadong access ay nangangailangan ng tunnel address na maruruta ng mga kliyente at listener na nakatali rito. Ang pampublikong hosting ay nangangailangan ng papasok na mapping na aktwal na inaalok ng provider, at ang address ng labasan lamang ay hindi nagbibigay nito.
Ang isang makina ay maaaring magserbisyo sa lahat ng tatlong layunin at gumamit pa rin ng tatlong magkaibang address. Ang bumagsak ay ang palagay na ang isang value ay sumasakop sa lahat ng ito:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
Ang papasok na hilera ang pinagtatalunan ng mga tao. Ang record na tumuturo sa address ng labasan ay hindi lumilikha ng listener, butas sa firewall, o port mapping, at hindi ito binabago ng paghihintay. Kapag ang provider ay nagbebenta ng dedikadong address kasama ng papasok na panuntunan, ang bundle na iyon ang kakayahang binili mo; ang address lamang ay hindi ang karapatan.
Mga command na nagpapakita kung aling address ang alin
Basahin ang makina, hindi ang panel. Nagkakaiba ang pangalan ng interface sa bawat sistema, kaya itugma ang mga address sa mga device sa halip na maniwala sa label.
Inililista ng unang linya ang bawat IPv4 address at ang device nito, at tinatanong ng pangalawa ang kernel kung aling device ang gagamitin para sa isang kilalang panlabas na destinasyon:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Kung ang paghahanap ng ruta ay sumasagot ng tunnel device para sa pampublikong trapiko, may bisa ang iyong buong tunnel. Ang pagsusuri sa listener ay kasinghalaga, dahil ang prosesong nakatali lamang sa 127.0.0.1 ay hindi kailanman sasagot sa tunnel address, anuman ang pangalang iyong i-publish.
I-publish ito, pagkatapos ay i-verify mula sa labas
I-publish lamang ang value na kailangan ng serbisyo: A o AAAA record para sa hosting, entry sa allowlist para sa papalabas na tawag, client profile para sa pribadong access. Pagkatapos ay subukan mula sa posisyong mahalaga, at hindi kailanman iyon ang makina na kalilinis mo lang i-edit.
Dalawang pagsusuri ang sumasakop sa karamihan, at pareho silang sapat na mura upang itago sa isang script:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthAng sagot ng DNS na nagpapatunay na umiiral ang iyong record ay hindi patunay na may dumarating na kahilingan, at ang isang matagumpay na kahilingan ay nagpapatunay lamang na may isang landas na gumagana mula sa isang network. Ulitin ang pagsusuri mula sa mobile connection kapag may allowlist na kasangkot, dahil ang labasang nakikita mo ay maaaring depende sa pamilya ng address at sa rutang tinahak. Itala kung aling pamilya ang na-verify mo; ang gumaganang IPv4 na landas ay walang sinasabi tungkol sa IPv6.
Kung ang serbisyo ay papasok, hindi sapat ang address ng labasan
Ang papasok na access ay nangangailangan ng apat na bagay sa isang linya: pangalan o address na maaabot ng kliyente, rutang naghahatid ng packet sa makina, listener na tumatanggap nito, at patakarang hindi ito itinatapon. Binabago ng VPN ang ikalawang elemento at kung minsan ang una, at wala itong ginagawa para sa ikatlo at ikaapat. Kapag ang tunnel ang landas ng paghahatid, kumokonekta ang mga kliyente sa tunnel address, hindi sa labasan.
Itala kung aling address ang nakasalalay sa bawat serbisyo, pagkatapos ay suriin muli ang talaang iyon tuwing babaguhin ng provider ang modelo ng routing nito. Ang server na sumasagot nang pribado at nabigo sa publiko ay karaniwang hindi sira; sumasagot ito sa maling pagkakakilanlan, at ang pag-aayos ay desisyon sa mapping, hindi pagbabago sa firewall.