De ce adresa tunelului VPN nu deschide un port de intrare
O adresă de tunel identifică clientul tău în fața partenerilor care pot ruta către ea și nu creează niciodată un ascultător. Verifică legarea, ruta de retur, apoi politica.
Conectează-te la VPN-ul biroului, pornește un serviciu mic pe portul 8443, trimite adresa tunelului unui coleg și privește conexiunea eșuând în timp ce clientul încă raportează că este conectat. Nimic nu este stricat în tunel: adresa a fost alocată, sesiunea este activă, iar pachetele care ar duce răspunsul pur și simplu nu sunt niciodată admise. Fă cele trei verificări de mai jos în ordine și oprește-te la cea care eșuează, pentru că fiecare are altă corecție și doar una dintre ele ține de VPN.
Începe cu locul unde soclul este într-adevăr legat
Înainte ca ceva să fie rutat, ceva trebuie să asculte pe o adresă pe care apelantul o poate atinge. Servere de dezvoltare sunt vinovatul obișnuit, pentru că multe se leagă implicit de loopback și acceptă doar conexiuni care provin de pe aceeași mașină. O adresă de tunel nu schimbă această legare, iar sistemul de operare va refuza conexiunea cu mult înainte ca VPN-ul să fie implicat.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Citește coloana adresei locale, nu starea. 127.0.0.1:8443 înseamnă doar loopback, iar corecția este o legare pe 0.0.0.0 sau pe adresa tunelului însuși. 0.0.0.0:8443 acceptă pe toate interfețele, ceea ce este mai larg decât intenționează majoritatea când mașina are și o adresă publică; 10.64.7.15:8443 este versiunea îngustă care ascultă doar acolo unde poate ajunge colegul. Observă și numele procesului în aceeași ieșire, pentru că o instanță rămasă de la un test anterior este o cauză obișnuită pentru care portul pare deschis și răspunde cu conținut greșit.
Apoi întreabă dacă ceva poate ruta către acea adresă
O adresă de tunel are sens doar pentru partenerii configurați să trimită acel prefix în tunel. Mașina colegului are propriul tabel, iar fără o rută către subrețeaua tunelului, pachetul merge la gateway-ul implicit și moare într-un loc care nu știe că adresa există. Aceasta este o întrebare de rutare de partea apelantului, nu o permisiune de partea ta.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Serverul dintre cei doi clienți contează la fel de mult. În proiectarea obișnuită a accesului la distanță, fiecare client deschide o conexiune de ieșire către gateway, iar gateway-ul ține starea acelor fluxuri, așa că răspunsurile se întorc pe o cale pe care o știe deja. O conexiune de la un client la altul este un flux nou pe care gateway-ul trebuie să îl accepte și să îl transmită, iar multe implementări îl dezactivează intenționat pentru a ține clienții izolați unii de alții. Serviciile VPN pentru consumatori izolează de obicei implicit; gateway-urile corporative permit uneori acest lucru pe grupuri.
Verifică direcția înainte de a schimba ceva pe gazdă. Dacă adresa tunelului răspunde de la gateway-ul însuși, dar nu de la un partener, diferența este setarea client-la-client a gateway-ului, iar nicio editare a firewall-ului local nu o poate înlocui.
În final, găsește politica ce permite fluxul
Trei straturi de politică stau între un pachet rutat și un serviciu care răspunde: decizia de transmitere a serverului VPN, firewall-ul gazdei și orice grup de securitate din cloud din fața instanței. Toate trei trebuie să fie de acord, iar ele eșuează în moduri diferite, de aceea simptomul din tabelul de mai sus este mai util decât mesajul de eroare din browser.
Firewall-ul gazdei este stratul pe care oamenii îl uită după o legare reușită, pentru că o regulă ce permite portul pe interfața LAN nu îl permite automat pe interfața tunelului. Regulile limitate la interfață sunt un proiect corect și, totodată, cauza obișnuită a unui serviciu care funcționează din birou și nu de acasă. Citește domeniul regulii, nu numărul portului.
Filtrarea cu stare explică cazul invers. O conexiune de ieșire de pe laptopul tău creează stare, iar răspunsurile la ea sunt admise fără o regulă de intrare. Conexiunea colegului este un flux complet nou, fără stare în spate, așa că are nevoie de o permisiune explicită. Această asimetrie este tot motivul pentru care o sesiune de browser care funcționează pe propria ta mașină nu spune nimic despre accesibilitatea serviciului din exterior.
Când o verificare eșuează, schimbă proiectarea, nu tunelul
Dacă cerința este ca un coleg să deschidă serviciul tău local, răspunsul onest este de obicei un mecanism construit pentru acces de intrare. Un tunel SSH invers este cel mai mic: mașina ta se conectează în exterior la o gazdă pe care colegul o poate atinge deja, iar ascultătorul există pe acea gazdă.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Releul are nevoie de GatewayPorts clientspecified în configurația serverului SSH, altfel ascultătorul transmis se leagă de loopback pe releu și colegul se lovește de aceeași respingere ca înainte. Pentru orice durează mai mult de o după-amiază, un balansator de încărcare sau un ingress cu verificare de sănătate și certificat pentru numele publicat este instrumentul mai bun, iar un tunel între locații cu rute pentru ambele subrețele este răspunsul corect când două rețele chiar trebuie să vorbească.
Fiecare dintre aceste proiectări face expunerea explicită, și acesta este punctul. Un VPN mută pachete între rețele pentru care erai deja autorizat; nu publică un serviciu și nu transformă un laptop într-o gazdă orientată spre internet. Sarcina este să decizi care dintre cele trei straturi să fie schimbat, iar tunelul este rareori unul dintre ele.