General failure ved ping til en LAN-adresse med VPN-klienten slået til
Windows siger, at den slet ikke kan nå en adapter, mens rutetabellen ser korrekt ud. Afgør, om blokeringen er routing, filtrering eller klienten.
Én værtsrute, én adresse, og ping mislykkes med det samme med General failure i stedet for at anmodningen timer ud. Den forskel er hele diagnosen. En timeout betyder, at pakken forlod maskinen, og at noget ignorerede den. General failure betyder, at Windows slet ikke kunne give pakken til nogen grænseflade.
Så når rutetabellen ser perfekt ud, og fejlen stadig er General failure, sker blokeringen under routingbeslutningen, og udbyderens klient er det, der arbejder der.
Læs fejlen før rutetabellen
Windows returnerer den fejl, når den ikke kan finde en grænseflade at sende på, og den siger intet om, hvad destinationen ville have gjort med pakken. Tilgængelighed, firewalls i den fjerne ende og tjenestens tilgængelighed er alle senere spørgsmål, som du endnu ikke er nået til.
Den klassiske konfiguration til dette tilfælde er en værtsrute, der peger en enkelt LAN-adresse mod den fysiske gateway, så den går uden om tunnelen. route add accepterer den, route print viser den, og ping mislykkes stadig, fordi filterdriveren allerede har besluttet, at pakken ikke må komme ud.
Før du accepterer den forklaring, skal du bekræfte, at ruten faktisk bliver valgt: kontroller grænsefladeindekset og metrikken, og sørg for, at posten ikke er forældet efter en genopkobling. En rute, der peger på en grænseflade, som ikke findes længere, giver en lignende fejl af en meget mindre interessant grund.
Tre lag, tre forskellige ejere
Det lag, der vinder, er det, der kører sidst, og disse tre er ikke i den rækkefølge, som de fleste antager.
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
Det midterste lag er grunden til, at en rute kan være både korrekt og ubrugelig på samme tid. Udbyderklienter installerer et filter og firewallregler, så trafik uden for tunnelen bliver droppet, og det er den samme mekanisme, der implementerer deres kill switch. Intet i rutetabellen deltager i den beslutning.
Det tredje lag forklarer en mærkelig rapport, der kommer regelmæssigt: det lokale subnet er utilgængeligt, selv efter klienten er afbrudt. Tjenesten kører stadig, og filteret er stadig installeret, så ikke forbundet er ikke det samme som ikke filtrerende. Afslut klienten i stedet for blot at afbryde den, før du konkluderer noget.
Hvad du skal prøve, i rækkefølge
Begynd med at fjerne de funktioner, der er billige at fjerne og nemme at genskabe. LAN-opdagelse, nogle gange kaldet usynlighed på LAN'et, blokerer trafik til private adresseområder, så maskinen forbliver skjult for sine naboer. Printere, lokale filservere og selve routeren forsvinder bag den kontakt. Trusselsbeskyttelsesfunktioner, der filtrerer DNS, installerer deres egne hooks, og de siges at ødelægge lokal tilgængelighed på stort set samme måde.
Slå begge fra, afslut klienten helt, og test derefter adressen. Den rækkefølge adskiller en funktion, der blokerer trafik, fra en tunnel, der router den forkert, og det tager to minutter i stedet for en eftermiddag med statiske ruter.
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4
Hvis adressen svarer, når funktionerne er slået fra, har du en politikbeslutning snarere end en fejl: vælg mellem at lade funktionen være slået fra, tilføje en undtagelse eller acceptere, at maskinen forbliver usynlig på det lokale netværk.
Brug klientens undtagelsessti, snævert
Når en funktion skal forblive aktiveret, er klientens egen opdelte tunnellering den understøttede udvej. Hold undtagelsen så lille, som kravet tillader, hvilket normalt betyder én værtsadresse til én server eller ét præfiks til et enkelt segment. En regel, der dækker et helt privat område, er et permanent hul, som ingen vil huske at have tilføjet, og som ingen vil turde fjerne.
Bekræft derefter først ved adresse og derefter ved navn. Hvis adressen svarer med et første hop på den fysiske gateway, virker undtagelsen. Hvis navnet stadig fejler, er du flyttet til DNS, fordi tunnelens resolver ikke kender den lokale zone, og ingen routingændring vil lære den det.
Behold ruten eller undtagelsen, ikke begge, plus en note om, hvilken der gør arbejdet. To overlappende mekanismer skjuler hinanden, og den næste person, der fejlretter denne maskine, vil fjerne en af dem og ikke se nogen ændring.
Når klienten er forhindringen
Nogle builds filtrerer trafik på måder, som hverken en statisk rute eller en klientundtagelse kan besejre. Når det er fundet, er de ærlige muligheder at vente på omgåelsesfunktionen eller at forbinde med en almindelig OpenVPN-klient med udbyderens egen profil, hvilket er det, leverandørens supportssvar i den oprindelige rapport anbefalede.
Forstå byttet, før du foretager den udskiftning. En almindelig profil opfører sig som enhver anden tunnel: den installerer sine ruter og omstrukturerer ikke resten af stakken, så en snæver værtsrute opfører sig stadig, som du forventer. Det, du mister, er alt, hvad den branded klient implementerede omkring tunnelen, inklusive kill switch og DNS-filtrering, og det skal genskabes bevidst eller accepteres som fraværende.
Uanset hvad du vælger, skal du notere, hvilket lag der ejede blokeringen. En pakke, der aldrig forlod maskinen, er et filterresultat, og ingen routingændring kan reparere et filter.