Gatewayen hoster sin egen admin-side: indre eller offentlig adresse

En admin-side svarer fra en telefon på mobildata og løber ud fra en bærbar computer, der er tilmeldt VPN'en. Der er intet i vejen med tunnelen, fordi anmodningen aldrig kommer ind i den. Værtsnavnet opløses til gatewayens offentlige adresse, og den adresse kan kun nås udefra den tunnel, den afslutter. At rette det betyder at give tjenesten en privat indgang i stedet for at flytte det ydre endepunkt rundt.

Siden indlæses udefra og ikke gennem tunnelen

Der sammenlignes to forskellige anmodninger. Fra mobildata når browseren den offentlige adresse direkte. Inde fra tunnelen opløses det samme navn til den samme offentlige adresse, og pakken skal nu forlade tunnelen for at nå en adresse på tunnelens egen fjerne side. Samme navn, samme adresse, to meget forskellige positioner.

En destinationsrute vælger en adresse, ikke en port. Intet i routingtabellen ved, at port 443 er til administration, og port 1194 er transporten, så begge behandles som samme destination.

Det er derfor, siden nogle gange virker og nogle gange ikke, afhængigt af hvilket navn og hvilket netværk klienten brugte. Det er et ruteproblem snarere end et autentificeringsproblem. Begge klienter autentificerer udmærket.

Hold det ydre endepunkt tilgængeligt

Fuldtunnelprofiler har brug for en undtagelsesrute til VPN-endepunktet, og OpenVPN's redirect-gateway-indstilling dokumenterer præcis det: det fjerne endepunkt beholder en rute gennem den eksisterende gateway, så tunnelen ikke router ind i sig selv. Fjern undtagelsen, og den krypterede transport følger tunnelen, hvilket afslutter sessionen i en løkke. Undtagelsen er grunden til, at endepunktets adresse forbliver tilgængelig indefra tunnelen.

Konsekvensen er, at den offentlige adresse forbliver tilgængelig fra klienten, hvilket også er grunden til, at en browseranmodning til den adresse kan følge samme undtagelse og forlade uden at gå ind i tunnelen. Undtagelsen gør sit arbejde, og navnet gør skaden.

Læs rutningsbeslutningen i stedet for grænsefladelisten, før du ændrer noget. Kommandoerne nedenfor udskriver beslutningen i stedet for inventaret. Kør dem fra den klient, der fejlede.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Hvis opslaget viser endepunktets rute gennem den fysiske gateway, er adfærden korrekt, og admin-siden sendes blot ad den forkerte vej. Det er det punkt, hvor navneopløsning bliver løsningen.

Giv tjenesten et privat navn

Tjenesten har brug for et navn, der opløses til gatewayens adresse inde i tunnelen, samtidig med at den certifikat- og værtsnavnssemantik bevares, som applikationen forventer. En privat zone-post for administrationsnavnet er det sædvanlige svar, og den lader transportnavnet være urørt.

Omdiriger ikke transportnavnet til den indre adresse, fordi den næste tunneloprettelse så ville forsøge at nå en adresse, der kun findes inde i en tunnel. Den fejl giver en VPN, der virker præcis én gang.

Kontroller også begge adressefamilier, fordi en efterladt AAAA-post kan sende browseren et sted hen, som den private plan aldrig dækkede.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Tilpas politikken til hvor processen kører

En indbygget proces, der lytter på gatewayen, nås via den lokale indgangsvej, så indgangskæden og socket-bindingen afgør, om anmodningen accepteres. Videresendelsesregler og IP-videresendelse får ikke en lokal lytter til at svare. Tillad tunnelens kilder i indgangspolitikken, og bekræft at processen er bundet til en adresse, som tunnelen kan nå.

En container, der er udgivet på en værtsport, følger en anden vej, fordi pakken destinationsoversættes og videresendes. Den anmodning møder værtens videresendelsespolitik og Dockers egne regler, og derfor kan en fungerende indbygget lytter sameksistere med en container, der afviser samme port.

Startrækkefølgen betyder noget i begge tilfælde, fordi en binding til en adresse, der først dukker op, når tunnelen kommer op, fejler lydløst ved opstart.

Kontroller privat adgang og en afvist offentlig vej

Lav en frisk navngivet anmodning fra en autoriseret klient med applikationens egne identitetskontroller intakte. Prøv derefter den samme tjeneste udefra tunnelen, og bekræft at den ikke svarer. Et privat navn er en bekvemmelighed snarere end en begrænsning, og en lytter, der stadig er bundet til den offentlige adresse, er stadig eksponeret. Den sidste kontrol er den, de fleste gennemgange springer over.

Læs bindingerne og filtertilstanden i stedet for det værtsnavn, brugerne fik. Eksponering er en egenskab ved socketen snarere end ved navnet. Den forskel overlever enhver DNS-ændring.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Når den indre anmodning returnerer siden, og den ydre anmodning løber ud, har tjenesten én bevidst privat vej, og transporten forbliver tilgængelig. Når den ydre anmodning stadig svarer, skal lytteren eller en udgivet containerpost indsnævres, før nogen beskriver tjenesten som kun intern.