Azure piste-sivusto yhdistää, mutta mikään yksityinen resurssi ei vastaa
Yhdistetty tarkoittaa vain sitä, että tunneli nousi. Tarkista, mitä yhdyskäytävä voi kuljettaa, vertaa osoiteavaruuksia ja selvitä sitten nimi ja testaa itse palvelua.
Yhdistetty on tunnelin tila, ei väite tavoitettavuudesta. Piste-sivusto-asiakas voi viimeistellä IKE:n, saada osoitteen ja silti päästä ei mihinkään, koska yhdyskäytävä välittää liikennettä vain verkoille, jotka VNet jo tuntee. Käy nämä viisi tarkistusta järjestyksessä ja pysähdy ensimmäiseen epäonnistumiseen. Eteenpäin hyppääminen on se tapa, jolla DNS-ongelmaa hoidetaan palomuuriongelmana tunnin ajan.
Järjestys on tärkeämpi kuin lista.
Tarkistus 1: päätä, mitä tunnelin on määrä kuljettaa
Azure VPN Gateway päättää tunnelin ja välittää liikennettä, joka kuuluu VNetiin; se ei oleyleinen internetin uloskäynti. Jos käyttäjät odottavat selailunsa poistuvan Azurea pitkin, suunnittelu on väärä ennen kuin mikään asiakasasetus tulee peliin. Ota split tunneling käyttöön, jotta paikallinen internet pysyy paikallisella reitillä, ja käytä NAT-instanssia tai sivusto-sivusto-tunnelia, kun kiinteä lähtöosoite todella vaaditaan.
Kirjoita ylös, mihin asiakkaan pitää päästä ennen kuin testaat mitään. Ilman sitä listaa jokainen osatulos näyttää edistykseltä.
Tarkistus 2: vertaa osoiteavaruuksia ennen varmenteita
Päällekkäisyys arvioidaan leveämmistä alueista, joten kaksi verkkoa, jotka näyttävät aliverkon tasolla erilaisilta, törmäävät silti, jos niiden yläblokit menevät päällekkäin. Yhdyskäytävän aliverkon on oltava erillinen ja riittävän suuri SKU:lle, eikä asiakkaan osoitepooli saa törmätä VNetiin tai mihinkään peeringin kautta tavoitettavaan. Muuta suunnitelmaa ja ota uudelleen käyttöön, sillä reittien lisääminen kompensoimaan tuottaa tunnelin, joka toimii joillekin kohteille ja selittämättömästi ei toisille. Provisiointi epäonnistuu täällä äänekkäästi, mikä on hyvä tapaus.
Todennus on seuraava portti. Varmenne-, RADIUS- ja Entra ID -profiilit eivät ole vaihdettavissa, ja asiakaspaketti eroaa kunkin osalta.
Tarkistus 3: selvitä yksityinen nimi sisältä käsin
Asiakas pitää oman resolverinsa, ellei ladattu profiili sisällä VNetin DNS-palvelimia, ja se lista upotetaan lataushetkellä. Lisää forwarder VNetin sisään, aseta se VNetin DNS-palvelimeksi ja lataa ja tuo asiakaspaketti uudelleen. Vanhan paketin uudelleenkäyttö testaa vain vanhaa resolverilistaa.
Testaa ensin osoite, koska se erottaa reitityksen nimeämisestä yhdellä askeleella: Test-NetConnection 10.20.1.4 -Port 3389.
Jos osoite vastaa ja nimi ei, kysy resolverilta suoraan komennolla Resolve-DnsName files.corp.example -Server 10.20.0.4. Jos molemmat epäonnistuvat, vika ei ole DNS:ssä ja sinun pitäisi lopettaa DNS-asetusten muokkaaminen. Azure-palvelun DNS osoitteessa 168.63.129.16 vastaa vain VNetin sisältä, joten sen ulkopuolella oleva asiakas ei voi käyttää sitä osoitetta resolverina.
Tarkistus 4: testaa tunnelin takana olevaa palvelua
Terve tunneli ja suljettu portti näyttävät asiakkaalle samalta. Tarkista vieraan palomuuri, sitten aliverkon tai NIC:n verkkoturvaryhmä, sitten kuunteleeko palvelu yksityisessä osoitteessa eikä vain loopbackissa. Salli asiakaspooli lähteenä sen sijaan, että avaat säännön internettiin, ja muista, että SMB Azure Filesiin vaatii yksityisen päätepisteen polun tunnelin kautta. Kun resurssi vastaa IP:llä mutta ei nimellä, palaa tarkistukseen 3 sen sijaan että koskisit yhdyskäytävään.
Yksi taulukko pitää kerrokset erillään työn aikana:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Tarkistus 5: kirjaa profiili ennen eskalaatiota
Laita tikettiin yhdyskäytävän tyyppi, tunnelin tyyppi, todennusmenetelmä ja asiakkaan käyttöjärjestelmä. Varmenteellinen IKEv2-profiili ja RADIUS-profiili epäonnistuvat eri syistä, ja toista tunnelityyppiä varten rakennettu asiakas yhdistää vain, kun yhdyskäytävä tarjoaa yhteensopivan protokollan.
Pienelle tiimille kestävä suunnittelu on yksi VNet, yksi DNS-forwarder ja dokumentoitu split-tunnel-asiakas. Jos vaatimus on kiinteä julkinen uloskäynti, päätä sivusto-sivusto-tunneli palomuuriin, jota hallitset, ja reititä internetliikenne sinne sen sijaan, että pyytäisit piste-sivusto-yhdyskäytävää tekemään jotain, mihin sitä ei koskaan rakennettu.