Miksi vieras-VPN epäonnistuu VirtualBoxin NATin takana?

Selain virtuaalikoneen sisällä toimii, ja saman vieraan VPN-asiakasohjelma ei pysty kuljettamaan dataa. Vieraalla on selvästi yhteys, joten vika on siinä, mitä VPN:n ulompi protokolla tarvitsee ja mitä virtuaalinen NAT päästää läpi. Kolme ehtoa ratkaisee lopputuloksen: mikä prosessi omistaa VPN:n, miltä ulompi vaihto näyttää johdolla ja onko sovittimen tila se, jota luulet. Sen ehdon nimeäminen, jota voit muuttaa, on koko päätös.

Paikanna VPN-prosessi ennen kuin syytät verkkoa

Ratkaise ensin, ajetaanko VPN:ää vieraan sisällä vai isännässä, koska nämä kaksi järjestelyä epäonnistuvat eri tavoin. Vieraan sisällä oleva asiakasohjelma rakentaa oman ulomman yhteytensä vieraan sovittimen ja sen takana olevan käännöksen kautta. Isännän VPN kaappaa vieraan liikenteen isännän ja hypervisorin käytännön mukaan, mikä on erillinen kaappauspiste omine sääntöineen. Ne voivat toimia yhtä aikaa ja sekoittaa todisteet, joten tunnista se, jonka pitäisi kuljettaa tätä liikennettä, ennen kuin kosket kumpaakaan.

Kirjoita vieraan sovittimen tila ylös nyt, ennen kuin muutat mitään. Tuo yksi arvo selittää suurimman osan siitä, mikä seuraa, ja se on ensimmäinen asia, jonka joku kysyy sinulta myöhemmin.

Ulompi vaihto ratkaisee yhteensopivuuden

VirtualBoxin verkkokäsikirja luettelee NATin rajoituksia, joilla on tässä merkitystä: se ei päästä läpi muita protokollia kuin TCP ja UDP, GRE mainitaan tukemattomaksi ja PPTP annetaan esimerkkinä, johon tämä vaikuttaa. PPTP käyttää TCP-ohjausvaihtoa ja GRE:tä datalle, joten ohjausyhteys voi onnistua, kun taas datapolku ei voi ylittää samaa rajaa. Nämä ovat kaksi eri todistetta, ja vain toinen niistä koskee liikenteen kuljettamista. TCP-portin 47 salliminen palomuurisäännössä ei ole sama kuin IP-protokollan 47 salliminen, ja nämä kaksi sekoitetaan jatkuvasti.

Pidä rajoitus tässä NAT-järjestelyssä eikä jokaisessa laitteessa, joka käyttää sanaa NAT. Fyysinen reititin voi päästää GRE:n läpi valittamatta, kun taas virtuaalinen NAT pudottaa sen, ja toinen hypervisor tekee oman valintansa siitä, mitä välittää. Jos organisaatio tarjoaa hyväksytyn kuljetuksen TCP:n tai UDP:n sisällä, käytä sen tuettua asiakasohjelmaa ja profiilia tuolle polulle. Yhteensopivuus on yksi vaatimus muiden joukossa, eikä se vahvista palvelimen luottamusta, tilin lupaa tai toimivia yksityisiä reittejä.

Mitä sillaus todella muuttaa

Silta antaa vieraan MAC-osoitteen fyysiselle segmentille sen sijaan, että piilottaisi sen käännöksen taakse. Vieras ottaa silloin osoitteen miltä tahansa DHCP-palvelimelta, joka palvelee tuota segmenttiä, vastaa ARP:hen tuolle osoitteelle ja näyttää ylävirran kytkimelle vielä yhdeltä portilta. Tämä poistaa virtuaalisen käännöspolun, mikä on juuri syy siihen, miksi vanha resepti suosittelee sitä, ja se muuttaa kolmea muuta asiaa samalla hetkellä. Osoitteistus tulee nyt paikallisesta segmentistä eikä hypervisorista, paljastuminen tarkoittaa, että vieras on näkyvissä tuolle segmentille, ja hyväksyminen riippuu kytkimen portista ja sen käytännöstä. Jokainen näistä voi olla syy hylätä muutos, eikä mikään niistä koske VPN-protokollaa.

Sillaus ei asenna puuttuvaa liitännäistä, toimita käyttökelvotonta salaista agenttia tai korjaa todennuksen hylkäystä. Se ei myöskään tee vanhentuneesta protokollasta hyvää valintaa, ja kun operaattorilla on ylläpidetty korvaava ratkaisu, päätös on se eikä hypervisorin vaihtaminen. Portin edelleenlähetys on kokonaan kolmas rooli: se julkaisee saapuvan palvelun eikä tee mitään lähtevän asiakasohjelman ulommalle protokollalle.

Kaksi tunnelia, kaksi todistejälkeä

Vieras-VPN tarvitsee käyttökelpoisen polun vieraan rajapinnasta vastapuolelleen ennen kuin millään sisäisellä osoitteella tai yksityisellä reitillä on merkitystä. Jos isännän VPN on läsnä, se voi välittää tai estää tämän ulomman vaihdon oman käytäntönsä mukaisesti, ja vieraan sisempi tunneli alkaa vasta, kun ulompi onnistuu. Minkään kerroksen kattavuutta ei voi lukea yhdestä yhdistetystä kuvakkeesta tai isännän selaimen julkisesta osoitteesta.

Säilytä ensimmäinen virheilmoitus viimeisen sijaan, koska varhaisin epäonnistuminen nimeää kerroksen. Muuta yhtä tuettua verkkojärjestelyä kerrallaan, samalla vierasprofiililla ja samoilla tunnuksilla, jotta vertailu merkitsee jotain. Päätä epäonnistumisesta, mikä vaihe katkesi: paikallinen integrointi, kuljetus, todennus vai resurssien käyttö tunnelin noustua. Jokaisella niistä on eri omistaja, ja vain yksi on hypervisor-kysymys.

Mikä ehto sinua oikeastaan estää

Nyt päätös kaventuu kolmeen eri vastauksin varustettuun kysymykseen. Jos ulompi protokolla on TCP:n ja UDP:n ulkopuolella, NAT-tila on rajoitus, ja eteenpäin vie sillaus tai hyväksytty TCP/UDP-kuljetus. Jos ulompi vaihto valmistuu mutta datapolku ei, rajoitus on sama kuin toisessa todisteessa nähtiin. Jos tunneli nousee eivätkä resurssit vastaa, ongelma on jo ohittanut hypervisorin reititykseen tai käytäntöön.

Kirjoita vastaus muistiin sovittimen tila vieressä, tai seuraava henkilö toistaa saman iltapäivän. Testaa todellinen sovellus ja nimien selvitys vieraan sisällä jokaisen korjauksen jälkeen, yhdistä sitten uudelleen ja kokeile vikatilanteen käytäntöä. Tunnelin läpi toimiva verkkosivu todistaa vain, että verkkopolku toimii, mikä on pienempi väite kuin miltä se sillä hetkellä tuntuu.