VPN ŝaltita, VM neatingebla? La vojo probable neniam estis la problemo

Konektu la VPN, kaj la evoluiga VM, kiu antaŭ unu minuto ankoraŭ respondis, subite silentas. La evidenta rakonto skribas sin mem: la tunelo prenis la vojon, la gastiganto nun sendas la gastan trafikon en la firmaan reton, kaj la solvo estas aldoni statikan vojon aŭ ŝanĝi la adaptilon al ponto-reĝimo. Tiu rakonto kelkfoje veras. Sed ĝi ne estas la kutima kaŭzo, kaj agi laŭ ĝi unue kutime rompas ion alian.

Host-only retado estas programara reto posedata de la gastiganto kaj dividata kun ĝiaj gastoj, aparta de ajna fizika konekto. Nenio en la propra interfaco de VPN-kliento ŝanĝas tiun reton, do antaŭ ol tuŝi ĝin, eltrovu, kiu el la kvar tavoloj vere fiaskis.

La vojo kutime restas loka

Demandu la kernon anstataŭ la unuan paĝon de la enkursiga tabelo. En Linux, ip route get 192.168.56.10 raportas la ĝustan vojon, interfacon kaj fontadreson, kiuj estus uzataj, kio estas malsama respondo ol legi implicitan vojon kaj diveni. Se la eligo nomas la host-only interfacon, la tunelo tute ne partoprenas en tiu vojo.

Du aferoj povas vere rompi ĝin, kaj ambaŭ estas adresaj problemoj, ne VPN-problemoj. Fora subreto, kiu interkovras la host-only prefikson, igas la pli specifan vojon venki, kaj VPN-kliento, kiu instalas larĝan vojon kun pli malalta metriko, povas forpreni la prefikson. Ambaŭ videblas en la sama komando: la interfaco nomita en la eligo estos la tunelo, kaj la korekto apartenas al tiu, kiu posedas tiun adresplanon.

Vojoselekto kaj paketa akcepto estas malsamaj decidoj

Tio estas la parto, kiun la mensa modelo kutime maltrafas. Eĉ kun perfekta loka vojo, VPN-kliento povas rifuzi la paketon. Multaj klientoj aplikas lokan retalirpolitikon, kiu decidas, kiuj celoj estas permesataj ekster la tunelo, kaj konektita subreto ne aŭtomate ĝisdatigas tiun liston.

Do la fiasko aspektas idente al enkursiga problemo de la aplikacia flanko, kaj tute malsame de la klienta flanko. Se ip route get nomas la ĝustan interfacon kaj la konekto ankoraŭ tempas for, ĉesu redakti vojojn kaj anstataŭe legu la dokumentitan lokan alir-konduton de la kliento. Kelkaj klientoj montras permesliston por lokaj subretoj, kelkaj blokas ĉion, kio ne estas la tunelo, kaj kelkaj blokas nur kiam mortigŝaltilo estas ŝaltita.

Tiu distingo gravas, ĉar la korektoj ne estas interŝanĝeblaj. Aldoni vojon ne povas kontentigi filtrilon, kaj malŝalti filtrilon por atingi unu gaston estas multe pli granda decido ol la simptomo sugestas.

La gasto havas tri manierojn diri ne

Gasto, kiu povas retumi, pruvis nenion pri la servo, kiun vi volas. La aŭskultanto povas esti ligita al 127.0.0.1 ene de la gasto, kaj tiam neniu peto de la gastiganto povas alveni, kiel ajn bona estas la vojo. Kontrolu per ss -ltn en la gasto kaj rigardu la kolumnon de la loka adreso, ne nur la pordon.

Sekva estas la propra fajroŝirmilo de la gasto. Evoluiga bildo kun restrikta implicita agordo povas akcepti la paketojn de la gastiganto kaj forĵeti ilin ĉe la serva limo, kio kreas tempolimon, kiu aspektas ĝuste kiel enkursiga nigra truo. Fine estas la propra agordo de la servo: reteja aplikaĵo ligita al specifa gastigantnomo, aŭ permeslisto de klientaj adresoj, rifuzos peton el la host-only subreto eĉ kiam ĉiu paketo alvenas.

Trarigardu tiujn tri antaŭ ol pripensi ŝanĝi la retan reĝimon de la VM. Ĉiu estas pli malgranda ŝanĝo ol rearkitekturi la konekton de la gasto, kaj ĉiu havas klaran teston.

Kio ponto vere estas, kaj kiom ĝi kostas

Ŝanĝi la adaptilon al ponto-reĝimo ne estas riparo de la host-only vojo. Ĝi estas decido meti la gaston en alian reton, kutime la fizikan LAN, kie ĝi fariĝas videbla al ĉio alia, kio loĝas tie. Tio povas esti ĝuste tio, kion vi volas. Sed ĝi ne estas tio, kion faris la originala agordo.

Uzu ĝin, kiam la gasto vere devas esti samtavolano en tiu LAN kaj la elmeto estas aprobita. Ne uzu ĝin ĉar unu sola servo ĉesis respondi, ĉar la ŝanĝo povas movi la gaston el la izoliteco, kiu igis ĝin sekura por evoluigo.

Post ajna aprobita korekto, testu en fiksa ordo: nova peto de gastiganto al gasto, bezonata firmaa rimedo tra la tunelo, kaj la celita rifuzita konduto kun la tunelo mallevita. Se la lasta jam ne validas, la korekto iris preter la problemo.

La VirtualBox-seccio pri host-only retado priskribas la programaran interfacon ĉe la gastiganta flanko kaj kiel ĝi diferencas de pontal konekto, kio estas la referenco inda legi antaŭ ol supozi, ke la du reĝimoj estas interŝanĝeblaj.