Kvifor VPN-tunneladressa di ikkje opnar ein innkomande port
Ei tunneladresse identifiserer klienten din overfor partnarar som kan rute dit, og lagar aldri ein lyttar. Kontroller bindinga, returruta og deretter policyen.
Kopla til VPN-en på kontoret, start ein liten teneste på port 8443, send tunneladressa til ein kollega og sjå at sambandet feilar medan klienten framleis rapporterer at han er tilkopla. Ingenting er øydelagt i tunnelen: adressa er delt ut, økta er oppe, og pakkane som skulle bere svaret blir rett og slett aldri sleppte inn. Gjer dei tre kontrollane nedanfor i rekkjefølgje og stopp ved den som feilar, fordi kvar har si eiga retting og berre éin av dei handlar om VPN.
Byrja med kvar socketen faktisk er bunden
Før noko blir ruta, må noko lytta på ei adresse som den som ringer kan nå. Utviklartenester er den vanlege syndaren, fordi mange av dei som standard bind til loopback og berre godtek samband som kjem frå same maskin. Ei tunneladresse endrar ikkje denne bindinga, og operativsystemet vil avvise sambandet lenge før VPN er involvert.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Les kolonnen for den lokale adressa i staden for tilstanden. 127.0.0.1:8443 tyder berre loopback, og rettinga er ei binding på 0.0.0.0 eller på sjølve tunneladressa. 0.0.0.0:8443 godtek på alle grensesnitt, noko som er breiare enn dei fleste meiner når maskinen også har ei offentleg adresse; 10.64.7.15:8443 er den smale versjonen som berre lyttar der kollegaen kan nå henne. Legg også merke til prosessnamnet i same utdata, fordi ein gløymd instans frå ein tidlegare test er ein vanleg grunn til at porten ser open ut og svarar med feil innhald.
Spør deretter om noko kan rute til den adressa
Ei tunneladresse er berre meiningsfull for partnarar som er konfigurerte til å sende det prefikset inn i tunnelen. Maskinen til kollegaen har si eiga tabell, og utan ei rute til tunnelsubnettet går pakken til standardgatewayen og døyr på ein stad som ikkje anar at adressa finst. Dette er eit rutingsspørsmål på sida til den som ringer, ikkje ei løyve på di side.
| 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 |
Tenaren mellom dei to klientane tyder like mykje. I det vanlege designet for fjern tilgang opnar kvar klient eit utgåande samband til gatewayen, og gatewayen held tilstand for desse straumane, slik at svar kjem tilbake via ein veg han allereie kjenner. Eit samband frå éin klient til ein annan er ein ny straum som gatewayen må godta og videresende, og mange installasjonar slår det bevisst av for å halde klientane isolerte frå kvarandre. Forbrukar-VPN-tenester isolerer vanlegvis som standard; bedriftsgatewayar tillèt det av og til per gruppe.
Kontroller retninga før du endrar noko på verten. Viss tunneladressa svarar frå gatewayen sjølv, men ikkje frå ein partnar, er skilnaden innstillinga til gatewayen for klient-til-klient, og inga redigering av den lokale brannmuren kan erstatte henne.
Finn til slutt policyen som tillèt straumen
Tre policylag ligg mellom ein ruta pakke og ei teneste som svarar: videresendingsvedtaket til VPN-tenaren, brannmuren til verten og kvar som helst skysikkerheitsgruppe framfor instansen. Alle tre må vere samde, og dei feilar på ulike måtar, difor er symptomet i tabellen ovanfor nyttigare enn feilmeldinga i nettlesaren.
Brannmuren til verten er laget folk gløymer etter ei vellukka binding, fordi ein regel som tillèt porten på LAN-grensesnittet ikkje automatisk tillèt han på tunnelgrensesnittet. Reglar avgrensa til grensesnitt er riktig design og også den vanlege årsaka til ei teneste som verkar frå kontoret og ikkje heimanfrå. Les omfanget av regelen i staden for portnummeret.
Stateful filtrering forklarar det motsette tilfellet. Eit utgåande samband frå laptoppen din lagar tilstand, og svara på det blir sleppte inn utan ein innkomande regel. Sambandet til kollegaen er ein heilt ny straum utan tilstand bak seg, så det treng ei uttrykkeleg løyve. Denne asymmetrien er heile grunnen til at ei fungerande nettlesarøkt på din eigen maskin ikkje seier noko om tenesta er tilgjengeleg utanfrå.
Når éin kontroll feilar, endre designet i staden for tunnelen
Viss kravet er at ein kollega skal opne den lokale tenesta di, er det ærlege svaret vanlegvis ein mekanisme bygd for innkomande tilgang. Ein omvendt SSH-tunnel er den minste: maskinen din koplar utgåande til ein vert som kollegaen allereie kan nå, og lyttaren finst på den verten.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Reléet krev GatewayPorts clientspecified i SSH-tenarkonfigurasjonen, elles bind den videresende lyttaren til loopback på reléet, og kollegaen møter same avvising som før. For alt som varer lenger enn ein ettermiddag, er ein lastbalansar eller ingress med helsesjekk og sertifikat for det publiserte namnet det betre verktøyet, og ein tunnel frå stad til stad med ruter for begge subnetta er det rette svaret når to nettverk verkeleg treng å snakke saman.
Kvart av desse designa gjer eksponeringa eksplisitt, og det er poenget. Ein VPN flyttar pakkar mellom nettverk du allereie var autorisert til å bruke; han publiserer ikkje ei teneste og gjer ikkje ein laptop til ein vert vend mot internett. Oppgåva er å avgjere kva av dei tre laga som skal endrast, og tunnelen er sjeldan eitt av dei.