Ce adresă se pune în DNS pentru un server conectat prin VPN?
Un server găzduit are trei adrese și ele nu sunt interschimbabile. Alege valoarea de care are nevoie fiecare serviciu, apoi confirmă-o din afara mașinii.
Un server găzduit cu un VPN instalat ajunge să aibă trei adrese, iar doar una dintre ele își are locul în fiecare loc pe care urmează să îl configurezi. Copierea numărului dintr-un panou al furnizorului în DNS, într-un listener sau într-o listă de permisiuni este modul în care un tunel funcțional devine un serviciu pe care nimeni nu îl poate atinge. Acest ghid ordonează munca astfel încât fiecare adresă să fie aleasă pentru un scop declarat. De asemenea, enumeră comenzile care confirmă ce ai publicat de fapt.
Cartografiază cele trei adrese înainte de a publica ceva
Denumește-le după funcție. Adresa de underlay este cea pe care mașina o folosește pentru a ajunge la endpointul VPN prin internet și este adesea privată în spatele NAT-ului furnizorului. Adresa de tunel trăiește în interiorul VPN-ului, atribuită de server sau de client în funcție de produs. Ieșirea publică este adresa pe care un site remote o înregistrează după traducere, și nu trebuie să existe pe nicio interfață pe care o poți interoga.
Un panou care arată o singură adresă publică pentru o mașină îți spune foarte puțin despre celelalte două roluri. Accesibilitatea underlay este o cerință, nu o achiziție: un laptop în spatele unui router de acasă poate ajunge la un endpoint VPN găzduit fără să dețină o adresă IPv4 publică. Ce nu poți face este să inventezi o cale de intrare scriind un nume care rezolvă către o adresă pe care nimeni nu o redirecționează.
Alege adresa după serviciu, nu după etichetă
Notează ce trebuie să facă serverul înainte de a alege un număr. Apelurile API de ieșire au nevoie de o ieșire stabilă atunci când cealaltă parte ține o listă de permisiuni. Accesul privat are nevoie de o adresă de tunel către care clienții pot ruta și de un listener legat de ea. Găzduirea publică are nevoie de o mapare de intrare pe care furnizorul o oferă cu adevărat, iar adresa de ieșire singură nu o furnizează.
O singură mașină poate servi toate cele trei scopuri și totuși poate folosi trei adrese diferite. Ce se rupe este presupunerea că o singură valoare le acoperă pe toate:
| 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 |
Rândul de intrare este cel despre care oamenii se ceartă. O înregistrare care indică adresa de ieșire nu creează listener, nicio deschidere de firewall și nicio mapare de port, iar așteptarea nu schimbă asta. Când furnizorul vinde o adresă dedicată împreună cu o regulă de intrare, acel pachet este capacitatea pe care ai cumpărat-o; adresa singură nu este dreptul.
Comenzi care arată care adresă este care
Citește mașina, nu panoul. Numele interfețelor diferă între sisteme, așa că asociază adresele cu dispozitivele în loc să te bazezi pe o etichetă.
Prima linie listează fiecare adresă IPv4 și dispozitivul ei, iar a doua întreabă nucleul ce dispozitiv ar folosi pentru o destinație externă cunoscută:
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)'Dacă interogarea de rută răspunde cu un dispozitiv de tunel pentru traficul public, tunelul tău complet este în vigoare. Verificarea listenerului contează la fel de mult, pentru că un proces legat doar de 127.0.0.1 nu va răspunde niciodată pe adresa de tunel, indiferent ce nume publici.
Publică-l, apoi verifică din exterior
Publică valoarea de care are nevoie serviciul și nimic mai mult: o înregistrare A sau AAAA pentru găzduire, o intrare în lista de permisiuni pentru apelurile de ieșire, un profil de client pentru accesul privat. Apoi testează din poziția care contează, iar aceea nu este niciodată mașina pe care tocmai ai editat-o.
Două verificări acoperă cea mai mare parte, și ambele sunt suficient de ieftine pentru a fi păstrate într-un script:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthUn răspuns DNS care dovedește că înregistrarea ta există nu este dovada că sosește o cerere, iar o cerere reușită dovedește doar că o cale funcționează dintr-o rețea. Repetă verificarea de pe o conexiune mobilă atunci când este implicată o listă de permisiuni, pentru că ieșirea pe care o observi poate depinde de familia de adrese și de ruta urmată. Notează ce familie ai verificat; o cale IPv4 funcțională nu spune absolut nimic despre IPv6.
Dacă serviciul este de intrare, adresa de ieșire nu este suficientă
Accesul de intrare are nevoie de patru lucruri aliniate: un nume sau o adresă la care un client poate ajunge, o rută care livrează pachetul la mașină, un listener care îl acceptă și o politică ce nu îl aruncă. Un VPN schimbă al doilea element și uneori primul, iar pentru al treilea și al patrulea nu face nimic. Când tunelul este calea de livrare, clienții se conectează la adresa de tunel, nu la ieșire.
Notează de ce adresă depinde fiecare serviciu, apoi revizuiește acea notă ori de câte ori furnizorul își schimbă modelul de rutare. Un server care răspunde în privat și eșuează public nu este de obicei stricat; răspunde sub identitatea greșită, iar reparația este o decizie de mapare și nu o modificare de firewall.