Enkursigilo en VPN-klienta reĝimo: kial LAN-aparatoj malaperas
LAN-aparatoj malaperas post kiam enkursigilo eniras VPN-klientan reĝimon: unue testu la inspektan funkcion en la plusendvojo, poste la LAN-gamuton kiun la firmaro ŝanĝis sub vi.
Kredi ke la klienta reĝimo mem mortigas LAN-aliradon kondukas homojn al la malĝusta agordmenuo, kaj la veraj kaŭzoj kutime estas du. La tunelo ne forigas la LAN-ponton nek malhelpas dratajn kaj sendratajn klientojn atingi unu la alian. Tio, kio rompas lokan aliradon, estas aŭ inspekta funkcio en la plusendvojo de la enkursigilo aŭ LAN-adresgamuto kiu moviĝis kiam la firmaro faris tion. Ambaŭ produktas la saman plendon, kaj nek unu estas riparita per reinstalo de la VPN-profilo.
La mito, kaj kion la klienta reĝimo vere ŝanĝas
La klienta reĝimo aldonas tunelan interfacon kaj defaŭltan itineron kiu trairas ĝin, kaj poste plusendas LAN-trafikon en tiun tunelon. La ponto inter la drataj havenoj kaj la sendrataj radiaj unuoj restas netuŝita, same kiel loka ŝaltado. Kio ŝanĝiĝas estas politiko: kiu trafiko estas plusendata, kie ĝi estas tradukata kaj kiun solvilon la klientoj ricevas.
Tiu distingo gravas ĉar rompita LAN kutime signifas ke unu el tiuj tri politikoj ŝanĝiĝis, ne ke la enkursigilo ĉesis esti ŝaltilo. Enkursigilo kiu ankoraŭ respondas sian propran administran paĝon pruvas ke la LAN-interfaco vivas. Enkursigilo kiu respondas tute nenion havas alian problemon, kiel ŝanĝitan LAN-adreson aŭ klienton en la malĝusta subreto.
Do la utila unua paŝo estas trovi kiun tavolon rompiĝis, ne ŝanĝi la tavolon kiun vi suspektas.
Testu tri celojn antaŭ ol tuŝi agordon
De drata kliento, testu tri celojn aparte kaj notu ĉiun rezulton: la propran LAN-adreson de la enkursigilo, alian aparaton sur la sama ŝaltilo per IP, kaj ion atingeblan nur tra la tunelo. Faru ilin en tiu ordo, ĉar ĉiu rezulto ekskludas alian tavolon. Uzu adresojn anstataŭ nomojn en la unua raŭndo, ĉar nomfiasko miksas DNS en konektecan demandon.
La ŝablono de respondoj estas la diagnozo. Enkursigilo kiu respondas dum lokaj aparatoj ne respondas montras lokan ŝaltadon aŭ filtradan funkcion anstataŭ enkursigadon. Lokaj aparatoj kiuj respondas dum la tunela flanko ne respondas montras la tunelan itineron aŭ la malproksiman fajroŝirmilon. Ĉio respondanta per adreso dum nomoj fiaskas estas solvila demando, kaj neniu itinredaktado riparos ĝin.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Tenu la tabelon apud la testrezultoj. Ĝi transformas vagan plendon en unu linion pri kiu vi povas agi.
La sekureca tavolo ene de la plusendvojo
Konsumantaj enkursigiloj pli kaj pli venas kun inspekta funkcio kiu observas plusendatan trafikon, kaj ĝi funkcias en la sama vojo kiu portas pakaĵojn de LAN al la tunelo. Kiam tiu inspektado ne povas klasifiki la tunelan trafikon, plusendado povas halti dum la tunelo mem restas supre kaj la enkursigilo raportas sanan konekton. Nenio en la VPN-protokolo montras tion, ĉar la VPN ja konektiĝis.
La diagnozo estas kontrolata eksperimento, ne permanenta ŝanĝo. Notu la nunan agordon, malŝaltu la funkcion por la daŭro de unu testo, restarigu la tunelon kaj testu ununuran lokan gastiganton per adreso. Plusendado kiu revenas estas la pruvo kiun vi bezonis, kaj la kompromiso tiam fariĝas decido anstataŭ konjekto. Se nenio ŝanĝiĝas, reŝaltu ĝin tuj kaj transiru al la adresada kaŭzo.
Lasi pagitan sekurecan funkcion malŝaltita por ke tunelo daŭre funkciu estas kompromiso farota konscie kaj skribote. Ankaŭ indas demandi ĉu la tunelo apartenas al alia aparato, ĉar enkursigilo kiu devas inspekti ĉion kaj enkursigilo kiu devas plusendi ĉion estas du malsamaj taskoj.
La dua kaŭzo: la LAN-gamuto moviĝis
Firmaraj ĝisdatigoj rutine restarigas la LAN-adreson al la fabrikanto-defaŭlto, kaj iuj enkursigiloj havas eksplicitan reĝiman ŝaltilon kiu decidas ĉu la LAN konservas privatan gamuton aŭ heredas unu de la supra aparato. Kliento kiu atendas 192.168.8.x povas fini sur 10.64.0.x, kaj tiam SSH-sesio al gastiganto finiĝas kvankam la tunelo estas tute sana.
ipconfig /all
ip addr show
ip route get 192.168.8.20Legu la prefikson kaj la enirejon el la luo antaŭ ol malfermi la enkursigilan paĝon. La unuaj du komandoj montras kion la kliento efektive ricevis, kaj la tria montras kiun interfacon la kliento uzus por loka adreso, kaj tiel malkaŝiĝas restinta itineron aŭ malaktuala subreto. Poste komparu tion kun la LAN-paĝo kaj la reĝimo en kiu la enkursigilo estas.
Se la gamuto ne povas reveni, ĝisdatigu ĉiun objekton kiu nomas ĝin: DHCP-rezervojn, ajnan statikan itineron en la malnovan subreton kaj ĉiun fajroŝirmilan regulon kiu portas la antaŭan prefikson. Gamuto kiu kolizias kun la malproksima subreto de la tunelo estas la pli malbona varianto, ĉar lokaj aparatoj restas atingeblaj dum malproksimaj celoj silente misdirektiĝas en la LAN.
Rekonektiĝu kaj retestu laŭ paka ordo
Post ajna el la du ŝanĝoj, rekonektu la tunelon kaj ripetu la testojn laŭ paka ordo: enkursigilo, loka gastiganto, malproksima gastiganto, poste nomoj, poste la aplikaĵo. Testi la aplikaĵon unue kaŝas kiun tavolon ankoraŭ rompiĝas, kaj reto de retumilo kontraŭ kaŝmemorita nomo povas aspekti kiel enkursiga fiasko.
Notu la firmaran version, la LAN-prefikson kaj la staton de la inspekta funkcio apud la VPN-profilo. Ĉiuj tri estas agordo kiun la sekva ĝisdatigo povas superskribi, kaj du linioj da notoj ŝparas la horon kiun vi ĵus pasigis.