Melyik cím kerül a DNS-be egy VPN-en keresztül csatlakozó kiszolgálónál?
Egy hosztolt kiszolgálón három cím van, és ezek nem cserélhetők fel. Válaszd ki azt az értéket, amelyre az egyes szolgáltatásoknak szükségük van, majd ellenőrizd kívülről a gépen.
Egy telepített VPN-nel rendelkező hosztolt kiszolgálón végül három cím lesz, és ezek közül csak egy tartozik ahhoz a helyhez, amelyet éppen konfigurálsz. A szám átmásolása egy szolgáltatói panelból a DNS-be, egy figyelőbe vagy egy engedélyezési listába az az út, amelyen egy működő alagút olyan szolgáltatássá válik, amelyet senki sem ér el. Ez az útmutató úgy rendezi a munkát, hogy minden cím egy megadott célra legyen kiválasztva. Felsorolja azokat a parancsokat is, amelyek igazolják, mit tettél közzé valójában.
Térképezd fel a három címet, mielőtt bármit közzéteszel
Nevezd el őket funkció szerint. Az underlay cím az, amelyet a gép használ a VPN végpontjának eléréséhez az interneten keresztül, és gyakran privát a szolgáltató NAT-ja mögött. Az alagútcím a VPN-en belül él, a kiszolgáló vagy a kliens osztja ki a terméktől függően. A nyilvános kimenet az a cím, amelyet egy távoli webhely a fordítás után naplóz, és nem kell léteznie olyan interfészen, amelyet meg tudsz kérdezni.
Egy panel, amely egyetlen nyilvános címet mutat egy géphez, nagyon keveset mond a másik két szerepről. Az underlay elérhetősége követelmény, nem vásárlás: egy otthoni router mögötti laptop elérhet egy hosztolt VPN-végpontot anélkül, hogy nyilvános IPv4-címe lenne. Amit nem tehetsz meg, az az, hogy bejövő útvonalat találj ki egy olyan név beírásával, amely olyan címre oldódik fel, amelyet senki sem továbbít.
A címet a szolgáltatás alapján válaszd, ne a címke alapján
Írd le, mit kell tennie a kiszolgálónak, mielőtt számot választasz. A kimenő API-hívásoknak stabil kimenetre van szükségük, ha a másik fél engedélyezési listát vezet. A privát hozzáféréshez olyan alagútcím kell, amelyre a kliensek tudnak útvonalat választani, és egy hozzá kötött figyelő. A nyilvános hosztoláshoz olyan bejövő leképezés kell, amelyet a szolgáltató valóban kínál, és ezt a kimeneti cím önmagában nem biztosítja.
Egyetlen gép mindhárom célt szolgálhatja, és mégis három különböző címet használhat. Az törik meg, hogy egyetlen érték mindet lefedi:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
A bejövő sor az, amelyről az emberek vitatkoznak. Egy rekord, amely a kimeneti címre mutat, nem hoz létre figyelőt, tűzfalnyitást vagy portleképezést, és a várakozás ezen nem változtat. Amikor a szolgáltató dedikált címet ad el egy bejövő szabállyal együtt, az a csomag az a képesség, amelyet megvásároltál; a cím önmagában nem jogosultság.
Parancsok, amelyek megmutatják, melyik cím melyik
A gépet olvasd, ne a panelt. Az interfésznevek rendszerenként eltérnek, ezért a címeket az eszközökhöz párosítsd, ne egy címkében bízz.
Az első sor minden IPv4-címet és a hozzá tartozó eszközt felsorolja, a második pedig megkérdezi a kernelt, melyik eszközt használná egy ismert külső célhoz:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Ha az útvonalkeresés alagúteszközzel válaszol a nyilvános forgalomra, a teljes alagutad érvényben van. A figyelő ellenőrzése ugyanolyan fontos, mert a csak 127.0.0.1-hez kötött folyamat soha nem fog válaszolni az alagútcímen, bármilyen nevet is teszel közzé.
Tedd közzé, majd ellenőrizd kívülről
Csak azt az értéket tedd közzé, amelyre a szolgáltatásnak szüksége van: A vagy AAAA rekordot a hosztoláshoz, engedélyezési listás bejegyzést a kimenő hívásokhoz, kliensprofilt a privát hozzáféréshez. Utána abból a helyzetből tesztelj, amely számít, és az soha nem a gép, amelyet épp szerkesztettél.
Két ellenőrzés a legtöbbet lefedi, és mindkettő elég olcsó ahhoz, hogy szkriptben maradjon:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthEgy DNS-válasz, amely bizonyítja, hogy a rekordod létezik, nem bizonyítja, hogy egy kérés megérkezik, és egyetlen sikeres kérés csak azt bizonyítja, hogy egy útvonal működik egy hálózatról. Ismételd meg az ellenőrzést mobilkapcsolatról, ha engedélyezési lista van a játékban, mert a megfigyelt kimenet függhet a címcsaládtól és a megtett útvonaltól. Jegyezd fel, melyik családot ellenőrizted; egy működő IPv4-útvonal semmit sem mond az IPv6-ról.
Ha a szolgáltatás bejövő, a kimeneti cím nem elég
A bejövő hozzáféréshez négy dolognak kell egy vonalban lennie: egy névnek vagy címnek, amelyet egy kliens elér, egy útvonalnak, amely a csomagot a géphez juttatja, egy figyelőnek, amely fogadja, és egy szabályzatnak, amely nem dobja el. A VPN a második elemet változtatja meg, és néha az elsőt, a harmadikkal és a negyedikkel pedig semmit sem tesz. Ha az alagút a szállítási útvonal, a kliensek az alagútcímhez csatlakoznak, nem a kimenethez.
Jegyezd fel, melyik szolgáltatás melyik címtől függ, majd nézd át ezt a feljegyzést, valahányszor a szolgáltató megváltoztatja az útválasztási modelljét. Egy kiszolgáló, amely privátan válaszol és nyilvánosan meghibásodik, általában nem hibás; rossz identitással válaszol, és a javítás leképezési döntés, nem tűzfalmódosítás.