Kaksi julkista IP:tä yhdellä Azure VPN -virtuaalikoneella: kumpi tekee mitä

Kaksi julkista IP:tä yhdellä Azure VPN -virtuaalikoneella luo odotuksen, joka harvoin pitää: osoite, johon asiakkaat yhdistävät, on myös osoite, jonka verkkosivustot näkevät. Kolme riippumatonta päätöstä tuottaa tämän tuloksen, ja vain ensimmäinen koskee tunnelin kuuntelijaa. Toinen on vieraan lähde, jota käytetään välitetylle asiakasliikenteelle, ja kolmas on Azuren lähtevä menetelmä, joka koskee tuota lähdettä. Muuta yhtä, ja kaksi muuta pysyvät paikallaan, joten päätä jokainen erikseen.

Päätös 1: mihin tunneli päättyy

Azuren julkinen IP liitetään NIC:n yksityiseen IP-määritykseen; se ei ole osoite, jonka lisäät vieraan käyttöjärjestelmän sisään. Lue määritys sen sijaan että oletat sen: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Minkä yksityisen osoitteen tuo kysely palauttaakin, juuri se vieraan on todella oltava.

Yksi NIC voi kantaa useita IP-määrityksiä, joten kaksi julkista osoitetta ei vaadi kahta NIC:iä. Jos suunnittelu kuitenkin käyttää kahta NIC:iä, kumpikin tuo omat vierasreittinsä ja seuraavat hyppynsä, ja olet lisännyt reitityspäätöksen sen sijaan että olisit yksinkertaistanut sitä.

Palvelulle, jolla on nimenomainen paikallinen sidonta, sido vieraan todelliseen yksityiseen osoitteeseen, älä koskaan julkiseen paikkamerkkiin. Kuuntelija, joka hyväksyy kaikki osoitteet, vastaanottaa liikennettä jokaisen sitä lähestyvän IP-määrityksen kautta, joten rajoita sisäänkäyntiä verkon suojausryhmällä ja isännän palomuurilla sen sijaan että toivoisit sidontajärjestyksen ratkaisevan.

Päätös 2: mitä lähdettä välitetty asiakas käyttää

Kun yhdyskäytävä on purkanut asiakaspyynnön salauksen, välitettävä paketti on eri paketti kuin VPN-kuuntelijalle saapunut. Vieras tarvitsee välityksen käyttöön, liikenteen sallivan palomuurikäytännön ja lähdeosoitteen, jonka pilvisuunnittelu sallii. Jos käännät asiakkaan sisäisen osoitteen, Azure arvioi juuri tuon käännetyn lähteen, ei asiakkaan sisäistä osoitetta.

Kapea SNAT-sääntö voi valita vieraan yksityisen lähteen, mutta se ei voi ohittaa myöhempää Azuren käännöstä. Valitse SNAT, kun tarvitset vastuullisuuden asiakaskohtaisesti virtuaalikoneen sisällä; jätä se pois, kun aliverkon lähtevä suunnittelu tarjoaa jo vakaan julkisen lähteen ja toinen käännös lisäisi vain tilaa.

Päätös 3: mikä Azuren lähtevä menetelmä voittaa

Microsoft dokumentoilähtevän liikenteen ensisijaisuusjärjestyksen: sovellettava reitti laitteeseen tai yhdyskäytävään on etusijalla, ja aliverkon NAT Gateway -yhteys on etusijalla instanssitason julkiseen IP:hen nähden kyseisellä polulla. Tämän järjestyksen vuoksi käännös osoitteeseen 10.20.0.5 ei todista, että verkkosivusto näkisi 198.51.100.20. Lue tehokas reititystaulukko, NAT Gateway -liitos ja NIC:n julkinen IP yhdessä ennen kuin hyväksyt lähtösuunnitelman.

PidäAzuren NIC:n välitysasetuserillään Linuxin välityksestä. Pilven lippu sallii paketit, joiden lähdettä tai kohdetta ei ole osoitettu NIC:lle; se ei ota net.ipv4.ip_forward käyttöön, eikä vieraan asetus anna pilven lupaa.

Tunnelin pistokkeella on oma lähdepäätöksensä

WireGuardin Address wg-quickin alla osoittaa osoitteen WireGuard-rajapinnalle; se ei ole ulkoisen UDP-sidonnan ohje. Salatun pistokkeen lähde seuraa reititystaulukkoa, joten käytäntöreitti tai toinen oletusreitti voi siirtää sitä koskematta rajapinnan osoitteeseen.OpenVPN: local-asetus ja UDP multihome käyttäytyvät samoin: ne koskevat kuuntelijaa ja sen vastauksia, eivät jokaisen välitetyn asiakkaan internet-lähdettä.

Säilytä tunnelia kantava alikerroksen reitti ja varmista, että asiakas saa edelleen todennettuja vastauksia odotetusta sisäänkäyntijärjestelystä. Älä luota osoiteluettelon järjestykseen pysyvänä lähdevalintakäytäntönä, sillä seuraava NIC:lle lisättävä osoite voi muuttaa sitä, kumpi voittaa.

Mitä hyväksyä ja missä järjestyksessä

Hyväksy kolme tulosta erikseen. Ensinnäkin ulkoinen asiakas saavuttaa aiotun VPN-sisäänkäynnin. Toiseksi uusi sallittu pyyntö tuolta VPN-asiakkaalta poistuu dokumentoidun internet-uloskäynnin kautta. Kolmanneksi tahattomat kuuntelija- ja välityspolut pysyvät hylättyinä. Kirjaa julkisen ja yksityisen osoitteen vastaavuudet sekä jokaisen päätöksen vieras- ja pilviomistajat samaan paikkaan.

Onnistunut tunneli todistaa vain ensimmäisen osan. Testaa uloskäynti uudella virtauksella, sillä välimuistiin tallennettu yhteys voi käyttää vanhaa lähdettä vielä kauan reitin muuttumisen jälkeen.