General failure la ping către o adresă LAN cu clientul VPN activ
Windows spune că nu poate ajunge deloc la niciun adaptor, deși tabela de rutare pare corectă. Decideți dacă blocajul este de la rutare, de la filtrare sau de la client.
O rută de host, o adresă, iar pingul eșuează imediat cu General failure în loc ca cererea să expire. Această distincție este întregul diagnostic. O expirare înseamnă că pachetul a plecat și ceva l-a ignorat. General failure înseamnă că Windows nu a putut preda pachetul niciunei interfețe de la bun început.
Așadar, când tabela de rutare pare perfectă și eroarea este încă General failure, blocajul are loc sub decizia de rutare, iar clientul furnizorului este ceea ce operează acolo.
Citiți eroarea înaintea tabelei de rutare
Windows returnează acea eroare când nu găsește o interfață pe care să trimită și nu spune nimic despre ce ar fi făcut destinația cu pachetul. Accesibilitatea, firewall-urile de la celălalt capăt și disponibilitatea serviciului sunt toate întrebări ulterioare la care încă nu ați ajuns.
Configurația clasică pentru acest caz este o rută de host care direcționează o singură adresă LAN către gateway-ul fizic, ca să ocolească tunelul. route add o acceptă, route print o afișează, iar pingul tot eșuează, pentru că driverul de filtrare a decis deja că pachetul nu are voie să iasă.
Înainte de a accepta această explicație, confirmați că ruta este într-adevăr selectată: verificați indexul interfeței și metrica și asigurați-vă că intrarea nu este învechită după o reconectare. O rută care indică o interfață care nu mai există produce o eroare similară dintr-un motiv mult mai puțin interesant.
Trei straturi, trei proprietari diferiți
Câștigă stratul care rulează ultimul, iar aceste trei nu sunt în ordinea pe care majoritatea o presupune.
| 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 |
Stratul din mijloc este motivul pentru care o rută poate fi simultan corectă și inutilă. Clienții furnizorilor instalează un filtru și reguli de firewall ca traficul din afara tunelului să fie aruncat, iar acesta este același mecanism care implementează kill switch-ul lor. Nimic din tabela de rutare nu participă la acea decizie.
Al treilea strat explică un raport ciudat care apare regulat: subrețeaua locală este inaccesibilă chiar și după deconectarea clientului. Serviciul încă rulează, iar filtrul încă este instalat, așa că a nu fi conectat nu este același lucru cu a nu filtra. Ieșiți din client în loc să îl deconectați doar, înainte de a trage vreo concluzie.
Ce să încercați, în ordine
Începeți prin a elimina funcțiile care sunt ieftine de eliminat și ușor de restabilit. Descoperirea LAN, numită uneori invizibilitate în LAN, blochează traficul către intervalele de adrese private ca aparatul să rămână ascuns de vecini. Imprimantele, serverele de fișiere locale și routerul însuși dispar în spatele acelui comutator. Funcțiile de protecție împotriva amenințărilor care filtrează DNS își instalează propriile cârlige și se raportează că strică accesibilitatea locală aproape în același fel.
Dezactivați-le pe amândouă, ieșiți complet din client, apoi testați adresa. Acea secvență separă o funcție care blochează traficul de un tunel care îl rutează greșit și durează două minute în loc de o după-amiază cu rute statice.
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4
Dacă adresa răspunde după ce funcțiile sunt oprite, aveți o decizie de politică, nu o defecțiune: alegeți între a lăsa funcția oprită, a adăuga o excepție sau a accepta că aparatul rămâne invizibil în rețeaua locală.
Folosiți calea de excepție a clientului, îngust
Când o funcție trebuie să rămână activă, tunelarea divizată proprie a clientului este ieșirea acceptată. Păstrați excepția cât de mică permite cerința, ceea ce înseamnă de obicei o adresă de host pentru un server sau un prefix pentru un singur segment. O regulă care acoperă un întreg interval privat este o gaură permanentă pe care nimeni nu își va aminti că a adăugat-o și pe care nimeni nu va îndrăzni să o elimine.
Apoi verificați mai întâi după adresă și apoi după nume. Dacă adresa răspunde cu un prim salt pe gateway-ul fizic, excepția funcționează. Dacă numele încă eșuează, ați trecut la DNS, pentru că resolverul tunelului nu cunoaște zona locală și nicio modificare de rutare nu îl va învăța.
Păstrați ruta sau excepția, nu ambele, plus o notă despre care face treaba. Două mecanisme suprapuse se ascund reciproc, iar următoarea persoană care va depana acest aparat va elimina unul dintre ele și nu va vedea nicio schimbare.
Când clientul este obstacolul
Unele build-uri filtrează traficul în moduri pe care nici o rută statică, nici o excepție a clientului nu le pot învinge. Când aceasta este constatarea, opțiunile oneste sunt să așteptați funcția de ocolire sau să vă conectați cu un client OpenVPN simplu folosind profilul furnizorului însuși, ceea ce recomanda și răspunsul asistenței producătorului din raportul original.
Înțelegeți compromisul înainte de a face acea substituire. Un profil simplu se comportă ca orice tunel obișnuit: își instalează rutele și nu restructurează restul stivei, așa că o rută îngustă de host se comportă în continuare așa cum vă așteptați. Ce pierdeți este tot ce clientul de marcă a implementat în jurul tunelului, inclusiv kill switch-ul și filtrarea DNS, iar acelea trebuie reproduse intenționat sau acceptate ca absente.
Orice ați alege, notați ce strat deținea blocajul. Un pachet care nu a părăsit niciodată aparatul este rezultatul unui filtru, iar nicio modificare de rutare nu poate repara un filtru.