Kiun adreson oni metas en DNS por servilo konektita per VPN?
Gastigita servilo havas tri adresojn kaj ili ne estas interŝanĝeblaj. Elektu la valoron, kiun bezonas ĉiu servo, poste konfirmu ĝin de ekster la maŝino.
Gastigita servilo kun instalita VPN finfine havas tri adresojn, kaj nur unu el ili apartenas al ĉiu loko, kiun vi prepare konfiguros. Kopii la numeron el panelo de provizanto en DNS, en aŭskultanton aŭ en permesliston estas la maniero, kiel funkcianta tunelo fariĝas servo, kiun neniu povas atingi. Ĉi tiu gvidilo ordigas la laboron tiel, ke ĉiu adreso estas elektita por deklarita celo. Ĝi ankaŭ listigas la komandojn, kiuj konfirmas, kion vi fakte publikigis.
Mapu la tri adresojn antaŭ ol publikigi ion ajn
Nomu ilin laŭ funkcio. La underlay-adreso estas tio, kion la maŝino uzas por atingi la finpunkton de VPN tra la interreto, kaj ĝi ofte estas privata malantaŭ la NAT de la provizanto. La tunela adreso vivas ene de la VPN, donita de la servilo aŭ de la kliento laŭ la produkto. La publika eliro estas la adreso, kiun fora retejo registras post la traduko, kaj ĝi ne devas ekzisti sur iu ajn interfaco, kiun vi povas demandi.
Panelo, kiu montras unu publikan adreson por maŝino, diras al vi tre malmulte pri la aliaj du roloj. Atingeblo de underlay estas postulo, ne aĉeto: tekkomputilo malantaŭ hejma enkursigilo povas atingi gastigitan VPN-finpunkton sen posedi publikan IPv4-adreson. Kion vi ne povas, estas elpensi envenan vojon skribante nomon, kiu solviĝas al adreso, kiun neniu plusendas.
Elektu la adreson laŭ la servo, ne laŭ la etikedo
Notu, kion la servilo devas fari antaŭ ol elekti numeron. Elirantaj API-vokoj bezonas stabilan eliron, kiam la alia flanko tenas permesliston. Privata aliro bezonas tunelan adreson, al kiu klientoj povas enkursigi, kaj aŭskultanton ligitan al ĝi. Publika gastigado bezonas envenan mapadon, kiun la provizanto vere proponas, kaj la elira adreso sola ne provizas ĝin.
Unu maŝino povas servi al ĉiuj tri celoj kaj tamen uzi tri malsamajn adresojn. Tio, kio rompiĝas, estas la supozo, ke unu valoro kovras ilin ĉiujn:
| 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 |
La envena vico estas tiu, pri kiu homoj disputas. Registro montranta al la elira adreso kreas neniun aŭskultanton, neniun truon en fajroŝirmilo kaj neniun pordan mapadon, kaj atendo tion ne ŝanĝas. Kiam la provizanto vendas dediĉitan adreson kune kun envena regulo, tiu pako estas la kapablo, kiun vi aĉetis; la adreso mem ne estas rajto.
Komandoj, kiuj montras, kiu adreso estas kiu
Legu la maŝinon, ne la panelon. Interfacaj nomoj malsamas inter sistemoj, do parigu adresojn al aparatoj anstataŭ fidi etikedon.
La unua linio listigas ĉiun IPv4-adreson kaj ĝian aparaton, kaj la dua demandas la kernon, kiun aparaton ĝi uzu por konata ekstera celo:
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)'Se la vojserĉo respondas per tunela aparato por publika trafiko, via plena tunelo validas. La kontrolo de la aŭskultanto same gravas, ĉar procezo ligita nur al 127.0.0.1 neniam respondos ĉe la tunela adreso, kiun nomon ajn vi publikigos.
Publikigu ĝin, poste kontrolu de ekstere
Publikigu nur la valoron, kiun la servo bezonas: registron A aŭ AAAA por gastigado, listan eron por elirantaj vokoj, klientan profilon por privata aliro. Poste testu el la pozicio, kiu gravas, kaj tio neniam estas la maŝino, kiun vi ĵus redaktis.
Du kontroloj kovras la plejparton, kaj ambaŭ estas sufiĉe malmultekostaj por resti en skripto:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthDNS-respondo, kiu pruvas, ke via registro ekzistas, ne estas pruvo, ke peto alvenas, kaj unu sukcesa peto pruvas nur, ke unu vojo funkcias el unu reto. Ripetu la kontrolon el poŝa konekto, kiam permeslisto implikiĝas, ĉar la eliro, kiun vi observas, povas dependi de la adresa familio kaj de la prenita vojo. Notu, kiun familion vi kontrolis; funkcianta IPv4-vojo diras absolute nenion pri IPv6.
Se la servo estas envena, la elira adreso ne sufiĉas
Envena aliro bezonas kvar aferojn en unu linio: nomon aŭ adreson, kiun kliento povas atingi, vojon, kiu liveras la paketon al la maŝino, aŭskultanton, kiu akceptas ĝin, kaj politikon, kiu ne faligas ĝin. VPN ŝanĝas la duan elementon kaj foje la unuan, kaj faras nenion por la tria kaj kvara. Kiam la tunelo estas la livera vojo, klientoj konektiĝas al la tunela adreso, ne al la eliro.
Registru, de kiu adreso dependas ĉiu servo, poste revizuu tiun noton ĉiufoje, kiam la provizanto ŝanĝas sian enkursigan modelon. Servilo, kiu respondas private kaj malsukcesas publike, kutime ne estas rompita; ĝi respondas sub la malĝusta identeco, kaj la riparo estas mapada decido, ne ŝanĝo de fajroŝirmilo.