Miért nem nyit bejövő portot a VPN-alagút címe
Az alagút cím az ügyfélt azon partnerek felé azonosítja, amelyek oda tudnak irányítani, és soha nem hoz létre figyelőt. Ellenőrizze a kötést, a visszautat, majd a szabályt.
Csatlakozzon az irodai VPN-hez, indítson egy kis szolgáltatást a 8443-as porton, küldje el az alagút címét egy kollégának, és figyelje, hogy a kapcsolat meghiúsul, miközben az ügyfél továbbra is kapcsolódott állapotot jelent. Az alagútban semmi sem romlott el: a cím ki lett osztva, a munkamenet él, és a választ szállító csomagokat egyszerűen soha nem engedi át. Végezze el az alábbi három ellenőrzést sorrendben, és álljon meg annál, amelyik meghiúsul, mert mindegyiknek más a javítása, és csak az egyikük szól a VPN-ről.
Kezdje ott, hogy hová van valójában kötve a socket
Mielőtt bármi útvonalat kapna, valaminek hallgatnia kell egy címen, amelyet a hívó elér. A fejlesztői kiszolgálók a szokásos bűnösök, mert közülük sok alapértelmezés szerint a loopbackhez kötődik, és csak az ugyanazon a gépen keletkező kapcsolatokat fogadja el. Az alagút cím nem változtat ezen a kötésen, és az operációs rendszer jóval korábban elutasítja a kapcsolatot, mint hogy a VPN egyáltalán szóba kerülne.
ss -ltnp | grep 8443
netstat -ano | findstr 8443A helyi cím oszlopát olvassa, ne az állapotot. A 127.0.0.1:8443 csak loopbacket jelent, és a javítás a kötés a 0.0.0.0-ra vagy magára az alagút címére. A 0.0.0.0:8443 minden interfészen fogad, ami szélesebb annál, amit a legtöbben szándékoznak, amikor a gépnek nyilvános címe is van; a 10.64.7.15:8443 a szűk változat, amely csak ott hallgat, ahová a kolléga eljut. Figyelje meg a folyamat nevét ugyanabban a kimenetben, mert egy korábbi tesztből maradt példány gyakori oka annak, hogy a port nyitottnak látszik, és rossz tartalommal válaszol.
Aztán kérdezze meg, tud-e valami útvonalat adni ahhoz a címhez
Az alagút címnek csak azok a partnerek számára van értelme, amelyek úgy vannak beállítva, hogy ezt az előtagot az alagútba küldjék. A kolléga gépe saját táblával rendelkezik, és ha nincs útvonala az alagút alhálózatához, a csomag az alapértelmezett átjáróhoz megy, és olyan helyen hal el, amelynek fogalma sincs a cím létezéséről. Ez útvonalválasztási kérdés a hívó oldalán, nem engedély az Ön oldalán.
| 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 |
A két ügyfél közötti kiszolgáló ugyanolyan fontos. A szokásos távoli hozzáférési kialakításban minden ügyfél kimenő kapcsolatot nyit az átjáró felé, és az átjáró nyilvántartja ezeknek a folyamoknak az állapotát, így a válaszok olyan úton jönnek vissza, amelyet már ismer. Az egyik ügyféltől a másikig tartó kapcsolat új folyam, amelyet az átjárónak fogadnia és továbbítania kell, és sok telepítés ezt szándékosan kikapcsolja, hogy az ügyfeleket elkülönítve tartsa egymástól. A fogyasztói VPN-szolgáltatások általában alapértelmezés szerint elkülönítenek; a vállalati átjárók ezt néha csoportonként engedélyezik.
Ellenőrizze az irányt, mielőtt bármit módosít a hoston. Ha az alagút cím magától az átjárótól válaszol, de egy partnertől nem, a különbség az átjáró ügyféltől ügyfélig beállítása, és a helyi tűzfal semmilyen szerkesztése nem pótolhatja.
Végül keresse meg a folyamot engedélyező szabályt
Három szabályréteg áll az útvonalon továbbított csomag és a válaszoló szolgáltatás között: a VPN-kiszolgáló továbbítási döntése, a host tűzfala és az példány előtti bármely felhő biztonsági csoport. Mindháromnak egyet kell értenie, és különböző módokon hibáznak, ezért hasznosabb a fenti táblázat tünete, mint a böngésző hibaüzenete.
A host tűzfala az a réteg, amelyet a sikeres kötés után elfelejtenek, mert a LAN-interfészen a portot engedélyező szabály nem engedélyezi azt automatikusan az alagút interfészén. Az interfészhez kötött szabályok helyes tervezés, és egyben a szokásos oka annak a szolgáltatásnak, amely az irodából működik, otthonról nem. A szabály hatókörét olvassa, ne a portszámát.
Az állapotkövető szűrés magyarázza a fordított esetet. A laptopjáról induló kimenő kapcsolat állapotot hoz létre, és a válaszok bejövő szabály nélkül átjutnak. A kolléga kapcsolata teljesen új folyam, amely mögött nincs állapot, ezért kifejezett engedélyt igényel. Ez az aszimmetria az egész oka annak, hogy a saját gépén működő böngésző-munkamenet semmit sem mond arról, elérhető-e a szolgáltatás kívülről.
Ha egy ellenőrzés meghiúsul, a tervezést változtassa meg, ne az alagutat
Ha az a követelmény, hogy egy kolléga nyissa meg a helyi szolgáltatását, az őszinte válasz általában egy bejövő hozzáférésre épített mechanizmus. A fordított SSH-alagút a legkisebb: a gépe kimenő kapcsolatot létesít egy olyan host felé, amelyet a kolléga már elér, és a figyelő azon a hoston létezik.
ssh -N -R 8443:127.0.0.1:8443 [email protected]A relének GatewayPorts clientspecified beállításra van szüksége az SSH-kiszolgáló konfigurációjában, különben a továbbított figyelő a relén a loopbackhez kötődik, és a kolléga ugyanazzal az elutasítással találkozik, mint korábban. Mindenre, ami egy délutánnál tovább tart, a terheléselosztó vagy a health checkkel és a közzétett névhez tartozó tanúsítvánnyal rendelkező ingress a jobb eszköz, és amikor két hálózatnak valóban kommunikálnia kell, a két alhálózat útvonalaival rendelkező telephelyek közötti alagút a helyes válasz.
Mindegyik kialakítás kifejezetté teszi a kitettséget, és ez a lényeg. A VPN csomagokat mozgat olyan hálózatok között, amelyek használatára már jogosult volt; nem tesz közzé szolgáltatást, és nem alakít egy laptopot internet felé néző hosttá. A feladat annak eldöntése, hogy a három réteg közül melyiket változtassa meg, és az alagút ritkán tartozik közéjük.