Kodėl jūsų svečio VPN neveikia už VirtualBox NAT?

Naršyklė virtualioje mašinoje veikia, o to paties svečio VPN klientas negali perduoti duomenų. Svečias akivaizdžiai turi ryšį, todėl gedimas yra tame, ko reikalauja išorinis VPN protokolas ir ką praleis virtualus NAT. Rezultatą lemia trys sąlygos: kuris procesas valdo VPN, kaip išoriniai mainai atrodo laidu ir ar adapterio režimas yra tas, apie kurį galvojate. Įvardyti sąlygą, kurią galite pakeisti, yra visas sprendimas.

Raskite VPN procesą prieš kaltindami tinklą

Pirmiausia nuspręskite, ar VPN veikia svečio viduje, ar pagrindiniame kompiuteryje, nes šios dvi sąrangos sugenda skirtingai. Klientas svečio viduje kuria savo išorinį ryšį per svečio adapterį ir bet kokį vertimą už jo. Pagrindinio kompiuterio VPN fiksuoja svečio srautą pagal pagrindinio kompiuterio ir hipervizoriaus politiką, o tai atskiras fiksavimo taškas su savo taisyklėmis. Jie gali veikti vienu metu ir supainioti įrodymus, todėl nustatykite, kuris turėtų perduoti šį srautą, prieš liesdami bet kurį.

Dabar užsirašykite svečio adapterio režimą, prieš ką nors keisdami. Ta viena reikšmė paaiškina didžiąją dalį to, kas bus toliau, ir tai pirmas dalykas, kurio vėliau kas nors jūsų paklaus.

Išoriniai mainai lemia suderinamumą

VirtualBox tinklų vadovas išvardija NAT apribojimus, kurie čia svarbūs: jis nepraleis kitų protokolų nei TCP ir UDP, GRE įvardytas kaip nepalaikomas, o PPTP pateiktas kaip paveiktas pavyzdys. PPTP naudoja TCP valdymo mainus ir GRE duomenims, todėl valdymo ryšys gali pavykti, o duomenų kelias negali peržengti tos pačios ribos. Tai du skirtingi įrodymai, ir tik vienas jų apie srauto perdavimą. Leisti TCP prievadą 47 ugniasienės taisyklėje nėra tas pats, kas leisti IP protokolą 47, ir šie du nuolat painiojami.

Laikykite apribojimą susietą su šia NAT sąranka, o ne su kiekvienu įrenginiu, kuris vartoja žodį NAT. Fizinis maršrutizatorius gali be priekaištų praleisti GRE, o virtualus NAT jį numeta, ir kitas hipervizorius pats pasirenka, ką persiųsti. Kur organizacija siūlo patvirtintą transportą TCP arba UDP viduje, naudokite jos palaikomą klientą ir profilį tam keliui. Suderinamumas yra vienas iš kelių reikalavimų, ir jis nenustato nei serverio pasitikėjimo, nei paskyros leidimo, nei veikiančių privačių maršrutų.

Ką tiltas iš tikrųjų keičia

Tiltas perduoda svečio MAC adresą fiziniam segmentui, o ne slepia jį už vertimo. Tada svečias gauna adresą iš bet kurio DHCP serverio, aptarnaujančio tą segmentą, atsako ARP šiam adresui ir aukštesniam komutatoriui atrodo kaip dar vienas prievadas. Tai pašalina virtualaus vertimo kelią, ir būtent todėl senas receptas jį rekomenduoja, ir tuo pačiu metu pakeičia dar tris dalykus. Adresavimas dabar ateina iš vietinio segmento, o ne iš hipervizoriaus, atskleidimas reiškia, kad svečias matomas tam segmentui, o priėmimas priklauso nuo komutatoriaus prievado ir jo politikos. Kiekvienas iš jų gali būti priežastis atmesti pakeitimą, ir nė vienas nėra apie VPN protokolą.

Tiltinimas neįdiegia trūkstamo papildinio, netiekia neprieinamo slapto agento ir neremontuoja autentifikavimo atmetimo. Jis taip pat nepaverčia pasenusio protokolo geru pasirinkimu, o kur operatorius turi prižiūrimą pakaitalą, sprendimas yra būtent jis, o ne hipervizoriaus keitimas. Prievado persiuntimas yra visiškai trečias vaidmuo: jis paskelbia įeinančią paslaugą ir nieko nedaro išeinančio kliento išoriniam protokolui.

Du tuneliai, du įrodymų pėdsakai

Svečio VPN reikia naudingo kelio nuo svečio sąsajos iki jo partnerio, kol bet koks vidinis adresas ar privatus maršrutas dar nepradeda nieko reikšti. Kur yra pagrindinio kompiuterio VPN, jis gali persiųsti arba blokuoti tuos išorinius mainus pagal savo politiką, o svečio vidinis tunelis prasideda tik po to, kai išorinis pavyksta. Nė vieno sluoksnio aprėptis negali būti nuskaitoma iš vienos prijungtos piktogramos ar pagrindinio kompiuterio naršyklės viešo adreso.

Išsaugokite pirmąjį klaidos pranešimą, o ne paskutinį, nes ankstyviausias gedimas įvardija sluoksnį. Keiskite vieną palaikomą tinklo sąranką vienu metu, su tuo pačiu svečio profiliu ir tais pačiais prisijungimo duomenimis, kad palyginimas ką nors reikštų. Pagal gedimą nuspręskite, kuris etapas lūžo: vietinė integracija, transportas, autentifikavimas ar prieiga prie išteklių po tunelio pakėlimo. Kiekvienas jų turi kitą savininką, ir tik vienas yra hipervizoriaus klausimas.

Kuri sąlyga iš tikrųjų jus stabdo

Dabar sprendimas susiaurėja iki trijų klausimų su skirtingais atsakymais. Jei išorinis protokolas yra už TCP ir UDP ribų, NAT režimas yra apribojimas, o kelias pirmyn yra tiltas arba patvirtintas TCP/UDP transportas. Jei išoriniai mainai baigiasi, o duomenų kelias ne, apribojimas yra tas pats, kuris matomas antrame įrodyme. Jei tunelis pakyla, o ištekliai neatsako, problema jau peržengė hipervizorių į maršrutizavimą ar politiką.

Užrašykite atsakymą su adapterio režimu šalia, kitaip kitas žmogus pakartos tą patį popietę. Po bet kokios pataisos išbandykite tikrąją programą ir vardų sprendimą svečio viduje, tada prisijunkite iš naujo ir išbandykite gedimo politiką. Veikiantis tinklalapis per tunelį įrodo tik tai, kad veikia žiniatinklio kelias, o tai mažesnis teiginys, nei atrodo tuo metu.