De gateway host zijn eigen beheerpagina: intern of openbaar adres

Een beheerpagina antwoordt vanaf een telefoon op mobiele data en loopt vast vanaf een laptop die lid is van de VPN. Aan de tunnel is niets kapot, omdat het verzoek er nooit in komt. De hostnaam wordt omgezet naar het openbare adres van de gateway, en dat adres is alleen bereikbaar van buiten de tunnel die hij beëindigt. Dit oplossen betekent de dienst een privé-ingang geven in plaats van het buitenste eindpunt te verplaatsen.

De pagina laadt van buiten en niet door de tunnel

Er worden twee verschillende verzoeken vergeleken. Via mobiele data bereikt de browser het openbare adres rechtstreeks. Vanuit de tunnel wordt dezelfde naam omgezet naar hetzelfde openbare adres, en het pakket moet nu door de tunnel naar buiten om een adres aan de eigen verre kant van de tunnel te bereiken. Dezelfde naam, hetzelfde adres, twee heel verschillende posities.

Een bestemmingsroute kiest een adres, geen poort. Niets in de routingtabel weet dat poort 443 voor beheer is en poort 1194 het transport, dus beide worden als dezelfde bestemming behandeld.

Daarom werkt de pagina soms wel en soms niet, afhankelijk van welke naam en welk netwerk de client gebruikte. Het is een padprobleem en geen authenticatieprobleem. Beide clients authenticeren prima.

Houd het buitenste eindpunt bereikbaar

Volledige-tunnelprofielen hebben een uitzonderingsroute nodig voor het VPN-eindpunt, en de redirect-gateway-optie van OpenVPN documenteert precies dat: het externe eindpunt houdt een route via de al bestaande gateway, zodat de tunnel niet in zichzelf routeert. Verwijder die uitzondering en het versleutelde transport volgt de tunnel, wat de sessie in een lus beëindigt. Die uitzondering is de reden dat het eindpuntadres bereikbaar blijft van binnen de tunnel.

Het gevolg is dat het openbare adres bereikbaar blijft vanaf de client, en daarom kan een browserverzoek aan dat adres dezelfde uitzondering volgen en naar buiten gaan zonder de tunnel in te komen. De uitzondering doet haar werk, en de naam richt de schade aan.

Lees de routebeslissing in plaats van de interfacelijst voordat u iets wijzigt. De opdrachten hieronder drukken de beslissing af in plaats van de inventaris. Voer ze uit vanaf de client die faalde.

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

Als de opzoeking de eindpuntroute via de fysieke gateway toont, is het gedrag correct en wordt de beheerpagina simpelweg de verkeerde weg op gestuurd. Dat is het punt waar naamresolutie de oplossing wordt.

Geef de dienst een privénaam

De dienst heeft een naam nodig die binnen de tunnel naar het adres van de gateway wordt omgezet, terwijl de certificaat- en hostnaamsemantiek behouden blijft die de applicatie verwacht. Een privézonerecord voor de beheernaam is het gebruikelijke antwoord, en het laat de transportnaam ongemoeid.

Verwijs de transportnaam niet opnieuw naar het interne adres, want de volgende tunnelopbouw zou dan proberen een adres te bereiken dat alleen binnen een tunnel bestaat. Die fout levert een VPN op die precies één keer werkt.

Controleer ook beide adresfamilies, want een achtergelaten AAAA-record kan de browser ergens heen sturen waar het privéplan nooit kwam.

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/

Stem het beleid af op waar het proces draait

Een native proces dat op de gateway luistert, is bereikbaar via het pad van lokale invoer, dus de invoerketen en de socketbinding bepalen of het verzoek wordt geaccepteerd. Doorstuurregels en IP-doorsturen zorgen er niet voor dat een lokale luisteraar antwoordt. Sta de bronnen van de tunnel toe in het invoerbeleid en bevestig dat het proces aan een adres is gebonden dat de tunnel kan bereiken.

Een container die op een hostpoort is gepubliceerd, volgt een ander pad, omdat het pakket op bestemming wordt vertaald en doorgestuurd. Dat verzoek komt bij het doorstuurbeleid van de host en de eigen regels van Docker, en daarom kan een werkende native luisteraar samengaan met een container die dezelfde poort weigert.

De startvolgorde is in beide gevallen belangrijk, omdat een binding aan een adres dat pas verschijnt nadat de tunnel omhoog komt, bij het opstarten stil faalt.

Controleer privétoegang en een geweigerd openbaar pad

Doe een vers benoemd verzoek vanaf een geautoriseerde client met de eigen identiteitscontroles van de applicatie intact. Probeer daarna dezelfde dienst van buiten de tunnel en bevestig dat hij niet antwoordt. Een privénaam is een gemak en geen beperking, en een luisteraar die nog aan het openbare adres is gebonden, is nog steeds blootgesteld. Die laatste controle is degene die de meeste beoordelingen overslaan.

Lees de bindingen en de filterstatus in plaats van de hostnaam die gebruikers kregen. Blootstelling is een eigenschap van de socket en niet van de naam. Dat onderscheid overleeft elke DNS-wijziging.

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/

Wanneer het interne verzoek de pagina teruggeeft en het externe verzoek vastloopt, heeft de dienst één bewust privépad en blijft het transport bereikbaar. Wanneer het externe verzoek nog antwoordt, moeten de luisteraar of een gepubliceerde containerentry worden ingeperkt voordat iemand de dienst als alleen intern beschrijft.