Hvorfor én VPN-ressource virker, og en anden løber tør for tid

Én privat tjeneste indlæses gennem tunnelen, og den næste løber tør for tid, og fristelsen er at genopbygge hele klientprofilen. Den fungerende tjeneste er mere nyttig som kontrol end som grund til at starte forfra. Den beviser, at én destination, én port og én autorisationsvej blev opfyldt, og intet ud over det.

To tjenester på samme gateway kan nås gennem forskellige adressefamilier, forskellige subnets og forskellig politik.

Adskil det fungerende flow fra det fejlende

Behandl hver tjeneste som sit eget flow og ikke som et symptom på VPN'et. En illustrativ klient kan åbne portal.corp.example på 172.20.4.15:443 og stadig ikke nå en database på 172.20.9.40:5432, fordi det er to destinationer med to regelsæt. Skriv begge rækker ned, før du ændrer noget, inklusive porten og protokollen, fordi en regel, der tillader TCP 443 på en vært, intet siger om TCP 5432 på samme vært.

Den fejlende række er den, der skal undersøges. Den fungerende række fortæller kun, hvor baseline ligger, og den bliver sammenligningspunktet efter hver ændring.

Sammenlign adresser, før du sammenligner navne

Opløs hvert fulde navn gennem den politik, applikationen faktisk bruger, og noter derefter den adressefamilie, den valgte. Ét navn kan returnere en IPv6-adresse, mens et andet returnerer IPv4, og et gammelt cachet svar kan sende en anmodning til en offentlig adresse, der intet har at gøre med den private tjeneste.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

Opslaget besvarer et snævert spørgsmål: hvilken rute ville denne vært vælge til den destination, givet de nuværende tabeller og politikregler. En rute til 172.20.4.0/24 dækker ikke 172.20.9.0/24, og en anden netværksmanager eller en lokal rute med bedre specificitet kan stille tilsidesætte tunnelen. Gentag opslaget inde i navnerummet eller med det mærke, applikationen bruger, når de adskiller sig fra din shell. Noter også det interface, pakken forlader igennem, fordi rutetabellen kan navngive ét interface, mens policy routing sender flowet ud gennem et andet.

En rute, der matcher, er en nødvendig betingelse, ikke en tilladelse. Den fortæller, at pakken har et sted at gå hen, og intet om, hvorvidt en firewall, en autorisationstjeneste eller værten selv accepterer den.

Protokol og svarfase fortæller, hvor det stopper

Et ping-svar beviser ikke, at en databaseport er åben, og en vellykket HTTPS-side autoriserer ikke en filshare på samme maskine. Noter, hvad der faktisk kom tilbage, i stedet for at jævne hver fejl til én kategori. En timeout, et reset, en TLS-identitetsfejl og en afvisning på applikationsniveau peger hver på et forskelligt lag.

Forskellen er vigtig, fordi rettelserne går i hver sin retning. Tavshed betyder normalt et rute-, firewall- eller oversættelsesproblem på vejen. Et øjeblikkeligt reset tyder på, at noget nåede værten og afviste porten. En certifikatfejl betyder, at forbindelsen nåede frem, og navnet ikke passede, hvilket er et konfigurationsproblem og ikke et tilgængelighedsproblem. En applikationsafvisning betyder, at netværket gjorde sit arbejde, og identiteten blev afvist bagefter.

Når en ressource offentliggøres gennem en gateway, sammenlign den kildeaddresse, destinationen ser, med den kilde, din klient tror, den bruger. En anmodning, der stammer fra gatewayen selv, kan lykkes, mens den samme anmodning fra en klient fejler, fordi de to kommer fra forskellige adresser og møder forskellige regler.

Ændr én variabel, og kør begge anmodninger igen

Identitet er det sidste sted, folk kigger, og det første sted, en korrekt afvisning dukker op. VPN-login, directory-gruppen og applikationskontoen er tre separate identiteter, der kan divergere. Adgang til en portal betyder aldrig adgang til databasen bag den, og et navn i ét directory opretter ikke en række i et andet. Hvis tjenesten ligger uden for brugerens tilsigtede omfang, er afvisningen systemet, der virker.

Bed ressourceejeren bekræfte den tilsigtede berettigelse i stedet for at tilføje en bred rute eller åbne en gruppe som test. At udvide netværket for at bevise en pointe er måden, hvorpå en midlertidig diagnostik bliver en permanent eksponering, og det ødelægger den kontrol, du startede med. Én påvist uoverensstemmelse per iteration er nok: en manglende rute, en forkert adressefamilie, en blokeret port eller et manglende gruppemedlemskab.

Efter hver ændring gentages begge anmodninger, og outputtet holdes side om side. Undersøgelsen slutter, når den fejlende tjeneste virker under sin egen politik, mens den fungerende tjeneste og de afvisninger, du stadig forventer, opfører sig præcis som før.