Azure P2S VPN:n paluuliikenne toimii vain yhteen suuntaan

Tunnelin kuvake on vihreä, NSG näyttää sallivalta, tehokkaat reitit näyttävät oikeilta, ja silti VM ei voi avata yhteyttä takaisin yhdistettyyn asiakkaaseen. Tavallinen oletus on, että toimiva point-to-site-tunneli on symmetrinen: jos asiakas pääsee VM:ään, VM pääsee asiakkaaseen. Tämä oletus on päättelyn virhe, ei kokoonpanon. Tunneli voi kuljettaa pyytämättömän virtauksen toista suuntaa ja pudottaa toisen, ja korjaus riippuu siitä, mikä kerros sen pudottaa.

Myytti: yhdistetty tunneli on kaksisuuntainen tunneli

VPN-tunneli on käytäntöpolku, ei johto. Jokaista suuntaa verrataan valitsimiin, reitteihin ja suodattimiin, ja mikä tahansa niistä voi sallia toisen suunnan ja estää toisen.

Käytännössä epäsymmetria on niin yleistä, että suunta kuuluu ensimmäiseen testiin, ei viimeiseen. Asiakas aloittaa, yhdyskäytävä seuraa virtausta ja vastaus seuraa syntynyttä tilaa. VM, joka aloittaa uuden virtauksen, ei omaa tällaista tilaa, joten se riippuu siitä, että paluupolku on nimenomaisesti reititettävissä ja sallittu. Kun tämä polku puuttuu, yhteysyritys kuolee ennen kuin mikään sovellus näkee sen.

Testaa suunta ennen saavutettavuuden testaamista

Valitse yksi asiakasosoite, yksi VM-osoite ja yksi protokolla. Yhdistä asiakkaasta ja kirjaa tulos; aloita sitten sama testi VM:stä ja kirjaa sekin. Jos ensimmäinen onnistuu ja toinen epäonnistuu, asiakaspooli, yhdyskäytävän liitos ja polku asiakkaasta VNetiin toimivat kaikki.

Seuraava askel on todisteet, ei lisäsäännöt. Tarkista VM:n aliverkon NSG molempiin suuntiin, lue tehokkaat reitit VM:n NIC:ltä ja kaappaa paketteja VM:llä, kun asiakas lähettää liikennettä. Pyyntö, joka saapuu ilman vastausta, on suodatin- tai paluureittiongelma; pyyntö, joka ei koskaan saavu, on polkuongelma. Älä pidä epäonnistunutta pingiä todisteena siitä, että VM on saavuttamaton, koska ICMP-käytäntö voi pudottaa vastauksen TCP:n toimiessa.

IKEv2 point-to-site -paluupolku on tavallinen epäilty

Tämän artikkelin taustalla olevassa Azure-raportissa asiakas pääsi VM:ihin IKEv2:n kautta, mutta VM:stä asiakkaaseen tuleva ICMP epäonnistui, kunnes yhdyskäytävän tunnelityyppi vaihdettiin OpenVPN:ään. Raportoija kertoo, että Microsoft vahvisti rajoituksen IKEv2 point-to-site -polussa, jossa paluuliikennettä VM:stä asiakkaaseen ei reititetä symmetrisesti, ellei asiakas aloittanut istuntoa. IKEv2 nojaa liikenteen valitsimiin, eikä yhdyskäytävä kunnioittanut paluusuuntaa siinä tapauksessa.

Tämä ei tee OpenVPN:stä yleisesti parempaa tunnelityyppiä. Se tekee tunnelityypistä muuttujan tämän työkuorman testimatriisissa.

Tunnelityypin vaihtaminen on palvelumuutos, ei kytkin. Jokainen asiakas tarvitsee yhteensopivan profiilin, ja yhdyskäytävä voi tarvita eri varmenteen tai todennusasetuksen. Toista yksisuuntainen käytös yhdellä testiasiakkaalla ja yhdellä testi-VM:llä, vaihda tyyppi hyväksytyn aikataulun mukaan ja toista sitten samat suuntatestit. Jos käytös säilyy vaihdon jälkeen, tunnelityyppi ei ollut syy ja olet rajannut ongelman koskematta tuotantoon.

Myytti: broadcast-haku ylittää VNetin rajan

Toinen oletus epäonnistuu asiasta riippumattomasta syystä. Azure-virtuaaliverkko ei kuljeta broadcast-liikennettä, joten VM ei voi vastaanottaa broadcast-kehyksiä paikallisverkosta site-to-site- tai point-to-site-yhteyden kautta. Sovellukset, jotka löytävät vertaiset broadcastin avulla, kuten vanhempi tiedostoselailu tai eräät laitteenetsintäprotokollat, eivät koskaan näe kaukokohdetta, kirjoitettiinpa reitit miten tahansa.

Korvaa broadcast-haku DNS-nimillä, hakemistopalvelulla tai nimenomaisella vertaisluettelolla. Jos sovelluksella ei ole unicast-vaihtoehtoa, suunnittelu tarvitsee erilaisen etsintämekanismin, ei leveämpää tunnelia.

Mitä muuttaa ja miten se todistetaan

Jos suuntatesti epäonnistuu vain IKEv2:lla, kirjaa yhdyskäytävän tunnelityyppi, asiakasosoitteiden pooli ja tarkka ICMP- tai TCP-testi, arvioi sitten hyväksytty OpenVPN-profiili kärsineille asiakkaille. Jos se epäonnistuu kaikilla tunnelityypeillä, työstä paluupolkua: asiakasosoitteen on oltava reititettävissä VM:n aliverkosta, jokaisen käyttäjän määrittämän reitin on osoitettava kelvolliseen seuraavaan hyppyyn ja asiakkaan palomuurin on hyväksyttävä saapuva virtaus. Liitä NSG- ja reittitodisteet tikettiin.

Varmista sovelluksella, älä pingillä. Onnistunut ICMP-vaihto muutoksen jälkeen ei kerro mitään palvelun portista, sen todennuksesta tai nimien selvityksestä. Toista testi uudelleenyhdistämisen jälkeen, koska asiakas, joka saa eri pooliosoitteen, voi muuttaa tulosta. Toista se sitten vielä kerran, kun asiakas nukkuu ja herää, sillä jatketussa istunnossa yksisuuntainen käytös usein palaa.