Gatewayen er vert for sin egen admin-side: indre eller offentlig adresse

En admin-side svarer fra en telefon på mobildata og timer ut fra en bærbar datamaskin som er koblet til VPN-en. Ingenting er i stykker i tunnelen, fordi forespørselen aldri kommer inn i den. Vertsnavnet løses til gatewayens offentlige adresse, og den adressen er bare tilgjengelig fra utsiden av tunnelen den avslutter. Å rette dette betyr å gi tjenesten en privat inngang i stedet for å flytte det ytre endepunktet rundt.

Siden lastes fra utsiden og ikke gjennom tunnelen

Det sammenlignes to forskjellige forespørsler. Fra mobildata når nettleseren den offentlige adressen direkte. Fra innsiden av tunnelen løses det samme navnet til den samme offentlige adressen, og pakken må nå forlate tunnelen for å nå en adresse på tunnelens egen fjerne side. Samme navn, samme adresse, to svært forskjellige posisjoner.

En destinasjonsrute velger en adresse, ikke en port. Ingenting i rutetabellen vet at port 443 er for administrasjon og port 1194 er transporten, så begge behandles som samme destinasjon.

Det er derfor siden noen ganger virker og noen ganger ikke, avhengig av hvilket navn og hvilket nettverk klienten brukte. Det er et ruteproblem og ikke et autentiseringsproblem. Begge klientene autentiserer helt fint.

Hold det ytre endepunktet tilgjengelig

Fulltunnelprofiler trenger en unntaksrute for VPN-endepunktet, og OpenVPNs redirect-gateway-alternativ dokumenterer nettopp det: det eksterne endepunktet beholder en rute gjennom den allerede eksisterende gatewayen, slik at tunnelen ikke ruter inn i seg selv. Fjern det unntaket, og den krypterte transporten følger tunnelen, noe som avslutter økten i en løkke. Det unntaket er grunnen til at endepunktadressen forblir tilgjengelig fra innsiden av tunnelen.

Konsekvensen er at den offentlige adressen forblir tilgjengelig fra klienten, og det er også grunnen til at en nettleserforespørsel til den adressen kan følge det samme unntaket og gå ut uten å gå inn i tunnelen. Unntaket gjør jobben sin, og navnet gjør skaden.

Les ruteavgjørelsen i stedet for grensesnittlisten før du endrer noe. Kommandoene nedenfor skriver ut avgjørelsen i stedet for inventaret. Kjør dem fra klienten som feilet.

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

Hvis oppslaget viser endepunktets rute gjennom den fysiske gatewayen, er oppførselen korrekt, og admin-siden blir bare sendt ned feil sti. Det er punktet der navneoppslag blir rettelsen.

Gi tjenesten et privat navn

Tjenesten trenger et navn som løses til gatewayens adresse inne i tunnelen, samtidig som sertifikat- og vertsnavnsemantikken applikasjonen forventer beholdes. En privat sonepost for administrasjonsnavnet er det vanlige svaret, og den lar transportnavnet være urørt.

Ikke pek transportnavnet om til den indre adressen, fordi den neste tunnelopprettelsen da ville prøve å nå en adresse som bare finnes inne i en tunnel. Den feilen gir en VPN som virker nøyaktig én gang.

Sjekk også begge adressefamiliene, fordi en AAAA-post som blir liggende igjen kan sende nettleseren et sted den private planen aldri dekket.

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/

Tilpass policyen til hvor prosessen kjører

En innebygd prosess som lytter på gatewayen nås via den lokale inngangsstien, så inngangskjeden og socket-bindingen avgjør om forespørselen godtas. Videresendingsregler og IP-videresending får ikke en lokal lytter til å svare. Tillat tunnelens kilder i inngangspolicyen, og bekreft at prosessen er bundet til en adresse tunnelen kan nå.

En container som er publisert på en vertsport, følger en annen sti, fordi pakken destinasjonsoversettes og videresendes. Den forespørselen møter vertens videresendingspolicy og Dockers egne regler, og derfor kan en fungerende innebygd lytter sameksistere med en container som avviser samme port.

Startrekkefølgen betyr noe i begge tilfeller, fordi en binding til en adresse som først dukker opp etter at tunnelen kommer opp, feiler stille ved oppstart.

Sjekk privat tilgang og en avvist offentlig sti

Lag en fersk navngitt forespørsel fra en autorisert klient med applikasjonens egne identitetskontroller intakte. Prøv deretter den samme tjenesten fra utsiden av tunnelen, og bekreft at den ikke svarer. Et privat navn er en bekvemmelighet og ikke en begrensning, og en lytter som fortsatt er bundet til den offentlige adressen, er fortsatt eksponert. Den siste kontrollen er den de fleste gjennomganger hopper over.

Les bindingene og filtertilstanden i stedet for vertsnavnet brukerne fikk. Eksponering er en egenskap ved socketen og ikke ved navnet. Den forskjellen overlever hver DNS-endring.

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 forespørselen returnerer siden og den ytre forespørselen timer ut, har tjenesten én bevisst privat sti, og transporten forblir tilgjengelig. Når den ytre forespørselen fortsatt svarer, må lytteren eller en publisert containerpost innsnevres før noen beskriver tjenesten som bare intern.