Kāpēc jūsu VPN tuneļa adrese neatver ienākošo portu
Tuneļa adrese identificē jūsu klientu tiem partneriem, kuri var uz to maršrutēt, un nekad neizveido klausītāju. Pārbaudiet piesaisti, atgriešanās maršrutu un tad politiku.
Pieslēdzieties biroja VPN, palaidiet nelielu servisu uz porta 8443, nosūtiet tuneļa adresi kolēģim un vērojiet, kā savienojums neizdodas, kamēr klients joprojām ziņo, ka ir pievienots. Tunelī nekas nav salūzis: adrese ir piešķirta, sesija ir aktīva, un paketes, kas nestu atbildi, vienkārši nekad netiek ielaistas. Veiciet trīs pārbaudes zemāk pēc kārtas un apstājieties pie tās, kura neizdodas, jo katrai ir cits labojums un tikai viena no tām attiecas uz VPN.
Sāciet ar to, kur ligzda patiešām ir piesaistīta
Pirms kaut kas tiek maršrutēts, kaut kam jāklausās adresē, ko zvanītājs var sasniegt. Izstrādes serveri ir ierastais vaininieks, jo daudzi no tiem pēc noklusējuma piesaistās loopback un pieņem tikai savienojumus, kas nāk no tās pašas mašīnas. Tuneļa adrese šo piesaisti nemaina, un operētājsistēma atteiks savienojumu daudz agrāk, nekā VPN vispār tiks iesaistīts.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lasiet vietējās adreses kolonnu, nevis stāvokli. 127.0.0.1:8443 nozīmē tikai loopback, un labojums ir piesaiste 0.0.0.0 vai pašai tuneļa adresei. 0.0.0.0:8443 pieņem visos saskarnēs, kas ir plašāk, nekā vairums cilvēku domā, ja mašīnai ir arī publiska adrese; 10.64.7.15:8443 ir šaurā versija, kas klausās tikai tur, kur kolēģis var tikt. Ievērojiet arī procesa nosaukumu tajā pašā izvadē, jo iepriekšējā testā palikusi lieka instance ir biežs iemesls, kāpēc ports izskatās atvērts un atbild ar nepareizu saturu.
Tad pajautājiet, vai kaut kas var maršrutēt uz šo adresi
Tuneļa adresei ir jēga tikai tiem partneriem, kuri konfigurēti sūtīt šo prefiksu tunelī. Kolēģa mašīnai ir sava tabula, un, ja tai nav maršruta uz tuneļa apakštīklu, pakete dodas uz noklusējuma vārteju un iet bojā vietā, kurai nav ne jausmas, ka adrese pastāv. Tas ir maršrutēšanas jautājums zvanītāja pusē, nevis atļauja jūsu pusē.
| 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 |
Serveris starp abiem klientiem ir tikpat svarīgs. Ierastajā attālinātās piekļuves dizainā katrs klients atver izejošu savienojumu uz vārteju, un vārteja uztur šo plūsmu stāvokli, tāpēc atbildes nāk atpakaļ pa ceļu, ko tā jau zina. Savienojums no viena klienta uz otru ir jauna plūsma, kas vārtejai jāpieņem un jāpārsūta, un daudzas instalācijas to apzināti izslēdz, lai klienti paliktu izolēti viens no otra. Patērētāju VPN pakalpojumi parasti izolē pēc noklusējuma; uzņēmumu vārtejas dažkārt to atļauj pa grupām.
Pārbaudiet virzienu, pirms kaut ko maināt uz saimniekdatora. Ja tuneļa adrese atbild no pašas vārtejas, bet ne no partnera, atšķirība ir vārtejas klienta-uz-klientu iestatījums, un nekāda vietējā ugunsmūra rediģēšana to neaizstās.
Visbeidzot, atrodiet politiku, kas atļauj plūsmu
Trīs politikas slāņi atrodas starp maršrutētu paketi un atbildošu servisu: VPN servera pārsūtīšanas lēmums, saimniekdatora ugunsmūris un jebkura mākoņa drošības grupa instances priekšā. Visiem trim jāsakrīt, un tie neizdodas dažādos veidos, tāpēc simptoms augšējā tabulā ir noderīgāks par kļūdas ziņojumu pārlūkā.
Saimniekdatora ugunsmūris ir slānis, ko cilvēki aizmirst pēc veiksmīgas piesaistes, jo noteikums, kas atļauj portu LAN saskarnē, automātiski neatļauj to tuneļa saskarnē. Saskarnei ierobežoti noteikumi ir pareizs dizains un arī ierastais iemesls servisam, kas strādā no biroja, bet ne no mājām. Lasiet noteikuma tvērumu, nevis tā porta numuru.
Stāvokļa filtrēšana izskaidro pretējo gadījumu. Izejošs savienojums no jūsu portatīvā datora izveido stāvokli, un atbildes uz to tiek ielaistas bez ienākoša noteikuma. Kolēģa savienojums ir pilnīgi jauna plūsma bez stāvokļa aiz tās, tāpēc tai vajag skaidru atļauju. Šī asimetrija ir viss iemesls, kāpēc strādājoša pārlūka sesija jūsu pašu mašīnā neko nepasaka par to, vai serviss ir sasniedzams no ārpuses.
Kad viena pārbaude neizdodas, mainiet dizainu, nevis tuneli
Ja prasība ir, lai kolēģis atvērtu jūsu vietējo servisu, godīgā atbilde parasti ir mehānisms, kas būvēts ienākošai piekļuvei. Apgriezts SSH tunelis ir mazākais: jūsu mašīna izejot savienojas ar saimniekdatoru, kuru kolēģis jau var sasniegt, un klausītājs pastāv tajā saimniekdatorā.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Retranslatoram savā SSH servera konfigurācijā vajag GatewayPorts clientspecified, citādi pārsūtītais klausītājs piesaistās loopback uz retranslatora un kolēģis saskaras ar tādu pašu atteikumu kā iepriekš. Visam, kas ilgst ilgāk par pēcpusdienu, slodzes balansētājs vai ingress ar veselības pārbaudi un sertifikātu publicētajam vārdam ir labāks instruments, un tunelis starp vietnēm ar maršrutiem abiem apakštīkliem ir pareizā atbilde, kad diviem tīkliem tiešām jāsarunājas.
Katrs no šiem dizainiem padara pakļautību skaidru, un tā ir jēga. VPN pārvieto paketes starp tīkliem, kuru lietošanai jūs jau bijāt pilnvarots; tas nepublicē servisu un nepārvērš portatīvo datoru par uz internetu vērstu saimniekdatoru. Uzdevums ir izlemt, kuru no trim slāņiem mainīt, un tunelis reti ir viens no tiem.