VPN instalita en Windows, Linux ekŝarĝas sen reto: kion kontroli

Vi instalas VPN en Windows, restartas en Linux, kaj la drata konekto estas morta. La evidenta rakonto skribas sin mem: la VPN lasis ion malantaŭ si. La rakonto malĝustas, ĉar la du ekŝarĝoj uzas apartajn kernojn kun apartaj peliloj, apartaj enkursigaj tabeloj kaj apartaj solviloj. Windows-reta filtro ne plenumiĝas ene de Linux, do la fuŝo kuŝas aŭ en la Linux-stako aŭ en io, kion ambaŭ ekŝarĝoj vere kunhavas, kiel aparataro, firmvaro aŭ la enkursigilo.

La simptomo kaj la malĝusta konkludo

La utila parto de la observado estas la tempo: la fuŝo aperis post ŝanĝo. La senutila parto estas la kaŭza salto al la Windows-VPN, kiu ne povas funkcii en la alia operaciumo. Apartigi la du estas la tuta laboro. Skribu la tempan linion antaŭ ol tuŝi kablon.

Kion la du ekŝarĝoj ja kunhavas, estas la fizika adaptilo, la kablo, la ŝaltila pordo kaj ĉio supre. Tiuj estas veraj komunaj variantoj, kaj ili meritas kontrolon post kiam la Linux-stako estis ekzamenita.

Kaptu la Linux-stakon per kvar komandoj

Komencu nurlege kaj kaptu la staton antaŭ ol ŝanĝi ion: ip -br link por la ĉeesto de interfacoj, ip -br address por adresoj, ip route por IPv4-vojoj kaj ip -6 route kie IPv6 gravas. La referenco de la ilo ip distingas tiujn objektojn, kaj interfaco en la listo ne pruvas, ke ĝi havas funkcian adreson aŭ uzeblan vojon.

Konservu la eligon en dosiero por poste kompari ĝin kun funkcianta ekŝarĝo. Snapero, kiun vi ne povas reprodukti, estas nur memoro pri stato.

Ĉu temas pri ligilo, adreso, vojo aŭ nomo?

Kvar malsamaj fuŝoj aspektas same en la retumilo. La aparato povas tute manki, ĉeesti sen portanto, esti ligita sed sen la atendata adreso, aŭ havi adreson sen vojo al la celo. Malsukceso de nomtraduko dum krudaj adresoj funkcias estas kvina kazo, kaj ĝi apartenas al la solvilo, ne al la pelilo.

Ĉiu kazo montras al alia laboro: pelilo aŭ firmvaro por mankanta aparato, kabligado aŭ ŝaltilo kiam mankas portanto, DHCP aŭ statika agordo por mankanta adreso, kaj enkursigado aŭ politiko por mankanta vojo. Problemo de la solvilo montras al systemd-resolved, NetworkManager aŭ loka DNS-agordo.

Kontrolu, ĉu la Linux-instalaĵo havas propran VPN aŭ daŭran fajroŝirmilan agordon. Loka tunelo aŭ aro de nftables-reguloj estas kaŭzo ĉe la Linux-flanko, kaj multe pli verŝajne klarigas la fuŝon ol Windows-programo, kiu ne funkcias.

Poste komparu la ekŝarĝan transiron

Windows Fast Startup estas hibrida malŝalto, kiu konservas la kernan sesian staton anstataŭ plenumi plenan ekŝarĝon. La dokumentaro de Microsoft pri potencaj statoj distingas ĝin de restartigo kaj de plena malŝalto, kaj tial la sama aparataro povas konduti malsame dum la du transiroj.

Se la fuŝo dependas de transiro de unu operaciumo al la alia, komparu dokumentitan restartigon aŭ plenan malŝalton kun la normala vojo, post konservi vian laboron. Rezulto, kiu sekvas la transiron, pravigas ekzamenon de la stato de pelilo, aparato aŭ firmvaro, kaj ĝi mem ne pruvas, ke Fast Startup kaŭzis difinitan adaptilan fuŝon.

Notu, kiu operaciumo laste uzis la adaptilon, la transiran tipon, la ligan staton en Linux kaj la unuan operacion, kiu malsukcesis. Ripetebla diferenco inter malvarma starto kaj varma transiro valoras multe pli ol forigi VPN-programaron el ambaŭ instalaĵoj sen scii, kiu stako rompiĝis.

Kion ne ŝanĝi

Ne restarigu ambaŭ retajn stakojn kiel unuan paŝon. Tio detruas la komparon kaj ofte riparas nenion, ĉar la vera kaŭzo neniam estis identigita. Ne reinstalu la Windows-VPN por ripari Linux, kaj ne ŝanĝu firmvarajn agordojn hazarde nur ĉar ekŝarĝa transiro korelaciis kun fuŝo.

La referenco de la ilo ip dokumentas la objektojn de ligilo, adreso kaj vojo uzitajn supre. Legu unue la Linux-flankon, konservu la snaperon, kaj nur poste decidos, ĉu la komuna aparatara tavolo meritas esploradon.