Site-to-site-VPN toimii vain yhteen suuntaan: kaksi erilaista vikaa
Vastaus, joka ei koskaan palaa, ja yhteys, joka hylättiin, ovat kaksi erilaista vikaa. Vertaa käytäntöä, reititystä ja lähdeosoitetta, jonka palvelin todella näkee.
Sijainti A tavoittaa B:n, B ei tavoita A:ta, ja tunneli näyttää molempiin suuntiin kunnossa olevalta. Ennen kuin kosket tunneliin, päätä, kumpi vika sinulla todella on. B:llä aloitettu uusi yhteys, joka hylätään, ja A:lta aloitetun yhteyden vastaus, joka ei koskaan saavu, tuottavat samankaltaisia valituksia ja täysin erilaisia diagnooseja. Toinen on käytännön tai reitin ongelma matkalla; toinen on paluureitin tai tilan ongelma liikenteelle, joka oli jo sallittu.
Tämä ero ratkaisee, mitkä komennot kannattaa ajaa.
Kaksi vikaa, jotka näyttävät samoilta
Ensimmäisessä tapauksessa B:n isäntä lähettää SYN:n A:lle, eikä mitään tule takaisin. Toisessa A:n isäntä avaa istunnon onnistuneesti ja vastaus katoaa paluumatkalla. Molemmat käyttäjät sanovat yhteyden olevan yksisuuntainen, ja molemmat kuvaavat kadonnutta pakettia, joten kuvaus yksin ei voi erottaa niitä.
Kysy, kumpi puoli aloitti epäonnistuneen yrityksen. Tämä yksi seikka poistaa puolet mahdollisista syistä.
Tarkista sitten, että testi käytti koko ajan samoja isäntiä ja samaa palvelua. Ping yhdeltä puolelta ja tiedostojakoyhteys toiselta testaavat kahta eri asiaa, ja yhdyskäytävältä tehty diagnostiikka voi valita tunneliosoitteen, jota mikään käyttäjän liikenne ei koskaan käytä.
Ensimmäinen tapaus: paluureitti puuttuu
Etäpalvelin, joka vastaa toisen oletusyhdyskäytävän kautta, voi vastaanottaa pyynnön ja reitittää vastauksen muualle. Tilaa seuraavat palomuurit pudottavat silloin epäsymmetrisen vastauksen, koska se ei vastaa muodostettua virtaa, mikä näyttää täsmälleen suunnalta, joka ei koskaan toiminut. Käännös lisää toisen version: kohde näkee käännetyn lähteen ja vastaa sille, joten alkuperäiselle osoitteelle kirjoitettu sääntö ei koskaan täsmää.
Tarkista osoite, jonka kohde todella näkee käännöksen jälkeen, ja paluureitti sille osoitteelle alkuperäisen aliverkon sijaan.
Toinen tapaus: käytäntö ei koskaan sallinut sitä
Vastakkainen tapaus on yksinkertaisempi ja yleisempi kuin miltä näyttää: yhden toimiston on tarkoitus käyttää keskitettyä palvelua eikä koskaan aloittaa yhteyksiä keskukseen. Tämä epäsymmetria on tarkoituksellinen käyttöoikeuspäätös, ja tunneli toimii suunnitellusti. Lue käyttöoikeuskäytäntö ennen kuin muutat mitään tunnelin asetusta. Asiakirja, ei pakettikaappaus, kertoo, mikä suunta oli tarkoitettu. Kaappaus voi näyttää vain mitä tapahtui, ei sitä mikä oli sallittu.
Jos kaksisuuntainen aloitus on todella tarpeen, lisää kyseisen palvelun lupa alustan tukeman sääntöjoukon kautta. Kaikkien aliverkkojen tekeminen keskenään luotetuiksi yhden sovelluksen korjaamiseksi muuttaa kapean vaatimuksen laajaksi luvaksi, ja tätä vaihtokauppaa tarkastellaan harvoin jälkeenpäin.
Vertaa ennen ja jälkeen samoilla isännillä
Tarkkaile saman yrityksen molempia päitä, älä kahta erillistä yritystä. Kaappaa aloittavan isännän yhdyskäytävällä ja kohteessa ja vertaa sitten, mitä tuli sisään, mitä meni ulos ja minkä osoitteen kaukopuoli näki.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
Jos kohteen kaappaus näyttää pyynnön odottamattomalla lähdeosoitteella, vastaus on käännöksessä tai reitityksessä eikä tunnelin tietoturvakäytännössä. Jos kohde ei näytä lainkaan pyyntöä, paketti ei koskaan ylittänyt suojattua reittiä.
Korjauksen jälkeen toista sama testi samalta isännältä ja varmista, että asiaankuulumaton käyttö evätään edelleen. Tunnelin tila “established” ei yksin tue kumpaakaan johtopäätöstä.