VPN aan, VM onbereikbaar? Die roete was waarskynlik nooit die probleem nie

Koppel die VPN, en die ontwikkel-VM wat 'n minuut gelede nog geantwoord het, word skielik stil. Die ooglopende verhaal skryf homself: die tonnel het die roete gegryp, die gasheer stuur nou gasverkeer in die korporatiewe netwerk in, en die oplossing is om 'n statiese roete by te voeg of die adapter na bruggemodus oor te skakel. Daardie verhaal is soms waar. Dit is egter nie die gewone oorsaak nie, en om eerste daarvolgens op te tree, breek gewoonlik iets anders.

Host-only-netwerking is 'n sagtewarenetwerk wat deur die gasheer besit en met sy gaste gedeel word, apart van enige fisiese aansluiting. Niks aan 'n VPN-kliënt se eie koppelvlak verander daardie netwerk nie, so voordat jy daaraan raak, vind uit watter van die vier lae werklik gefaal het.

Die roete is gewoonlik steeds plaaslik

Vra die kern eerder as die voorblad van die roetetabel. Op Linux rapporteer ip route get 192.168.56.10 die presiese roete, koppelvlak en bronadres wat gebruik sou word, wat 'n ander antwoord is as om 'n verstekroete te lees en te raai. As die uitset die host-only-koppelvlak noem, is die tonnel glad nie by daardie pad betrokke nie.

Twee dinge kan dit werklik breek, en albei is adresprobleme eerder as VPN-probleme. 'n Afgeleë subnet wat met die host-only-voorvoegsel oorvleuel, laat die meer spesifieke roete wen, en 'n VPN-kliënt wat 'n breë roete met 'n laer metriek installeer, kan die voorvoegsel wegtrek. Albei is in dieselfde opdrag sigbaar: die koppelvlak wat in die uitset genoem word, sal die tonnel wees, en die oplossing berus by wie ook al daardie adresplan besit.

Roeteseleksie en pakkettoelating is verskillende besluite

Dit is die deel wat die denkmodel gewoonlik mis. Selfs met 'n perfekte plaaslike roete kan 'n VPN-kliënt die pakket weier. Baie kliënte handhaaf 'n plaaslike netwerktoegangsbeleid wat besluit watter bestemmings buite die tonnel toegelaat word, en 'n gekoppelde subnet dateer nie daardie lys outomaties op nie.

Dus lyk die mislukking identies aan 'n roeteringsprobleem van die toepassing se kant, en heeltemal anders van die kliënt se kant. As ip route get die regte koppelvlak noem en die verbinding steeds tyd uitloop, hou op om roetes te redigeer en lees eerder die kliënt se gedokumenteerde plaaslike toegangsgedrag. Sommige kliënte bied 'n toelatingslys vir plaaslike subnette, sommige blokkeer alles wat nie die tonnel is nie, en sommige blokkeer net wanneer 'n kill switch geaktiveer is.

Daardie onderskeid maak saak omdat die oplossings nie uitruilbaar is nie. 'n Roete byvoeg kan nie 'n filter bevredig nie, en om 'n filter te deaktiveer om een gas te bereik, is 'n veel groter besluit as wat die simptoom suggereer.

Die gas het drie maniere om nee te sê

'n Gas wat die internet kan blaai, het niks oor die diens wat jy wil hê bewys nie. Die luisteraar kan binne die gas aan 127.0.0.1 gebind wees, in welke geval geen gasheerverzoek kan aankom nie, maak nie saak hoe goed die pad is nie. Kontroleer met ss -ltn in die gas en kyk na die plaaslike adreskolom eerder as net na die poort.

Volgende is die gas se eie firewall. 'n Ontwikkelbeeld met 'n streng verstek kan die gasheer se pakkette aanvaar en dit by die diensgrens laat val, wat 'n tyduitloop veroorsaak wat presies soos 'n roeteringswartgat lyk. Laastens is daar die diens se eie konfigurasie: 'n webapp wat aan 'n spesifieke gasheernaam gebind is, of 'n toelatingslys van kliëntadresse, sal 'n versoek van die host-only-subnet weier selfs wanneer elke pakket aankom.

Werk deur daardie drie voordat jy dit oorweeg om die VM se netwerkmodus te verander. Elkeen is 'n kleiner verandering as om die gas se aansluiting te herargitekteer, en elkeen het 'n duidelike toets.

Wat 'n brug werklik is, en wat dit kos

Om die adapter na bruggemodus oor te skakel, is nie 'n herstel van die host-only-pad nie. Dit is 'n besluit om die gas op 'n ander netwerk te plaas, gewoonlik die fisiese LAN, waar dit sigbaar word vir alles wat daar woon. Dit mag presies wees wat jy wil hê. Dit is nie wat die oorspronklike konfigurasie gedoen het nie.

Gebruik dit wanneer die gas werklik 'n eweknie op daardie LAN moet wees en die blootstelling goedgekeur is. Moenie dit gebruik omdat een enkele diens opgehou antwoord het nie, want die verandering kan die gas uit die isolasie skuif wat dit veilig gemaak het om teen te ontwikkel.

Na enige goedgekeurde regstelling, toets in 'n vaste volgorde: 'n nuwe gasheer-tot-gas-versoek, 'n vereiste korporatiewe hulpbron deur die tonnel, en die beoogde geweierde gedrag met die tonnel af. As die laaste een nie meer geld nie, het die regstelling verder gegaan as die probleem.

Die VirtualBox afdeling oor host-only-netwerking beskryf die gasheerkant se sagtewarekoppelvlak en hoe dit van 'n brug-aansluiting verskil, wat die verwysing is wat die moeite werd is om te lees voordat jy aanneem die twee modusse is uitruilbaar.