Varför en VPN-resurs fungerar och en annan får tidsgräns

En privat tjänst laddas genom tunneln och nästa får tidsgräns, och frestelsen är att bygga om hela klientprofilen. Den fungerande tjänsten är mer användbar som kontroll än som skäl att börja om. Den bevisar att en destination, en port och en auktoriseringsväg uppfylldes, och inget därutöver.

Två tjänster på samma gateway kan nås via olika adressfamiljer, olika subnät och olika policy.

Skilj det fungerande flödet från det misslyckade

Behandla varje tjänst som sitt eget flöde och inte som ett symptom på VPN:en. En illustrativ klient kan öppna portal.corp.example på 172.20.4.15:443 och ändå inte nå en databas på 172.20.9.40:5432, eftersom det är två destinationer med två regeluppsättningar. Skriv ner båda raderna innan du ändrar något, inklusive porten och protokollet, eftersom en regel som tillåter TCP 443 på en värd inte säger något om TCP 5432 på samma värd.

Den misslyckade raden är den som ska undersökas. Den fungerande raden säger bara var baslinjen ligger, och den blir jämförelsepunkten efter varje ändring.

Jämför adresser innan du jämför namn

Lös upp varje fullständigt namn genom den policy som applikationen faktiskt använder och notera sedan den adressfamilj den valde. Ett namn kan returnera en IPv6-adress medan ett annat returnerar IPv4, och ett gammalt cachelagrat svar kan skicka en förfrågan till en offentlig adress som inte har något med den privata tjänsten att göra.

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

Uppslaget svarar på en smal fråga: vilken rutt skulle den här värden välja för den destinationen, givet nuvarande tabeller och policyregler. En rutt för 172.20.4.0/24 täcker inte 172.20.9.0/24, och en andra nätverkshanterare eller en lokal rutt med bättre specificitet kan tyst åsidosätta tunneln. Upprepa uppslaget inne i namnutrymmet eller med det märke applikationen använder när de skiljer sig från ditt skal. Notera också det gränssnitt paketet lämnar genom, eftersom rutttabellen kan namnge ett gränssnitt medan policy-baserad routing skickar flödet ut genom ett annat.

En rutt som matchar är ett nödvändigt villkor, inte ett tillstånd. Den säger att paketet har någonstans att ta vägen och ingenting om huruvida en brandvägg, en auktoriseringstjänst eller värden själv accepterar det.

Protokoll och svarsfas berättar var det stannar

Ett ping-svar bevisar inte att en databasport är öppen, och en lyckad HTTPS-sida auktoriserar inte fildelning på samma maskin. Notera vad som faktiskt kom tillbaka i stället för att jämna ut varje fel i en kategori. En tidsgräns, en återställning, ett TLS-identitetsfel och en avvisning på applikationsnivå pekar var och en på ett annat lager.

Skillnaden är viktig eftersom rättelserna går isär. Tystnad betyder oftast ett rutt-, brandväggs- eller översättningsproblem på vägen. En omedelbar återställning tyder på att något nådde värden och nekade porten. Ett certifikatfel betyder att anslutningen kom fram och namnet inte matchade, vilket är ett konfigurationsproblem och inte ett nåbarhetsproblem. En applikationsavvisning betyder att nätverket gjorde sitt jobb och identiteten avvisades efteråt.

När en resurs publiceras genom en gateway, jämför källadressen som destinationen ser med den källa som din klient tror att den använder. En förfrågan som kommer från gatewayen själv kan lyckas medan samma förfrågan från en klient misslyckas, eftersom de två kommer från olika adresser och möter olika regler.

Ändra en variabel och kör båda förfrågningarna igen

Identitet är den sista platsen folk tittar på och den första där en korrekt avvisning dyker upp. VPN-inloggningen, kataloggruppen och applikationskontot är tre separata identiteter som kan gå isär. Åtkomst till en portal innebär aldrig åtkomst till databasen bakom den, och ett namn i en katalog skapar inte en rad i en annan. Om tjänsten ligger utanför användarens avsedda omfattning är avvisningen systemet som fungerar.

Be resursägaren bekräfta den avsedda rättigheten i stället för att lägga till en bred rutt eller öppna en grupp som test. Att vidga nätverket för att bevisa en poäng är hur en tillfällig diagnostik blir en permanent exponering, och det förstör kontrollen du började med. En påvisad avvikelse per iteration räcker: en saknad rutt, en felaktig adressfamilj, en blockerad port eller ett saknat gruppmedlemskap.

Efter varje ändring upprepas båda förfrågningarna och utdata hålls sida vid sida. Undersökningen slutar när den misslyckade tjänsten fungerar under sin egen policy, medan den fungerande tjänsten och de avvisningar du fortfarande förväntar dig beter sig exakt som tidigare.