Gatewayen er vert for si eiga administrasjonsside: indre eller offentleg adresse

Ei administrasjonsside svarar frå ein telefon på mobildata og går ut på tid frå ein berbar datamaskin som er knytt til VPN-en. Ingenting er i stykke i tunnelen, fordi førespurnaden aldri kjem inn i han. Vertsmannsnamnet blir løyst til den offentlege adressa til gatewayen, og den adressa er berre tilgjengeleg frå utsida av tunnelen han avsluttar. Å retta dette tyder å gje tenesta ein privat inngang i staden for å flytta det ytre endepunktet rundt.

Sida blir lasta frå utsida og ikkje gjennom tunnelen

Det blir samanlikna to ulike førespurnader. Frå mobildata når nettlesaren den offentlege adressa direkte. Frå innsida av tunnelen blir det same namnet løyst til den same offentlege adressa, og pakken må no gå ut gjennom tunnelen for å nå ei adresse på den eiga fjerne sida av tunnelen. Same namn, same adresse, to svært ulike posisjonar.

Ei destinasjonsrute vel ei adresse, ikkje ein port. Ingenting i rutetabellen veit at port 443 er for administrasjon og port 1194 er transporten, så begge blir handsama som same destinasjon.

Det er difor sida stundom verkar og stundom ikkje, alt etter kva namn og kva nettverk klienten brukte. Det er eit ruteproblem og ikkje eit autentiseringsproblem. Begge klientane autentiserer heilt fint.

Hald det ytre endepunktet tilgjengeleg

Fulltunnelprofilar treng ei unntaksrute for VPN-endepunktet, og redirect-gateway-valet i OpenVPN dokumenterer nettopp det: det fjerne endepunktet held ei rute gjennom gatewayen som alt fanst, slik at tunnelen ikkje rutar inn i seg sjølv. Fjern det unntaket, og den krypterte transporten følgjer tunnelen, noko som avsluttar økta i ei løkke. Det unntaket er grunnen til at endepunktadressa blir verande tilgjengeleg frå innsida av tunnelen.

Fylgja er at den offentlege adressa blir verande tilgjengeleg frå klienten, og det er òg grunnen til at ein nettlesarførespurnad til den adressa kan fylgje det same unntaket og gå ut utan å kome inn i tunnelen. Unntaket gjer jobben sin, og namnet gjer skaden.

Les ruteavgjerda i staden for grensesnittlista før du endrar noko. Kommandoane nedanfor skriv ut avgjerda i staden for inventaret. Køyr dei frå klienten som feila.

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

Viss oppslaget viser ruta til endepunktet gjennom den fysiske gatewayen, er åtferda rett, og administrasjonssida blir berre send ned feil stig. Det er punktet der namneoppløysing blir rettinga.

Gje tenesta eit privat namn

Tenesta treng eit namn som blir løyst til adressa til gatewayen inne i tunnelen, samstundes som sertifikat- og vertsmannsnamn-semantikken applikasjonen ventar blir halden. Ein privat sonepost for administrasjonsnamnet er det vanlege svaret, og han lèt transportnamnet vere urørt.

Ikkje peik transportnamnet om til den indre adressa, fordi den neste tunnelopprettinga då ville prøve å nå ei adresse som berre finst inne i ein tunnel. Den feilen gjev ein VPN som verkar nøyaktig éin gong.

Sjekk òg begge adressefamiliane, fordi ein AAAA-post som blir liggjande att kan sende nettlesaren ein stad den private planen aldri dekte.

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 politikken til der prosessen køyrer

Ein innebygd prosess som lyttar på gatewayen blir nådd via den lokale inngangsstigen, så inngangskjeda og socket-bindinga avgjer om førespurnaden blir godteken. Videresendingsreglar og IP-videresending får ikkje ein lokal lyttar til å svare. Tillat kjeldene til tunnelen i inngangspolitikken, og stadfest at prosessen er bunden til ei adresse tunnelen kan nå.

Ein container som er publisert på ein vertsport, følgjer ein annan stig, fordi pakken blir destinasjonsomsett og videresend. Den førespurnaden møter videresendingspolitikken til verten og dei eigne reglane til Docker, og difor kan ein fungerande innebygd lyttar sameksistere med ein container som avviser same port.

Startrekkjefølgja har noko å seie i båe tilfelle, fordi ei binding til ei adresse som først dukkar opp etter at tunnelen kjem opp, feilar stille ved oppstart.

Sjekk privat tilgang og ein avvist offentleg stig

Lag ein fersk namngjeven førespurnad frå ein autorisert klient med dei eigne identitetskontrollane til applikasjonen intakte. Prøv deretter den same tenesta frå utsida av tunnelen, og stadfest at ho ikkje svarar. Eit privat namn er ei lettvintheit og ikkje ei avgrensing, og ein lyttar som framleis er bunden til den offentlege adressa, er framleis eksponert. Den siste kontrollen er den dei fleste gjennomgangar hoppar over.

Les bindingane og filtertilstanden i staden for vertsmannsnamnet brukarane fekk. Eksponering er ein eigenskap ved socketen og ikkje ved namnet. Den skilnaden overlever kvar 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 førespurnaden returnerer sida og den ytre førespurnaden går ut på tid, har tenesta éin medviten privat stig, og transporten blir verande tilgjengeleg. Når den ytre førespurnaden framleis svarar, må lyttaren eller ein publisert containerpost snevrast inn før nokon skildrar tenesta som berre intern.