Plej multaj malgrandaj retejoj jam havas unu skatolon, kiu faras reton, DHCP kaj la voĉan linion, kaj tiu skatolo ne funkciigos vian retejan tunelon. Aldoni duan pordegon por la privata vojo funkcias, kondiĉe ke vi decidas posedanton de ĉiu vojo antaŭ ol tuŝi kablon. La vera risko ne estas la tunelo; ĝi estas silente ŝanĝi la aparaton, kiu tenas la telefonojn registritaj. Faru la kvin kontrolojn laŭorde kaj haltu kie unu malsukcesas.

Skribu la rolojn, kiuj jam funkcias

Notu la defaŭltan pordegon, la DHCP-servilon, la solvilon kaj la aparaton, kiu tenas la voĉan registradon de la provizanto. En ĉi tiu ekzemplo la ISP-routejo estas 10.50.0.1, la nova pordego estos 10.50.0.2, kaj la fora retejo estas 10.60.0.0/24. Nenio en tiu plano ŝanĝas la unuajn tri rolojn, kaj ĝuste tio estas la punkto. Poste konfirmu, ke la dua skatolo povas vere fini vian tunelon: kontrolu la protokolon, la atendatan trapenetron kaj ĉu ĝi ricevas firmvarajn aŭ pakaĵajn ĝisdatigojn. Aparato kun VPN-signo kaj sen ĝisdatiga vojo estas ŝarĝo, ne aldono.

Se vi ne povas diri, kiu posedas la voĉan servon, haltu. Ŝanĝi la routejon, kiu tenas registradon, sen revena plano igas VPN-projekton telefona paneo.

Donu al la nova pordego unu adreson kaj unu taskon

Rezervu ĝian LAN-adreson ekster la DHCP-pool, por ke ĝi ne moviĝu post restartigo, kaj ne donu al ĝi propran defaŭltan vojon krom se vi volas, ke ĝi fariĝu reta vojo. Ĝia tasko estas teni la tunelon kaj respondi pri foraj prefiksoj. Sur la LAN-gastigantoj, kiuj devas atingi la foran retejon, pruvu, kiun vojon ili nun uzas kaj kiun vi volas post la ŝanĝo; la samaj du komandoj antaŭe kaj poste estas la plej malmultekosta pruvo.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Se la serĉo redonas la ISP-routejon kaj la traceroute mortas ĉe la reta rando, la gastiganto ankoraŭ ne havas foran vojon, kio estas atendata. Se ĝi redonas ion neatenditan, solvu tion unue, ĉar ĉiu posta paŝo supozas ĉi tiun bazon.

Elektu, kiu posedas la vojon de la fora prefikso

Opcio A estas la ISP-routejo: ĝi tenas statikan vojon por 10.60.0.0/24 al la pordego, kaj ĉiu gastiganto sekvas sian defaŭltan pordegon kiel antaŭe. Opcio B estas laŭ gastiganto: nur la maŝinoj, kiuj bezonas la foran retejon, ricevas eksplicitan vojon tra 10.50.0.2, kaj ĉio alia restas netuŝita. A estas pli pura por multaj gastigantoj, sed kutime postulas, ke la routejo de la provizanto akceptu statikan vojon, kion iuj ne faras. B bezonas neniun kunlaboron de la provizanto, sed lasas al vi la prizorgon de la gastiganta agordo, do ĝi taŭgas por malgranda aprobita aro de maŝinoj.

En ambaŭ kazoj la revena direkto devas ekzisti. Se fora respondo alvenas al la pordego kaj la pordego plusendas ĝin rekte al LAN-gastiganto, la trafiko preterpasas la fajroŝtatan staton, kiun la ISP-routejo tenis sur la ekstera vojo. Kiam la pordego ne estas la defaŭlta routejo de la LAN, tiu nesimetrio estas projektdecido, ne eraro ignorebla.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Daŭrigu la entajpon per la agadposedanto de la gastiganta agordo, ne per ensaluta skripto. Vojo, kiu ekzistas nur post ies ensaluto, malsukcesos la unuan fojon, kiam la maŝino restartigos pro senrilata kaŭzo.

Preparu atingeblan envenan finpunkton

La pordego bezonas adreson, kiun la fora retejo povas atingi. Malantaŭ la ISP-routejo tio signifas pordan plusendadon aŭ DMZ-entajpon, kaj ambaŭ dependas de tio, ĉu la provizanto vere liveras la trafikon. Loka plusendado ne venkas operacian NAT ĉe la provizanta flanko. Se la provizanto ne donas atingeblan finpunkton, inversigu la direkton: lasu ambaŭ retejojn iniciatojn al koncentrilo, kiun vi kontrolas. Tio estas valida projektado, sed ĝi aldonas trian dependecon por plusendado, fido kaj havebleco, kaj dinamika DNS ne anstataŭas ĝin.

Konfirmu la plusendadon per kaptaĵo ĉe la pordego, ne per retejo, kiu skanas pordojn. Skaniloj raportas la pordon fermita ĝis la aŭskultanto estas ligita, kaj plusendado, kiu neniam liveras trafikon, aspektas de ekstere same kiel fermita pordo.

Akceptu la privatan servon kaj la voĉan linion kune

Testu la celatan funkcion de LAN-gastiganto, kun privata DNS kaj la propraj akreditaĵoj de la aplikaĵo. Voja tunelo ne igas foran retumadon aspekti kiel loka Ethernet-segmento, do malkovro kaj nomsolvado bezonas proprajn aranĝojn.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Poste konfirmu, ke ordinara reta aliro ankoraŭ funkcias de la sama gastiganto kaj ke la telefonoj ankoraŭ estas registritaj; tiuj du kontroloj kaptas hazardan ŝanĝon de la defaŭlta vojo, la plej oftan manieron, kiel ĉi tiu projekto rompas ion, kion ĝi neniam intencis tuŝi. Finu per skribita restaŭra noto: kiu aparato tenas kiun rolon, la rezervitajn adresojn, kaj kiel forigi la vojon de la fora prefikso en unu paŝo. Privata vojo, kiun oni povas pure retiri, valoras pli ol unu, kiu simple funkcias hodiaŭ.

Rilataj artikoloj