Poate un client VPN itinerant să găzduiască un serviciu pentru birou?

Laptopul de birou se poate conecta de acasă și totuși poate furniza ceva de care biroul are nevoie, dar numai când trei decizii separate se aliniază. Tunelul este transport, adresa internă este destinația, iar politica decide cine poate bate la ușă. Tratarea oricăreia dintre ele drept răspuns complet produce reclamația cunoscută: gazda răspunde la pinguri, dar aplicația nu se conectează niciodată. Rolurile nu sunt aceleași, iar diferența este exact acolo unde se află munca de proiectare.

Direcția conexiunii nu spune nimic despre direcția serviciului

Când un client pornește un tunel, deschide o cale pe care ambele direcții o pot folosi odată ce există. Dacă o conexiune nouă poate intra din hub către acel client este o chestiune de politică a gateway-ului, nu o proprietate a celui care s-a conectat. Pe un hub OpenVPN rutat, de exemplu, serverul are nevoie de o rută către adresa internă a clientului și de forwarding care permite relația peer.

Imaginați-vă un sistem de inventar care interoghează un agent pe laptopuri itinerante, sau un dezvoltator care are nevoie de un API de test de la o stație de lucru de acasă. Ambele vor ca partea biroului să înceapă conversația, ceea ce este inversul modelului obișnuit client-la-server.

Produsele de acces la distanță găzduite diferă aici, iar diferența nu este un defect. Unele VPN administrate blochează deliberat conexiunile nesolicitate către clienții conectați pentru că modelul lor este client-la-resursă, nu resursă-la-client. Citiți arhitectura documentată a produsului înainte de a promite unui coleg că laptopul său poate acționa ca server.

Urmați calea de întoarcere înainte de a deschide un port

Calea are trei părți: o rută pe gateway care indică adresa internă a clientului, o politică ce permite apelantul concret și un serviciu care ascultă pe țintă. Fiecare parte eșuează diferit, de aceea „VPN-ul este pornit” aproape nu spune nimic.

Vestea bună este că calea internă nu are nevoie de port forwarding pe routerul de acasă al clientului. Acesta este sensul publicării serviciului pe adresa tunelului în loc de adresa WAN de acasă, unde expunerea și regulile NAT ar fi cu totul altele. Un router de acasă poate refuza și hairpin-ul unei conexiuni care vine din birou, așa că ruta WAN eșuează din motive fără legătură cu VPN-ul dvs. Păstrarea traficului în interiorul tunelului evită ambele probleme deodată.

Verificați și partea țintă. Un serviciu legat doar de 127.0.0.1 nu poate accepta o conexiune care sosește pe interfața tunelului, oricât de corecte ar fi rutele gateway-ului. O regulă de firewall a gazdei care permite portul doar din subrețeaua locală va elimina și traficul biroului, iar acea regulă este independentă de politica VPN de deasupra.

Numele și adresele sunt decizii de proiectare

O adresă din interiorul tunelului nu este automat un nume. O înregistrare DNS privată pe care o controlați este mai clară decât speranța că un protocol de descoperire va traversa tunelul, deoarece rezoluția numelor prin multicast local rămâne în segmentul local și nu devine DNS între subrețele.

Stabilitatea adresei contează la fel de mult. Dacă clienții VPN iau adrese dintr-un pool cu închirieri scurte, adresa internă a laptopului se schimbă între sesiuni și fiecare marcaj, domeniu de firewall și verificare de monitorizare construite pe ea se strică în liniște. Folosiți o rezervare sau o cale documentată de actualizare dinamică.

Stabiliți numele împreună cu cel care deține identitatea VPN, astfel încât înregistrarea, alocarea adresei și politica de acces să se schimbe împreună, nu în trei tichete separate.

Testați serviciul, nu apartenența

Din țintă, confirmați ce ascultă și pe ce adresă, apoi confirmați viziunea gateway-ului asupra căii de întoarcere:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Acum testați din partea biroului cu o cerere reală în loc de un ecou. Un curl reușit către serviciu dovedește ruta, politica și ascultătorul deodată, în timp ce un ping reușit dovedește doar că ICMP este permis. Dacă cererea eșuează, mergeți înapoi prin cele trei părți în loc să lărgiți firewall-ul și să sperați.

Disponibilitatea face parte din aceeași discuție. Un laptop doarme, migrează între rețele și se deconectează la sfârșitul zilei. Un serviciu care trebuie să răspundă la orice oră aparține unei gazde mereu pornite, în timp ce un serviciu best-effort poate rămâne pe client cu această limitare notată.

Publicați resursa în mod deliberat, cu un nume, o listă de apelanți permiși și un proprietar, iar dispozitivul la distanță devine un serviciu acceptat în loc de un server accidental.