VPN-végpont neve kontra privát szolgáltatás neve: két felelős

Két név írhatja le ugyanazt a telephelyet, és válaszolhat teljesen különböző kérdésekre. A vpn.branch.example megmondja egy távoli partnernek, hol találja a VPN-végpontot, és fel kell oldódnia, mielőtt bármilyen alagút létezik. A inventory.branch.example megmondja egy jogosult felhasználónak, hol él egy privát alkalmazás, és csak akkor számít, amikor az alagút már áll. Az egyik karbantartása semmit nem tesz a másikért.

Nevezd meg a két rekordot, mielőtt bármelyiket is hibakeresed

Írd le mindkettőt a felelőseikkel együtt. A végpontnál jegyezd fel, ki frissíti a nyilvános címet, és hogyan frissíti a VPN-kliens a válaszát. A szolgáltatásnál jegyezd fel, ki birtokolja a privát címet, melyik zóna tartja a rekordot, és mely feloldóknak kell rá válaszolniuk.

Ez a rövid lista megakadályozza a terület leggyakoribb téves diagnózisát: egy működő telephelyi alagút újraindítását egy olyan rekord javításáért, amely teljes egészében benne él. Az alagút a szolgáltatásnév szállítója; nem annak tekintélye.

Amikor változást javasolnak, kérdezd meg, melyiküket érinti a két rekord közül. Ha senki nem tud válaszolni, a változás nem ütemezhető.

A végpontnak fel kell oldódnia, mielőtt bármilyen alagút létezik

Tegyük fel, hogy a telephely internetkapcsolata új nyilvános címet kap. A végpontfrissítő közzéteszi az új címet, és a távoli VPN-megvalósításnak képesnek kell lennie a megváltozott válasz olvasására. Bármelyik feloldó szolgáltatja is ezt a választ, elérhetőnek kell lennie az alagút nélkül, különben a kliens olyan nevet üldöz, amelyet csak azután tud feloldani, hogy csatlakozott ahhoz, amit nem talál.

Ezt a rendszerindítási függőséget érdemes nyíltan kimondani, mert könnyű véletlenül létrehozni, amikor minden belső feloldó a VPN mögött ül. Tarts fenn egy alagút előtti útvonalat a végpont kereséséhez, és igazold a kliens újracsatlakozási viselkedését ahelyett, hogy feltételeznéd, az új választ azonnal átveszi.

A dinamikus DNS-nek is vannak határai, amelyeket a rekordfrissítés nem léphet át. Egy rekord frissítése nem nyit tűzfalportot, nem hoz létre NAT-leképezést és nem bizonyít partnerazonosságot. Egy közzétett cím zárt porttal olyan klienst ad, amely helyesen old fel, és mégsem tud semmihez csatlakozni.

Végül, egy futó kliens tovább használhat egy gyorsítótárazott végpontot, amíg újra nem csatlakozik. Válaszd szét a jegyzeteidben a közzétételt, a gyorsítótárat és az újracsatlakozási szabályt, hogy egy elavult partnert ne nézzenek hibás frissítőnek.

A szolgáltatásnév leírja, hol él az alkalmazás

Most tegyük fel, hogy az alagút egészséges marad, de a leltárszerver 172.26.14.20 címről 172.26.14.35 címre mozdul. A nyilvános végpontrekord nem érintett, míg a privát szolgáltatásrekordnak változnia kell. Az adott szolgáltatásnak fenntartott cím vagy statikus kiosztás használata ritkábbá teszi ezt; egy jogosult frissítési útvonal kezeli azokat az eseteket, amikor ez szándékos.

Itt két frissítési mechanizmus keveredik. A RFC 2136 protokollt határoz meg DNS-rekordok zónán belüli hozzáadására és törlésére, míg egy kereskedelmi dinamikus DNS-szolgáltató teljesen más HTTP API-t tehet elérhetővé más célra. Az egyik használata nem jelenti azt, hogy a másik létezik a környezetedben. Ellenőrizd, melyik mechanizmust fogadja el valóban a zónád, mielőtt frissítőt írsz ellene.

A helyes privát válasz csak az első feltétel. Ahhoz, hogy egy távoli hívó használhassa, a kliensnek olyan feloldó kell, amely hordozza a privát zónát, olyan szabály, amely engedélyezi a lekérdezéseket ahhoz a feloldóhoz, és továbbítás a visszatérő címhez. Egy név, amely a kliens számára elérhetetlen címre oldódik fel, időtúllépést okoz, amely szerverhibának látszik.

Teszteld a két útvonalat külön

Ellenőrizd a végpontot az alagúton kívülről és a szolgáltatást belülről, és tartsd az eredményeket két független tényként:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Ha az első lekérdezés meghiúsul, a probléma a nyilvános közzététel vagy az alagút előtti feloldási útvonal, és semmilyen belső változás nem segít. Ha a második címet ad vissza, de a harmadik nem mutat útvonalat az alagúton át, a DNS-réteg rendben van, a továbbítási szabály pedig nem.

Futtasd a párt minden címváltozás után, és jegyezd fel, melyik rekord mozdult el. Az átadás, amely csak annyit mond, hogy „a DNS frissült”, a következő mérnökre hagyja, hogy kitalálja, melyik életciklus futott valójában.