Gateway-ul găzduiește propria pagină de administrare: adresă internă sau publică

O pagină de administrare răspunde de pe un telefon pe date mobile și expiră de pe un laptop conectat la VPN. Nimic din tunel nu este stricat, pentru că cererea nu intră niciodată în el. Numele de gazdă se rezolvă la adresa publică a gateway-ului, iar acea adresă este accesibilă doar din afara tunelului pe care îl termină. Repararea înseamnă să dai serviciului o intrare privată, nu să muți punctul final exterior.

Pagina se încarcă din exterior și nu prin tunel

Se compară două cereri diferite. Din date mobile, browserul ajunge direct la adresa publică. Din interiorul tunelului, același nume se rezolvă la aceeași adresă publică, iar pachetul trebuie acum să iasă prin tunel pentru a ajunge la o adresă de pe partea îndepărtată a tunelului însuși. Același nume, aceeași adresă, două poziții foarte diferite.

O rută de destinație alege o adresă, nu un port. Nimic din tabela de rutare nu știe că portul 443 este pentru administrare și portul 1194 este transportul, așa că ambele sunt tratate ca aceeași destinație.

De aceea pagina funcționează uneori și alteori nu, în funcție de numele și rețeaua pe care le-a folosit clientul. Este o problemă de traseu și nu o problemă de autentificare. Ambii clienți se autentifică foarte bine.

Păstrați punctul final exterior accesibil

Profilurile de tunel complet au nevoie de o rută de excepție pentru punctul final VPN, iar opțiunea redirect-gateway a OpenVPN documentează exact asta: punctul final îndepărtat păstrează o rută prin gateway-ul preexistent, astfel încât tunelul să nu rutaze spre sine. Eliminați acea excepție și transportul criptat urmează tunelul, ceea ce termină sesiunea într-o buclă. Acea excepție este motivul pentru care adresa punctului final rămâne accesibilă din interiorul tunelului.

Consecința este că adresa publică rămâne accesibilă de la client, motiv pentru care o cerere a browserului către acea adresă poate urma aceeași excepție și poate ieși fără să intre în tunel. Excepția își face treaba, iar numele face paguba.

Citiți decizia rutei, nu lista de interfețe, înainte de a schimba ceva. Comenzile de mai jos tipăresc decizia, nu inventarul. Rulați-le de pe clientul care a eșuat.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Dacă interogarea arată ruta punctului final prin gateway-ul fizic, comportamentul este corect și pagina de administrare este pur și simplu trimisă pe traseul greșit. Acolo rezolvarea numelor devine remediul.

Dați serviciului un nume privat

Serviciul are nevoie de un nume care se rezolvă la adresa gateway-ului în interiorul tunelului, păstrând în același timp semantica certificatului și a numelui de gazdă pe care o așteaptă aplicația. O înregistrare de zonă privată pentru numele de administrare este răspunsul obișnuit, și lasă neatins numele de transport.

Nu repointați numele de transport către adresa internă, pentru că următoarea stabilire a tunelului ar încerca atunci să ajungă la o adresă care există doar în interiorul unui tunel. Acea greșeală produce un VPN care funcționează exact o dată.

Verificați și ambele familii de adrese, pentru că o înregistrare AAAA lăsată în urmă poate trimite browserul undeva unde planul privat nu a ajuns niciodată.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Potriviți politica cu locul unde rulează procesul

La un proces nativ care ascultă pe gateway se ajunge prin calea de intrare locală, așa că lanțul de intrare și legarea socketului decid dacă cererea este acceptată. Regulile de redirecționare și redirecționarea IP nu fac un ascultător local să răspundă. Permiteți sursele tunelului în politica de intrare și confirmați că procesul este legat de o adresă pe care tunelul o poate atinge.

Un container publicat pe un port al gazdei urmează o cale diferită, pentru că pachetul este tradus pe destinație și redirecționat. Acea cerere întâlnește politica de redirecționare a gazdei și regulile proprii ale Docker, motiv pentru care un ascultător nativ funcțional poate coexista cu un container care refuză același port.

Ordinea de pornire contează în ambele cazuri, pentru că o legare la o adresă care apare doar după ce tunelul urcă eșuează în tăcere la boot.

Verificați accesul privat și o cale publică refuzată

Faceți o cerere nouă, cu nume, de la un client autorizat, cu verificările de identitate proprii aplicației intacte. Apoi încercați același serviciu din afara tunelului și confirmați că nu răspunde. Un nume privat este o comoditate și nu o restricție, iar un ascultător încă legat de adresa publică este încă expus. Această ultimă verificare este cea pe care majoritatea recenziilor o sar.

Citiți legările și starea filtrului, nu numele de gazdă primit de utilizatori. Expunerea este o proprietate a socketului și nu a numelui. Această distincție supraviețuiește fiecărei schimbări de DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Când cererea internă returnează pagina și cererea externă expiră, serviciul are o cale privată deliberată și transportul rămâne accesibil. Când cererea externă încă răspunde, ascultătorul sau o intrare de container publicată trebuie restrânsă înainte ca cineva să descrie serviciul ca fiind doar intern.