Cila adresë shkon në DNS për një server të lidhur me VPN?
Një server i strehuar mban tri adresa dhe ato nuk janë të këmbyeshme. Zgjidhni vlerën që i duhet secilit shërbim, pastaj konfirmojeni nga jashtë makinës.
Një server i strehuar me një VPN të instaluar përfundon duke mbajtur tri adresa, dhe vetëm njëra prej tyre i takon secilit vend që po përgatiteni të konfiguroni. Kopjimi i numrit nga një panel i ofruesit në DNS, në një dëgjues ose në një listë lejimesh është mënyra se si një tunel që funksionon kthehet në një shërbim që askush nuk mund ta arrijë. Ky udhëzues e rendit punën në mënyrë që çdo adresë të zgjidhet për një qëllim të deklaruar. Ai liston gjithashtu komandat që konfirmojnë atë që keni publikuar në të vërtetë.
Hartoni tri adresat përpara se të publikoni ndonjë gjë
Emërtoni ato sipas funksionit. Adresa e underlay-it është ajo që makina përdor për të arritur pikën përfundimtare të VPN-së nëpër internet, dhe shpesh është private pas NAT-it të ofruesit. Adresa e tunelit jeton brenda VPN-së, e dhënë nga serveri ose klienti në varësi të produktit. Dalja publike është adresa që një faqe interneti e largët regjistron pas përkthimit, dhe nuk ka nevojë të ekzistojë në ndonjë ndërfaqe që mund të pyesni.
Një panel që tregon një adresë publike për një makinë ju thotë shumë pak për dy rolet e tjera. Arritshmëria e underlay-it është kërkesë, jo blerje: një laptop pas një ruteri shtëpiak mund të arrijë një pikë përfundimtare VPN të strehuar pa zotëruar një adresë publike IPv4. Ajo që nuk mund të bëni është të shpikni një rrugë hyrëse duke shkruar një emër që zgjidhet në një adresë që askush nuk e përcjell.
Zgjidhni adresën sipas shërbimit, jo sipas etiketës
Shkruani çfarë duhet të bëjë serveri përpara se të zgjidhni një numër. Thirrjet dalëse të API-t kanë nevojë për një dalje të qëndrueshme kur pala tjetër mban një listë lejimesh. Aksesi privat ka nevojë për një adresë tuneli ku klientët mund të ushtrojnë rrugëzim dhe një dëgjues të lidhur me të. Strehimi publik ka nevojë për një hartëzim hyrës që ofruesi e ofron vërtet, dhe adresa e daljes vetëm nuk e siguron atë.
Një makinë e vetme mund t'u shërbejë të tre qëllimeve dhe gjithsesi të përdorë tri adresa të ndryshme. Ajo që thyhet është supozimi se një vlerë i mbulon të gjitha:
| 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 |
Rreshti hyrës është ai për të cilin njerëzit debatojnë. Një regjistrim që tregon adresën e daljes nuk krijon dëgjues, as hapje të firewall-it, as hartëzim porti, dhe pritja nuk e ndryshon këtë. Kur ofruesi shet një adresë të dedikuar së bashku me një rregull hyrës, ai paket është aftësia që keni blerë; adresa vetëm nuk është e drejta.
Komanda që tregojnë cila adresë është cila
Lexoni makinën, jo panelin. Emrat e ndërfaqeve ndryshojnë midis sistemeve, prandaj përputhni adresat me pajisjet në vend që t'i besoni një etikete.
Rreshti i parë liston çdo adresë IPv4 dhe pajisjen e saj, dhe i dyti pyet kernelin cilën pajisje do të përdorte për një destinacion të njohur të jashtëm:
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)'Nëse kërkimi i rrugës përgjigjet me një pajisje tuneli për trafikun publik, tuneli juaj i plotë është në fuqi. Kontrolli i dëgjuesit ka po aq rëndësi, sepse një proces i lidhur vetëm me 127.0.0.1 nuk do të përgjigjet kurrë në adresën e tunelit, cilindo emër që publikoni.
Publikojeni, pastaj verifikoni nga jashtë
Publikoni vlerën që i duhet shërbimit dhe asgjë më shumë: një regjistrim A ose AAAA për strehim, një zë në listën e lejimeve për thirrjet dalëse, një profil klienti për akses privat. Pastaj testoni nga pozicioni që ka rëndësi, dhe ai nuk është kurrë makina që sapo redaktuat.
Dy kontrolle mbulojnë pjesën më të madhe, dhe të dyja janë mjaft të lira për t'i mbajtur në një skript:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthNjë përgjigje DNS që provon se regjistrimi juaj ekziston nuk është provë se një kërkesë arrin, dhe një kërkesë e suksesshme provon vetëm se një rrugë funksionon nga një rrjet. Përsëriteni kontrollin nga një lidhje celulare kur është e përfshirë një listë lejimesh, sepse dalja që vëzhgoni mund të varet nga familja e adresave dhe rruga e ndjekur. Shënoni cilën familje verifikuat; një rrugë IPv4 që funksionon nuk thotë absolutisht asgjë për IPv6.
Nëse shërbimi është hyrës, adresa e daljes nuk mjafton
Aksesi hyrës ka nevojë për katër gjëra të rreshtuara: një emër ose adresë që një klient mund ta arrijë, një rrugë që e dorëzon paketën në makinë, një dëgjues që e pranon atë dhe një politikë që nuk e hedh poshtë. Një VPN ndryshon elementin e dytë dhe ndonjëherë të parin, dhe nuk bën asgjë për të tretin dhe të katërtin. Kur tuneli është rruga e dorëzimit, klientët lidhen me adresën e tunelit, jo me daljen.
Shënoni nga cila adresë varet secili shërbim, pastaj rishikoni atë shënim sa herë që ofruesi ndryshon modelin e tij të rrugëzimit. Një server që përgjigjet privatisht dhe dështon publikisht zakonisht nuk është i prishur; ai po përgjigjet me identitetin e gabuar, dhe riparimi është një vendim hartëzimi dhe jo një ndryshim i firewall-it.