Kial nomserĉoj malsukcesas tra enkursigita OpenVPN-tunelo

Gastiganto respondas al ping laŭ adreso kaj malsukcesas ĉe ĉiu serĉo laŭ nomo. La tunelo estas aktiva kaj la itinero ekzistas, do la natura konkludo estas, ke la VPN estas malĝuste agordita. Pli utila konkludo estas, ke la serĉo neniam estis enkursigebla: enkursigita tunelo portas unicast IP, dum la peto estis elsendo serĉanta segmenton, kiu ne ekzistas ĉe la alia flanko. Tuj kiam la tavola malkongruo videblas, la solvoj mem ordiĝas laŭ kosto.

Mito: la tunelo rompiĝis ĉar nomoj malsukcesas

La simptomo konvinkas ĉar ĉio super la noma tavolo funkcias. Adresoj enkursiĝas, la interfaco estas aktiva, kaj la samtavolano respondas al ping. Malsukcesis malkovra mekanismo, kiu neniam havis vojon tra punkt-al-punkta ligilo, kaj tio estas alia aserto ol rompita tunelo. Apartigi tiujn du asertojn estas la plej granda parto de la diagnozo.

Trakti ĝin kiel tunelan misfunkcion kondukas al profilaj ŝanĝoj, kiuj ne povas helpi. Aldoni opciojn, ŝanĝi la ĉifradon aŭ reinstali la klienton lasas la elsendon ĝuste tie, kie ĝi estis.

Nomu la mekanismon, kiu malsukcesis, antaŭ ol nomi la solvon. Serĉo per elsendo bezonas segmenton, dum serĉo per solvilo bezonas adreson por demandi.

Kion TUN portas kaj kion ĝi ne portas

TUN-aparato estas IP-interfaco, kaj ĝuste tio igas ĝin enkursigebla. OpenVPN donas al la kliento adreson kaj aron da itineroj, kaj de tiam la kliento sendas datagramojn al samtavolano. Nenio en tiu modelo kreas komunan ligilon, kie ĉiu gastiganto aŭdas ĉiun kadron.

Malkovra trafiko tute ne taŭgas por tiu modelo. Pli malnovaj Windows-nompetoj, SSDP-anoncoj kaj mDNS-petoj sendiĝas al ĉiuj en segmento anstataŭ al unu celloko. Enkursigita ligilo havas neniun «ĉiujn», al kiu sendi. Ĉiu el tiuj mekanismoj supozas komunan mediumon.

La tunelo do povas esti sana dum malkovro plene malsukcesas. Tiu frazo estas la frazo, kiun oni tenu, kiam iu raportas, ke la VPN estas malaktiva.

Pontado funkcias per forigo de la limo

TAP-aparato portas kadrojn, kaj ponto ligas ĝin al reala LAN-segmento. La kliento tiam havas adreson en tiu segmento kaj aŭdas ĝian elsendan trafikon. Tial pontado ŝajnas kuraci la nomproblemon. Ĝi ankaŭ igas la klienton dependa de tiu segmento por adresado.

La kuracilo estas forigo de la enkursiga limo, ne ia nova noma kapablo ene de la tunelo. Ĉio, kion la segmento elsendas, nun ankaŭ transiras la ligilon.

Por malgranda laboratorio tio estas justa interŝanĝo. Tra disa laborantaro ĝi malofte estas.

Puŝi DNS kaj WINS estas la pli mallarĝa riparo

Donu al la kliento konkretan lokon por demandi. dhcp-option DNS kaj dhcp-option DOMAIN direktas internajn nomojn al servilo, kiu konas la zonon, kaj Windows-kliento, kiu ankoraŭ fidas NetBIOS, povas ricevi WINS-servilon same. La tunelo restas enkursigita kaj la segmento restas, kie ĝi apartenas.

Du kondiĉoj decidas, ĉu tio funkcios. La nomita servilo devas respondi por la zono, kaj la peto devas esti permesata tra la tunelo.

Testu la solvilon de la kliento, ne de la propra ŝelo de la servilo. Solvilo, kiu funkcias loke, diras nenion pri tio, kion la tunelo portas.

Trovu, kiu tavolo malsukcesis

Unue pingu la adreson, poste solvu la nomon kaj legu, kiu servilo respondis. Nea respondo de servilo, kiu ne gastigas la zonon, aspektas alie ol peto, kiu neniam forlasis la maŝinon. Nomo, kiu solviĝas sed rifuzas konektojn, estas tute tria problemo.

Multicast staras malantaŭ la sama muro. Grupo kiel 224.0.0.251 ne estas plusendata tra enkursigita tunelo defaŭlte, kaj itinero por la grupo ne sufiĉas sen multicast-konscia vojo aŭ reflektoro en la LAN.